I would like to describe a new instruction which could, IMHO, be really useful
when building a scene.

A bit of background:

I used POV-Ray for a couple of years but without real artistic talent so I keep
myself with Sci-Fi subjects, my favorite being spaceships in an hard science
setting (like the RPGs 2300AD, 2320AD and Jovian Chronicles). While
building/assembling various parts to create a spaceship, I have frequently been
annoyed by the difficulty of adjusting different modules. So ...

The proposal:

1. An instruction to define a connection vector. A connection vector is an
identified vector (origin and direction) associated with an object and whose
origin is set anywhere on or near the object. Being identified means that this
vector has a mean of being uniquely addressed within the scope of the object (by
index or by name)

2. An instruction allowing to specify a connection vector from one object that
must be aligned with a connection vector of a target object. This instruction
resolves as a rotation of the first object so that the two vectors are parallel
but pointing in opposite directions. To this end, the first object is rotated
around the origin of the first vector. The rotation is followed by a translation
of the first object so that the origin of both connection vectors are the same
(in the absolute reference space)

Drawback:

1. There must be a way to uniquely identify each object
2. Once merged, there must be a way (or rules !) to tell what append with
connection vectors of both objects. Are they de facto merged or deleted?

Post a reply to this message

Kelumden wrote:
> I used POV-Ray for a couple of years but without real artistic talent so I
> keep myself with Sci-Fi subjects, my favorite being spaceships in an hard
> science setting (like the RPGs 2300AD, 2320AD and Jovian Chronicles).
> While building/assembling various parts to create a spaceship, I have
> frequently been annoyed by the difficulty of adjusting different modules.
> So ...
> 
> The proposal:
> 
> 1. An instruction to define a connection vector. A connection vector is an
> identified vector (origin and direction) associated with an object and
> whose origin is set anywhere on or near the object. Being identified means
> that this vector has a mean of being uniquely addressed within the scope
> of the object (by index or by name)
> 
> 2. An instruction allowing to specify a connection vector from one object
> that must be aligned with a connection vector of a target object. This
> instruction resolves as a rotation of the first object so that the two
> vectors are parallel but pointing in opposite directions. To this end, the
> first object is rotated around the origin of the first vector. The
> rotation is followed by a translation of the first object so that the
> origin of both connection vectors are the same (in the absolute reference
> space)
> 
> Drawback:
> 
> 1. There must be a way to uniquely identify each object
> 2. Once merged, there must be a way (or rules !) to tell what append with
> connection vectors of both objects. Are they de facto merged or deleted?

I don't understand why union{} isn't enough for your needs...

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote in
news:4b305906$1@news.povray.org: 

> Kelumden wrote:

> I don't understand why union{} isn't enough for your needs...
> 

I don't know if I'm getting him right or not but the way I understand it is 
he wants an anchor in POV space where two objects meet, a bit like if you 
stick a piece of blue tack to a table and then pull, strethc and twist it 
(as long as you don't pull too hard), the blue tack will stay stuck to the 
table in exactly the same spot, any action you perform on the blue tack 
will have no resulting effect on the table but the table and the blue tack 
will continue to be connected at the same point and covering the same area 
of the table. 


-- 
Cheers
Steve

http://www.zeropps.uklinux.net/

Post a reply to this message

Steve <ste### [at] zeroppsuklinuxnet> wrote:
> Nicolas Alvarez <nic### [at] gmailcom> wrote in
> news:4b305906$1@news.povray.org: 

> > Kelumden wrote:

> > I don't understand why union{} isn't enough for your needs...
> > 

> I don't know if I'm getting him right or not but the way I understand it is 
> he wants an anchor in POV space where two objects meet, a bit like if you 
> stick a piece of blue tack to a table and then pull, strethc and twist it 
> (as long as you don't pull too hard), the blue tack will stay stuck to the 
> table in exactly the same spot, any action you perform on the blue tack 
> will have no resulting effect on the table but the table and the blue tack 
> will continue to be connected at the same point and covering the same area 
> of the table. 

  How does that differ from union{}?

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Steve <ste### [at] zeroppsuklinuxnet> wrote:
> > Nicolas Alvarez <nic### [at] gmailcom> wrote in
> > news:4b305906$1@news.povray.org:
>
> > > Kelumden wrote:
>
> > > I don't understand why union{} isn't enough for your needs...
> > >
>
> > I don't know if I'm getting him right or not but the way I understand it is
> > he wants an anchor in POV space where two objects meet, a bit like if you
> > stick a piece of blue tack to a table and then pull, strethc and twist it
> > (as long as you don't pull too hard), the blue tack will stay stuck to the
> > table in exactly the same spot, any action you perform on the blue tack
> > will have no resulting effect on the table but the table and the blue tack
> > will continue to be connected at the same point and covering the same area
> > of the table.
>
>   How does that differ from union{}?
>
> --
>                                                           - Warp

First, sorry for being so long in answering ...

It has nothing to do with union{}. union results in the object being considered
as one entity for rendering.
Here, the 'new' instruction allows someone to design an object centered around
the origin, then, without complex calculations, put it against another object.

If I were to rely on union, I would first have to carefully compute (the surely
go into a trial and error process) the transformation of the first object to
append it to the second.

We have here a computer who can perform all the calculations for us so it seems
to me quite reasonable to tell the computer: "take object A and put in on object
B so that point x of A merge with point y of B". You still need union{} to treat
the two assembled objects as one ...

Post a reply to this message

Kelumden <nomail@nomail> wrote:
> We have here a computer who can perform all the calculations for us so it seems
> to me quite reasonable to tell the computer: "take object A and put in on object
> B so that point x of A merge with point y of B". You still need union{} to treat
> the two assembled objects as one ...

  So you want to apply the same transformation to both objects, plus an
additional translate to the first one? Still sounds like a union{} to me.

union
{
    object { ObjectB }
    object { ObjectA translate PointOnB }
    transform { ObjectBTransformations }
}

  If you definitely must keep them as separate objects for whatever reason,
you can define a transform identifier and apply it to both objects.

  It's not possible to add a new keyword which would say "give me the
transformations which were applied to this object" because there might
not be such transformations stored anywhere. They might have been applied
directly eg. to the coordinates of the object and hence are effectively lost
and unretrievable afterwards (because it's not possible to differentiate
between the original coordinates and the transformations applied to them).

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   It's not possible to add a new keyword which would say "give me the
> transformations which were applied to this object" because there might
> not be such transformations stored anywhere.

Agree. However, it should be possible to write a _function_ that transforms
(positions and orients) a child object to a parent object as described. You'd
need:
- An origin and vector for each socket (as per original post)
- Additionally, a local 'up' vector for each socket, that is orthogonal to its
respective socket vector.

This 'up' vector would remove the last degree of freedom, to give a unique
solution for the transformation you [Warp] describe.

Some functions already exist for POV-Ray to do this - perhaps someone else could
furnish us with an exact URL?

The transformations thereafter would be like a 'hinge' connector in inverse
kinematics.

Post a reply to this message