Just like to voice support for this. At Computer Science House, our current
distributed VR system follows this type of methodology. I brought this up
a little at the SIGGRAPH VRML BOF and the SIGGRAPH Garage-tech BOF. However,
I find its a little confusing to use the term "object" for everything.
What are normally considered objects in a traditional sense (the room, the
chair, etc.), are termed 'objects' but are really collections of propertiesies
(or property objects). Properties are just logical groupings of certain
attributes. The standard attributes that we defined at the BOF session
lend themselves to being property groups. That is to say, one property will
denote position, another orienatation, another geometric shape, another
texture, another behavior, etc.
We've arranged are properties in dynamic trees underneath the 'object'
class indexed by their name (string). Certain common properties can also
be directly referenced from the `object' class by direct pointers...we call
these "named properties".
By applying other OOP concepts such as encapsulation and virtual functions,
we can create a common interface for all properties such that similar properties
can be substituted for eachother during run-time (say an OFF geometry instead
of a .DXF geometry). Further, proper use of generalization and inheritence
make it easy to generalize the common interface and interproperty linkage to
a standard library, which can be inherited from to define the specific
properties.
Sorry if this explanation is a little bit confusing, I'm currently trying to
write a paper about it and alot of the ideas are bouncing around in my head.
>>>Messages -
>
>See earlier comments on OOP development. :)
(ditto)
>BTW, I'm not talking about an object hierarchy in the traditional sense of
>a C++ class library, rather in a relational sense. If each item in a room
>is a container that houses multiple objects that collectively describe the
>item, then a room is a collection of items with more objects associated
>with the 'room object' that describe behaviors of collections of items such
>as cameras etc. The reasons for an approach like this are many (and I
>don't have time or a large enough soapbox *grin*) but one is
>multi-processor/single-processor threading. Threading is breaking up a
>program into smaller chunks of code that can be executed more quickly than
>the whole shebang by the processor and compete more evenly for cycles with
>other "background" processes such as networking.
>
Again, this is the basic concept behind our system. We actually have a
container named property which hads a list of unique object ids which the
container contains (note that containers contain OBJECTS not properties).
The underlying architecture that we (Computer Science House) have developed
so far using the above OOP concepts will make integration of the VRML standard
relatively easy. All the low level code and relationships are there, its just
the application of the VRML-specific data model and class libraries that will
need to be implemented.
-Eric