[
Lists Home |
Date Index |
Thread Index
]
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@jeffrafter.com]
> 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
|
