Re: LANG: VRML 1.x Binary Format Proposal

Gavin Bell ([email protected])
Wed, 31 May 1995 13:27:59 -0700


On May 31, 1:18pm, Mark Waks wrote:
> Does anyone *object* to simply adding the Units node, lifted pretty
> much wholesale from Inventor? It allows you to specify the units as:
> meters, cm, mm, micrometers, microns (these *are* the same, aren't
> they?), nm, angstroms, km, feet, in, points, yds, miles, and nautical
> miles. This covers almost every base; presumably if we saw a crying
> need for any additional units, we could later add more pretty easily
> (since there clearly needs to be a general internal transformation
> capability).

Yes, I object. I'd like to get rid of the Units node from Inventor because
it causes headaches for us maintaing it and it causes headaches for
applications that have to deal with it. A simple uniform Scale at the top of
a file is, in my opinion, a much better way of changing units. We can't
remove Units from Inventor because of compatibility; I don't want VRML to
make the same mistake.

Why I hate the Units node:

Imagine an application that allows you to cut/paste objects in the scene
hierarchy. Imagine the user is dealing with part of the scene that looks
like:
DEF SEP Separator {
Scale { scaleFactor .01 .01 .01 } # centimeters
DEF OBJECT Separator {
Scale { scaleFactor .1 .1 .1 } # Now millimeters
Cube { }
}
Separator { // Another object...
}
}

Now, the user decides to move the object named "OBJECT" outside of "SEP"; the
application wants to be nice and keep the object the same size, so it figures
out the transformation applied to OBJECT with respect to SEP, and creates:
DEF OBJECT Separator {
Scale { scaleFactor .001 .001 .001 } # Scales multiply
Cube { }
}
DEF SEP Separator { # Etc, all of SEPS other children
}

The user is happy, the scene looks exactly the same way it did before only it
is arranged a little differently (perhaps to optimize rendering performance
or something).

No problem, until you replace the Scale nodes with Units nodes:
DEF SEP Separator {
Units { units CENTIMETERS } # From meters to centimeters
DEF OBJECT Separator {
Units { units MILLIMETERS } # From millimeters to centimeters
Cube { }
}
Separator { // Another object...
}
}

If the application doesn't know about UNITS it will create:

DEF OBJECT Separator {
Scale { scaleFactor .001 .001 .001 } # Scales multiply
Units { units MILLIMETERS } # Oops
Cube { }
}
DEF SEP Separator { # Etc, all of SEPS other children
}

The cube will look 1000 times smaller than it was before. Being forced to
write applications so that they deal with Units is really, really annoying--
it is much easier to write applications so that they just deal with arbitrary
transformations, and assume that transformations don't depend on any
transformations that occur before them in the scene. If I was writing an
application that allowed arbitrary editing and had to deal with Units, the
first thing I'd do would be to replace all Units nodes with the equivalent
Scale nodes.

If you redefine Units { units CENTIMETERS } to always mean Scale {
scaleFactor .01 .01 .01 }... what's the point? You've added no functionality
and very little ease-of-use.

There are similar problems supporting screen-space or screen-aligned
transformations; applications have a much, much harder time editing scenes if
a transformation means different things depending on where it is located in
the scene hierarchy (with multiple instancing, the same Units or screen
transformations may even mean two different things).