I agree with Jeff down below. Having actually written
high-performance 3D object management systems, I find that
an instancing DEF is nasty.
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?
--linas
>Date: Mon, 16 Oct 1995 11:28:06 -0800
>From: [email protected] (jjc)
>Subject: Re: Why does DEF do instancing? (fwd)
>
>At 10:03 AM 10/16/95, Paul S. Strauss wrote:
>>On Oct 13, 5:30pm, Bernie Roehl wrote:
>>
>>> Chris Laurel writes:
>>> > Finn Aarup Nielsen writes:
>>> > > I seems stranges to me why the DEF command is instancing.
>>> >...
>>> Yes, it's legal. Yes, it's portable. And yes, it's an ugly kludge that
>>> could be avoided by having a non-instancing DEF.
>>
>>Several people have suggested replacing this "ugly kludge" with
>>difserent ugly kludges, including a non-instancing DEF. (Don't
>>even try to claim that's not a kludge.)
Why Not?
>If end users _are_ going to be using VRML directly, then one can make an
>argument that a Prototype/Instantiate semantic is more intuitive than the
>current DEF.
>
>If end users are NOT going to be using VRML directly, and it becomes the
>domain of language generators, authoring tools, compilers, etc., as some
>people have suggested, then the intuitive ease is less an issue than
>efsiciency and language semantics, and the current DEF is a big lose here
>also.