William Tracy <wtr### [at] calpolyedu> wrote:
> Shay wrote:
> > How about:
> >
> > #local MyOb = difference {
> >   sphere { 0, 1 translate y*2 rotate z*45 translate <2,3,4> }
> >   object { Some Other Object }
> > }
> >
> > MyOb.subtrahend.transforms[1].addrotate(<0, 0, 15>);
> > MyOb.subtrahend.transforms[0] *= <1,0,0,0,0,1,0,0,0,0,0,1,0,5,0,1>
>
> Quick question for the group:
>
> Does anyone see any value in being able to use OO syntax to transform an
> object *after* it's declaration, in the general way shown in Shay's
> example? (I would like to hope that we could come up with a cleaner
> syntax than that.)

This is something I'd always like to do:

// a 3-legged 1-unit sized stool at origin.
#local stool = Stool { 0, 3 texture { textures.oak rotate 30 } }
stool.scale( .3, 1.4, .3 );
stool.place_on( floor );
stool.away( 3, nw_wall );

#local sph = sphere { 0, 1 pigment { rgb x } }
sph.place_on( stool );

Relative positioning of objects in the scene should benefit imensely from
not having to explicitely keep track of their positions by means of local
variables or half-assed positioning macros.  I've placed a sphere upon a
stool on the floor, without ever having to pass their sizes or positions.

Yes, there's trace and some positioning macros that allow us to do something
like that today in the "half-assed" routines we have in our personal
toolsets, but that's nothing compared to having current position and
transform state inside the objects themselves as properties, rather than
needing to declare variables for that purpose.

For instance, the stool is inittially at the origin  and then I place it on
the floor, which might be anywhere in the y scale.  If I had a macro to
determine the actual position of an object, given the identifier stool, all
it would get would be 0, the original location.

Post a reply to this message