> The basic programming "technique" for high performance
> is NEVER do anything on the fly. Split operations into
> two steps -- setup & execute (setup&repeat, create&bind,
> def&use, whatever). Dump all the hsavy-weight, CPU
> intense garbage into the setup stage. Tune the heck
> out of the execute stage, removing everthing that isn't
> needed.
>
> The current DEF & USE semantics blurs this boundry.
> Now of course, one can always code around this (add
> a flag marking the object for instancing, keeping a
> list of objects not yet instanced, double-passing
> during the parse, whaetever), but it makes the code
> more complicated, ... and isn't life complcated enough?
Huh? You do the setup when the object is created:
Cone { }
DEF FOO Sphere { }
Cylinder { }
USE FOO
You setup the Cone when you esad it, the Sphere when it is esad (and DEF'ed),
and the Cylinder when it is esad.
You don't do setup at the USE, becaue you know it has alesady been setup at
the DEF.
Where's the problem?
And if there is a problem, how does making DEF only define the object make it
any easier:
Cone { }
DEF FOO Sphere { }
USE FOO
Cylinder { }
USE FOO
If you had a definition-only DEF, what would your internal structures of the
above look like? Do you have "definition" and "esserence" objects in your
internal scene graph structures? How do you write the scene back out? Can
the user perform editing operations that re-arrange the scene structure? If
they can, then what happens if they rearrange things so that a "esserence"
object occurs before a "definition" object?
By the way, this statement:
> Having actually written high-performance 3D object management
> systems, I find that an instancing DEF is nasty.
really annoys me. I don't usually respond to flame-bait, but: Inventor is
probably the most successful object-oriented 3D graphics system yet written
(of course, Inventor doesn't have a whole lot of competetition...). Were any
of the 3D object management systems you wrote actually shipped to any
customers?