As another (I forget who) pointed out, 4x4 matrix calculations are trivial
to do in real time on a reasonable machine. Identifying so many different
_base_ "views" doesn't take advantage of the capabilities of our tools.
>1. A "furniture view", where 1 unit = 1 meter, one axis points up, one
>coincides with the line where the back wall of the room meets the floor,
>and the other points away from the wall. This would be useful for quickly
>placing furniture-like objects in a room so they're on the floor and next
>to the wall. (Or hanging pictures, for that matter.)
Why is this useful for quickly placing objects against anything other than
the back wall? And why would I want to make it so easy to put things
against the walls anyway? As an author, I'm far more interested in
arranging things in three dimensions ... couches, tables, water slides,
whatever, in such a manner that takes specific advantage of the fact that I
don't care about the _wall_.
>2. An "icon view", where the object must fit in a 1x1 box, one axis is up,
>one faces right, and one faces out of the screen. This would be useful
>when we have libraries containing objects of vastly different sizes, and we
>want to display a bunch of them on the screen for the use to choose from,
>in rows and columns.
But why would I want to use this view in anything other than a catalog of
VRML objects? I want chairs with high backs, and chesterfield sofas with
long, low shapes.
What we need for this is an agreement of orientation for objects, and a
unit size. So, I can grab an object, throw it in to my room facing the
right direction and know how big the creator intended it to be. That just
means an object neads to define where it's "front" is, and what's "up".
And what 1 unit in object space is in "real" space. 1 unit in this matrix
= 1 meter in normal space, or 1 unit = 1 km in normal space, or whatever.
Each object's creator can define these and then authors can be aware of
their expected orientation and size. And the author can map that object's
matrix to the units and orientation of the room.
Personally, I would like to have a full size model of the Enterprise flying
around in my office. But I'll be GOD sized so that it doesn't really
matter that it was designed for me to fit inside it. As an author I can
map the expectations of the object's creator into my own scene. =)
>Other interfacing views can be defined as the need arises for different
>domains, e.g. "chemistry view," using angstroms, "galactic view", using
>light-years, "Sim City view," where 3 units = 1 city block, etc.
Similarly, it is trivial for an author to create these "views" on the fly,
just by mapping units to units (in full knowledge of the object designer's
expectations), without having a limited set of "views" to choose from.
>The idea is that the interfacing views encapsulate whatever native
>coordinate system the designer has chosen to use for implementing the
>object; the native coordinate system should be inaccessable outside the
>object's definition. So, an object designer can use whatever coordinate
>system is convenient.
The object designer needs to be able to use whatever coordinate system is
convenient and he can do so if he provides a relation between his system
and some commom basis set (1 = 1 meter and what is up, and front).
One value of having a common set of views/unit relationships is that then
authors can "shop" for furniture-sized objects (or spaceship size), use
them in a room, and define a single transformation from those objects into
the room, instead of having to figure out the unique relationship for each
object: ok, this chair is 1 meter per unit, and my coffee table is 1 foot
per unit, and my desk is 0.25 meters per unit; now I want everything to be
twice the size, so convert unit to unit to special unit relationship, and
there I am. Hopefully, this could just be a straight 1:1 mapping if you
are using the object in the space model it was designed for. =)
>>From a language perspective, all we need is a way to attach a set of
>(view-id, matrix) pairs to an object, and a way to connect objects.
>Perhaps we might want to agree on some standard interfacing views to start
>the ball rolling, but they don't strictly need to be part of the language.
In the model I've suggested, we just need to attach a matrix for relating
their object to a reality where there is 1 meter per unit and z is up and
the x axis moves to the right along the horizon of the "FRONT" plane. (This
choice of unit and measurement is arbitrary and not inherently important,
but I think it's groovily intuitive.=)
Does anyone think this makes sense?
-j
Joe Andrieu andrieu@alta.com
818-405-1812