[x3d-public] questions on X3DJSAIL usage: USE

Joseph D Williams joedwil at earthlink.net
Tue May 14 14:29:29 PDT 2019


➢ setting USE according to the standard created a multiparent situation

That should (shall) happen in all cases, except in hanim where we have useless lists of USEs that serve no disclosed or even guessed at purpose. 
Please don’t forget our utilization of USE in the (not needed) list of joints, segments, sites fields of x3d hanim. 
That is the (only) case where the USE reference to the object names must not be used to signal that the referenced object has a second parent, it should be ignored for that but maybe used for something else, never specified.: 
Of course this usage in hanim should be obsoleted or at least made to be optional if the actual reasoning for the lists of names cannot be determined and justified. That, or finding some simple way, like an string of names, and eliminate the USE, which would also make it consistent everywhere. 

From: Brutzman, Donald (Don) (CIV)
Sent: Thursday, May 9, 2019 8:50 AM
To: John Carlson
Cc: Leonard Daly; aono at tut.jp; X3D Graphics public mailing list
Subject: Re: [x3d-public] questions on X3DJSAIL usage: USE

On 5/8/2019 3:16 PM, John Carlson wrote:
> Leonard pointed out that setting USE according to the standard created a multiparent situation.  I was merely trying to respond to that.   Perhaps the standard needs changing?
Yes, it is OK for multiple USE nodes to refer to a single DEF node.

Example: a virtual shrubbery, it is most efficient to DEF one block of geometry for bushes, and then repeatedly Transform and USE that block to get a long row of bushes.

I think the standard is OK since it implemented many times.  Always worth a look...

The X3D Architecture specification sayeth:

4.4.3 DEF/USE semantics


Node names are limited in scope to a single X3D file, prototype definition, or string submitted to either CreateX3DFromString, CreateX3DFromStream, or CreateX3DFromURL browser service or a construction for SFNodes within a script. The USE statement does not create a copy of the node. Instead, the same node is inserted into the scene graph a second time, resulting in the node having multiple parents (see 4.3.5 Transformation hierarchy, for restrictions on self-referential nodes).

Node names shall be unique in the context within which the associated DEF keyword occurs.

4.3.5 Transformation hierarchy


The transformation hierarchy includes all of the root nodes and root node descendants that are considered to have one or more particular locations in the virtual world. X3D includes the notion of local coordinate systems, defined in terms of transformations from ancestor coordinate systems. The coordinate system in which the root nodes are displayed is called the world coordinate system.

An X3D browser's task is to present an X3D file to the user; it does this by presenting the transformation hierarchy to the user. The transformation hierarchy describes the directly perceptible parts of the virtual world.

Some nodes, such as sensors and environmental nodes, are in the scene graph but not affected by the transformation hierarchy. These include CoordinateInterpolator, Script, TimeSensor, and WorldInfo.

Some nodes, such as Switch or LOD, contain a list of children, of which at most one is traversed during rendering. However, for the purposes of computing scene position, all children of these nodes are considered to be part of the transformation hierarchy, whether they are traversed during rendering or not. For instance, a Viewpoint node which is a child of a Switch whose whichChoice field is set to -1 (indicating that none of its children should be traversed during rendering) still uses the local coordinate space of the Switch to determine its position in the scene.

The transformation hierarchy shall be a directed acyclic graph; a node in the transformation hierarchy that is its own ancestor is considered invalid and shall be ignored. The following is an example of a node in the scene graph that is its own ancestor:

DEF T Transform {
     children [
        Shape { ... }
           USE T

[Note the "USE T" above has an excessive indentation, it is a peer of the Shape node.  Dick, I'll apply the editorial tweak in X3Dv4 draft, please check.]

[same example in XML]

<Transform DEF='T'>
     <!-- ... -->
   <Transform USE='T'/>

X3D Tooltips synopsis for authors:

USE means reuse an already DEF-ed node ID, excluding all child nodes and all other attributes (except for containerField, which can have a different value).
Hint: USE references to previously defined DEF geometry (instead of duplicating nodes) can improve performance.
Warning: do NOT include any child nodes, a DEF attribute, or any other attribute values (except for containerField) when defining a USE attribute.
Warning: each USE value must match a corresponding DEF value that is defined earlier in the scene.

Whew, a lot of words.  When an author is creating a scene-graph tree, it is usually much simpler than any of that.  For a string-based tree (such as XML or DOM dcument) the USE attribute is set to some value.

For content authors, USE is well defined and has been utilized untold thousands of times.  It works.

For software implementers, how objects are handled internally is a matter of implementation.

For software implementers (such as X3DOM, X_ITE or other JavaScript libraries) running within an HTML5 DOM tree, precisely how DOM tree updates in the page get correlated with the run-time X3D scene graph is again an implementation decision.

all the best, Don
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
x3d-public mailing list
x3d-public at web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190514/e97199ff/attachment-0001.html>

More information about the x3d-public mailing list