I concur that the new node is a clear improvement in most situations.
We might just leave the old one in, for them as *do* want it, although
it's not clear that it's worth the extra space.
>(I'm torn between wanting to get the VRML 1.0 spec done, nailed,
>out-the-door, and wanting to get it right the first time, but think this
>change is worth it).
What sort of schedule impact are we talking about here? Are we talking
about delaying the browser releases at all? (I *suspect* not -- this
doesn't sound like a difficult function to implement -- but I'd like
to hear the opinion of the implementors.) I mean, the point at which
1.0 *really* gets locked in iron is when the browsers go out the door,
and everybody and his kid brother starts making rooms. If this isn't
going to impact *that* schedule, I'm reasonably sanguine about the
change...
(I'm leery of anything that's going to delay release, though -- I've
got several people breathing down my neck for browsers to play with.
And I'll admit that I'm terribly eager to get one myself...)
>What do you think? The Intervista and WebSpace development teams both agree
>that this should be changed for VRML 1.0; I'd like to hear from people
>creating VRML content and from other people writing browsers.
>
>PS: I hereby volunteer to write a public domain QvLib-based tool that
>converts LevelOfDetail nodes to LOD nodes (I have to write the code for
>Inventor anyway), so it will be easy to convert existing VRML scenes that use
>LevelOfDetail to use LOD instead.
Given both of these caveats (and the above schedule concerns), it seems
reasonable to put in now...
-- Justin
Random Quote du Jour:
"In England, anything not expressly forbidden is permitted.
In Germany, anything not expressly permitted is forbidden.
In France, even things expressly forbidden are permitted."
-- from the Wall Street Journal