"Mikael Carneholm" <sa9### [at] idautbhbse> wrote in message
news:39A11AD5.5A347EF4@ida.utb.hb.se...

> I apologize if I was unclear about this. Your previous post made me
realize
> that it's better to have object type specific attributes (like .origin for
> sphere, .top & .bottom for cylinder, .corner1 & .corner2 for box, .normal
> and .distance for plane, etc.)  which relate to the initial values given
> when the object was created, and then separate .translation and .rotation
> attributes (alt. getTranslation() & getRotation() methods). Collecting
> information about an objects whereabouts should then be no problem - if
the
> .translation and .rotation attributes correspond to the respective values
in
> the transformation matrix of the object. Again, an example:
>
> #declare ABox = box{
>   <-1,-1,-1>,
>   <1,1,1>
>   translate <5,1,0>
> }
>
> Then:
>
> ABox.corner1 = <-1,-1,-1>
> ABox.corner2 = <1,1,1>
> ABox.translation = <5,1,0>
>
> ...which means the exact position of "corner1" can be retrieved by
>
> #declare corner1_pos = ABox.corner1 + ABox.translation;
>
> I think this makes more sense, as an object always is created with some
> parameters, and then translated/rotated various amounts. It should thus be
> quite logical to collect info about an object my reversing the creation
> process; think of it as setting the values at creation and getting the
same
> values at a later point.
>

Such an approach might work for simple primitives, but would fail on
anything more complex - how do you define a sensible reference point for a
blob? In addition, this is forcing a model onto POV that POV does not
actually use. Even if it was only implemented on simple primitives, it would
potentially lead new users astray.

Besides, your code could be rewritten as (I think):

#declare ABoxC1 = <-1,-1,-1>;
#declare ABoxC2 = <1,1,1>;
#declare ABoxTran = <5,1,0>;

#declare ABox = box{ ABoxC1, ABoxC2 translate ABoxTran }

#declare corner1_pos = ABoxC1 + ABoxTran;

Post a reply to this message