Cart
[Home] [By Thread] [By Date] [Recent Entries]
USE nodes have been in VRML since the beginning. I think SVG borrows somewhat liberally from VRML. One of the things I'd like to see is some unification of SVG and X3D so that SVG can be the 2D layer for X3D, handle text the same way, etc. That would be a nice to have because 3D systems need 2D layers for things like HUDs. USE nodes may be tough to implement, but I wouldn't know as I've not written a VRML or X3D browser. Since there is a Java-based open source for X3D, (Xj3D), one could find out. I can say with some experience that they are very useful when authoring a scene unless one routes events to them or does any editing without much thought and the change ripples all over the scene.So for example, you can DEFINE the geometry, then USE it elsewhere in the scene with say, different textures. A USE node has DEF'd name. Similar to the ID, it can then be referenced (similar to IDREF). The VRML parser doesn't yell about multiple DEFs with the same value, so you have to watch that. In X3D, the XML parser should catch that if you use the XML encoding and the X3D DTD/Schema. In X3D and VRML, USE gets you a performance advantage, so they are recommended for obvious reasons. OTOH, since ROUTEs are from DEF names to DEF names, USEd objects can get you in trouble. If for example, you send a transform to the rotation field, all of the USE'd objects spin. Keep in mind that ROUTEs are not hyperlinks, per se; they specify the path of events (event out to event in). So where you have a set of animation objects, you are actually routing the values of the events through the objects (eg, from a proximity sensor out to an interpolator in, interpolator out to tranform rotation in) and any objects within the objects (if you rotate a Transform, you are rotating a coordinate system and any objects within it). That takes some practice to get used to, so the solar system model is a good one to practice on (sun turns on its axis, planets turn on their axes, moons turn on their axes, sun orbits galaxy, planets orbit sun, moons orbit planets). It is easy once you get the hang of nested coordinate systems and routing interpolators to transforms. Then you can route into and out of scripts. Given a network protocol, (eg, XMSF), the fun boggles the bum. Again, X3D is a network of objects where the objects have hierarchy and type. The encoding (eg, XML, Classic VRML, binary) is just stuff. Important, but just stuff. len From: Jeff Rafter [mailto:lists@j...] > Same for VRML and X3D. It has route structures. I tend to think of it as > a network of objects, not a hierarchy. X3D has a hierarchy in the > XML encoding because it has to have a root node. In the VRML, encoding, > it doesn't. USE nodes provide, define one use everywhere functionality. > There is a hierarchy of objects with some inheritance of properties, and > to nest finite coordinate spaces. X3D like VRML likes a one pass parse. I was actually thinking of bringing up a very similar example in SVG. In SVG 1.1 you have a <use> element that can refer by id to a defined graphic primitive. Certain attributes of the <use> are passed on to the conceptual copy of the primitive (say a polyline). While this cuts down on repeated data throughout the SVG document it is wildly complex to process. One must understand the notion of a conceptual graphic, a shadow tree, and a realized version of the document when rendered. This is exacerbated by interactivity-- when an object that was <use>d is clicked you must find the conceptual node correlating to the position clicked, then find the corresponding <use> element and ultimately pass a third interface to the conceptual primitive using an SVGElementInstance. Once you have all of that figured out you then have to worry about mutation events in either the <use> or the element to which the <use> is referring (i.e., both ends of the relationship must be monitored for changes). This ultimately leads to a lot of jumping around in the processing. It is confusing at best. When working with <use> elements the first question I ask of document creators is "Do you *really* need them". I wasn't sure exactly how to tie this back to Roger's post-- so thanks Len for giving me the stepping stone. Cheers, Jeff Rafter
|
