|
|
In article <399CFECD.630F8C9C@ida.utb.hb.se>, sa9### [at] idautbhbse
wrote:
> I think the main advantage of OO (from my point of view) would be
> _reading_ the location/rotation/scale etc. of objects...
...snip...
This won't be possible, even with member variables and macros.
Transformations(scale, rotate, translate, matrix) are all stored in a
4*4 matrix, and what would "location" mean? The center of the bounding
box?
BTW, I would prefer a #reference keyword to your ref {} syntax, it could
be used outside of objects. Maybe a specific members {} block in objects
would be a good idea, though...
object {...
members {
#reference Next = object {...};// a reference
#declare Velocity = < 1, 5, 0>;// a public variable
#local Speed = vlength(< 1, 5, 0>);// a protected variable
#macro GetSpeed() Speed #end // a member macro
}
}
All objects would already have public transform and material member
variables and member macros for operating on them(you could arrange all
objects in a heirarchy, with "object" being the base object, so the
language is consistent, but of course, these would be hard-coded...). In
addition to these inherited members, objects would have variables
specific to them: spheres would have a "center" vector and a "radius"
float, boxes would have "point_a" and "point_b" vectors...this would
allow the current syntax to be retained, but make things easy to do with
the OO syntax.
BTW, I think the biggest advantage of OOP scripting would be things like
macros and include files that really emulate objects. You could create a
"lens flare" object, and have as many of these as you wanted, and it
would be almost completely transparent to the person using the lens
flares. Or you could do particle systems, tree/plant objects,
etc...using them could be much easier than with macros and include
files, especially when you have many of them.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|