I should have given more detail. As transforms accumulate, objects
are transformed by the product of a series of matrices. An improved
LOD would leave the object untransformed, and would transform the eye
with the product of the *inverses* of those matrices, applied in the
*reverse* order. So in the example above, the old method first
transforms the object with the "translation 0 0 1", then transforms
it with the "scaleFactor .5 .5 .5". In the new method, the eye would
first be transformed with a "scaleFactor 2 2 2", then with a
"translation 0 0 -1". So for this example, the new method would give
a distance of 1 (first multiply the eye by 2 leaving it at 0,0,0,
then shift it to 0,0,-1) and the old method would give a distance of .
5 (first move the object center to 0,0,1, then shrink it to 0 0 .5).
As desired, the new method looks like it's twice as far away.
For this sort of transform, the inverse is cheap to calculate. For a
Leemon Baird
general MatrixTransform it can be more computationally intensive, but
the inverse only needs to be calculated once, when the file is p
additional matrix be stored for each MatrixTransform node, but not
for the simpler transforms such as translation and scaleFactor. As
with other operations, the browser would be free to do whatever it
thinks is reasonable when it finds a singular matrix (or we could say
that such matrices should be ignored when calculating LOD). The
fractal VRML p (http://kirk.usafa.af.mil/~baird/vrml) contains
some Mathematica source files that show how to do VRML matrix
calculations (for the current system, not the new one).
[email protected]
http://kirk.usafa.af.mil/~baird