The Inventor VRML proposal states:
1) Minor incompatibilites should not be introduced to make things
more elegant. I disagree. VRML could have a very long life span,
it should be as elegant as possible outthe door. If that causes
minor incompatibilites with SGI's file format, I don't see that
that's bad.
2) I am concerned with the fact that Inventor scene graphs are not
stateless. In particular, I find the fact that results are
order-dependent very disconcerting. Below, I state the reasons:
a) A very very distant node could affect the outcome.
Suppose I build a scene graph which includes references to
other peoples remote VRML's. A small change in one of thier
VRML's could accidentally cause a large change in mine.
b) It makes editing and debugging a potential swamp. Its easy to
accidentally exchange the order of two items, especcially during
complicated editing -- e.g. when the tree is being reordered.
It can be very hard to catch such a mistake.
c) Stymies efforts to optimize. For instance, given a scene graph,
it would be useful to have a tool that reorders the graph so that
all objects sharing the same texture map are drawn together (thus
avoiding thrashing of texture memory). I don't see how this is
possible if there are unpredicatable side-effects that result from
re-ordering.
Even if ONLY separator nodes were supported (That is, the only
nodes that can have children are separator nodes), I want to
emphasize that the renderered image should be independent of the
order of the children in the node.
(Or I suggest a better explanation of the distinction between
"shapes" and "properties", and exactly what the problem was
with lights & cameras. )
Also, I see nothing wrong with pulling such a stunt when implementing
a VRML renderer on top of, E.G. OpenGL. The renderer for a camera
or light node could yank stff out of the state machine as needed.
This is quite kosher, and a real programming expedient. Just don't
expose these details to the user.
3) Supported primitives:
I see nothing wrong with supporting some variation of triangle
meshes.
4) Text3:
Rather than supporting Text3 directly, it would be useful to support
an indexed "group" or composite, together with an ASCII-to-index
converter. The indexed composite would contain slots that can
contain arbitrary VRML scene graphs. The ASCII-to-index converter
would then invoke objects in the slots: e.g. saying "Hello, World"
would cause objects in slots 0x48, 0x65, 0x6c, 0x6c, etc. get drawn.
5) Level of detail node. -- I like the 3D bounding box better than the
distance idea. To get the level of detail, you get the current
matrix (the matrix thats the concatation of all transforms from root
node to here), take it's (3x3) determinent, and scale it by the window
size, in pixels. If the bounding box is not of unit volume, you
multiply that by the volume of the bounding box. This simple formula
is based on the observation that volume and determinant are one & the
same thing.
6) Orthographic projections: support them. The incremental work over
having a perpsective camera is negligable.
----