Each object has slots for one or more "interfacing views", which are simply
4x4 matrices that convert to commonly-used coordinate systems.
I can think of at least two interfacing views that would be very useful:
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.)
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.
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.
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.
Also, support for any particular interfacing view is optional. For
example, someone designing a starship object would want to leave the
furniture view out, which would immediately indicate to users who
accidentally try to put a starship in a living room that they're doing
something silly. (Of course, you can always use another view and scale it,
if you want to put a starship in a living room anyway - a model starship,
perhaps.)
(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.
| Brian Slesinsky | bslesins@netcom.com | bslesins@us.oracle.com (work) |