Re: scales and standards - DON'T DO IT that way!

Gavin Bell (gavin@krypton.engr.sgi.com)
Sat, 17 Sep 1994 13:07:03 -0700

On Sep 16, 6:27pm, cal@antares.aero.org wrote:
> Um, why does moving the object out change the scale? It sounds like
Inventor
> is broken if it matters whether an object whose numbers are expressed
in
> meters is in or out of an object whose numbers are expressed in feet.

I didn't explain myself very well.

Imagine an application that lets the user pick a sub-part of an object
and make it a full-fledged part, independent of the object it was part
of before.

The application will have to do the following things:
1. rearrange the scene graph hierarchy
2. figure out what properties apply to the sub-part, and arrange
things so that the sub-part doesn't change material or size
by being moved.

Number 2 is pretty easy if Units nodes don't exist-- just figure out
what transformations the sub-part will inherit from its parent, and add
the appropriate transformations when the object is moved.

For example, if you want to make SUBPART independent for this scene:

Separator { # Root of scene
DEF Part Separator {
Scale { scaleFactor .3048 .3048 .3048 }
Translation { translation 2 3 4 }
Cube { depth .2 height .5 width .5 }

DEF SUBPART Separator {
Scale { scaleFactor 3.28 3.28 3.28 }
Translation { 3 3 3 }
Cube { }
}
}
}

... and application would probably do something like this:

Separator { # Root of scene
DEF Part Separator {
Scale { scaleFactor .3048 .3048 .3048 }
Translation { translation 2 3 4 }
Cube { depth .2 height .5 width .5 }
}
DEF SUBPART Separator {
MatrixTransform { matrix
.3048 0 0 0
0 .3048 0 0
0 0 .3048 0
.6096 .9144 1.2192 1
}
Scale { scaleFactor 3.28 3.28 3.28 }
Translation { 3 3 3 }
Cube { }
}
}

... calculating the appropriate MatrixTransform so that the object
doesn't change size when moved.

Unfortunately, the application breaks if you replace the Scale { }
nodes with Units nodes (.3048 is the meters-to-feet conversion, and
3.28 is feet-to-meters).

Why? Because the Units node for SUBPART will act like a Scale 3.28
before it is moved (current Units is FEET before it is moved, it has to
scale to METERS), but, unlike a regular Scale node, will act like a
Scale 1.0 after it is moved (current (default) Units will be METERS, it
doesn't have to do anything).

Here are the same scenes using Units:

# subpart in part:
Separator { # Root of scene
DEF Part Separator {
Units { units FEET }
Translation { translation 2 3 4 }
Cube { depth .2 height .5 width .5 }

DEF SUBPART Separator {
Units { units METERS }
Translation { translation 3 3 3 }
Cube { }
}
}
}

# subpart on its own; this DOES NOT look the same as above!
Separator { # Root of scene
DEF Part Separator {
Units { units FEET }
Translation { translation 2 3 4 }
Cube { depth .2 height .5 width .5 }
}
DEF SUBPART Separator {
MatrixTransform { matrix
.3048 0 0 0
0 .3048 0 0
0 0 .3048 0
.6096 .9144 1.2192 1
}
Units { units METERS }
Translation { translation 3 3 3 }
Cube { }
}
}

If nested Units are allowed in addition to arbitrary transformations,
it becomes very hard for applications to do the right thing.