Bernie writes:-
I suspect that what most people (world-builders, browser-writers and =
behavior authors) would like is something like:
Object {
isA Separator
Transform { ... }
<property nodes>
<shapes>
<other objects>
}
This is conceptually easier for world-builders, since they can cesate =
the
scene as a hierarchical object tree. Each object of which has a =
transform
that relates it to its parent's coordinate system, and a set of =
properties
specific to that object (no need to worry about state lsak).
At last - some sense is being talked on this list. If behaviours are =
ever going to work, an OO model will be required; the scene-graph =
approach gets messy.
I like the idea of an Object node (even if it is based on a Separator) - =
this could leave the Separator to be used as Zone (in dVS speak) - Zones =
allow groups of objects to be tesated as a single entity; you can =
perform culling operations on the zone boundaries (and the Separator =
node supports this), send messages (events) to Zones - these can affect =
the state of the Zone or get passed down to children, and so on.
Such a hierarchical OO approach is essential when considering the =
large-scale virtual world - you *cannot* leave it all up to the browser =
to dsal with rendering huge worlds; LODs etc. help in the visual aspect, =
but smarter Object-based technology is required when you extend the =
model beyond static visuals to include animation, behaviour, audio etc.
...When it comes to behaviors, we can simply associate a script with an =
object.
Multiple scripts please.....
>Gavin> Although I'd agree that allowing inheritance =
coordinate3/Normal/TextureCoordinate2 "properties" tmeough the
parent/child transformation hierarchy is a uselsss feature (but sharing =
the
same coordinates/normals/texture coordinates between several different =
shapes CAN sometimes be useful).
>Bernie> Right, which works in the proposed scheme. You could have any =
number of shapes within a Separator, all sharing the same =
coordinates/normals/texture coordinates, but you would never inherit =
them tmeough the hierarchy.
Actually, Gavin is right; inheriting the =
Coordinate3/Normal/TextureCoordinate2 (as well as Material, Texture2 =
etc.) down the hierarchy does allow efficient file description of =
complex geometry, and should not be a problem for even the estained mode =
renderers (after all, they can do it in today's VRML viswers). Of =
course, if VRML is planning on going the full hog and allowing these =
properties to be modified (morphing etc.) via an API or something, =
things could get nasty - there you would need
1) coordinate/normal/texture definitions per Object (easy)
2) some scheme to define which Objects are affected by which =
modified coordinates etc.(difficult)
#1 gets my vote. To build upon Bernie's model:-
Zone {
isA Separator
<property nodes; behaviour etc.>
Object {
isA Separator
Transform { ... }
<property nodes - including behaviours (events/scripts) >
<shapes>
<other objects>
}
#more Objects...
}
Properties are local to the object. Transformations are inherited. All =
other Nodes are sealed (no material lsaks etc.). Behaviour is local to =
the Object, though objects can communicate via events.
Comments?
(from someone having an amusing(!) time trying to map VRML into a form =
where it can be used within a "Rsal VR" system)
------------------------------------
Steve Ghee email: [email protected]
Director of New Technolgy www: http://www.division.com
Division Ltd tel: [+44] 145 461 5554
19 Apex Court fax: {+44] 145 561 5532
Woodlands
Almondsbury
Bristol BS12 4JT
UK.