Re: LANG: Standard Semantic Characteristics (was Re: LANG: Re: scalability)

John Ellson (
Thu, 16 Jun 94 22:36:48 EDT

> From: Brian Behlendorf <>
> Can we come up with a short list of standard "slots", OO characteristics,
> and that would be the semantic tagging we want? They should be
> characteristics of almost any object, and the idea is that they would be
> passed along on a higher level than the polygon-list, so that the
> browser could modify cached objects or grab the "correct one", with
> the difference being as minimal as possible. We want this list to be
> as short as possible, so that the benefit of getting the cached item
> isn't lost by overmodifying it.

There is a package called "tsipp" that I've used that front-ends a
"SImple Polygon Processor" library package with a TCL interpreted
command set (available from I've used this
package to interactively generate 3D objects as a result of a query
into an OO database (Itasca, but it could have been any OODB).

Tsipp includes a 4*4 matrix representation of relative position,
orientation and size which is used as a single attribute.
Tsipp then also provides a set of operations on those matrix variables for
translation, rotation and scaling. Also supported is
camera position, light positions, perspective, surface color,
texture, ...

Having played with this excellent package I'm convinced that the 4*4 matrix
is an efficient way of specifying relative location. I've no idea if it is
the best way, but I am sure that we shouldn't be doing anything less
capable given that it is already freely available.

> How about this:
> Standard characteristics of all objects:
> 1. color

Isn't color a property that results from a combination of surface
properties and lighting color. I don't think this is an intrinsic
property of an object as a whole.

> 2. orientation (TOP and FORWARD vectors see below)

I propose that this attribute should be "relative position" using
the 4*4 matrix representation as in tsipp. This attribute would then encompass
position, orientation and scale in a form that has proven mathematic

> 3. bounding box (8 points, simple 3-space for now?)

Is this for collision detection, or for very simple rendering?

> 4. name

In addition to its URL? Why? (At least why is it a mandatory attribute?)

> 5. the URL for the actual polygon list.

Perhaps this should be a: list of URLs of components, where components
may be simple polygons or composite objects. Each component would
have its own "relative position" to the composite object.

> Orientation - this is difficult. You obviously want the door of the
> refrigerator to face away from the wall. What is the standard axis for
> objects? If a refrigerator has a "front" we all default to, can we define a
> "front" of a chair, or a "front" of a fish?

This just demonstrates that "orientation" is a relative term. So is
"up" (which leads to "top"), and so is "size."