<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">The use of 'instance' seems a bit
overloaded and should be cleaned up. Most of the time (at least in
conversation), it is shorthand for 'reference another instance'.
This is not the right thing to do for text.<br>
<br>
WRT the sensor nodes. The VRML documents and an early version of
the spec (early 2000's) was unclear on how this worked. The use of
'union' for non-overlapping sensed regions of space refer to the
spatial union of the covered areas. <br>
<br>
The use of the term 'undefined' means the specification does not
define what should be returned or made available to the X3D
developer. It is not meant in a mathematical or software sense
where 'undefined' has a different meaning. The specification
allows a browser to determine which referenced copy is identified.<br>
<br>
Final note: When an event is triggered, time stops within the X3D
browser until the event cascade is completely processed. It is
completely processed when there are no new events generated from
that cascade or (2) any new event is a loop. In the case of (2),
the browser's event loop breaking mechanism will step in and
terminate that event. I bring this up so that people understand
that there is no motion of the viewer during a traversal of the
scene graph. Multiple separate events can be generated from a
single change in the environment. For example, if there are two
active and independent ProximitySensor nodes covering the same
physical space, motion within that spatial region will generate
two separate event cascades that both must terminate before any
other change to the environment can occur. <br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
</div>
<blockquote cite="mid:BAY181-W23ABC4D83B03132368A1C6B6510@phx.gbl"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
Hello all.
This, my first posting here, is a comment on the DEF/USE syntax within
the X3D specification. It is about the terminology used.
Paragraph 3.1.38 defines an ‘instance’ as a node created by the
instantiation process. So, consider the case where a node is first
instantiated with a DEF statement. This is an instance of the node. Now
assume that other nodes are specified with a USE statement to the above
DEF’d node. Paragraph 4.4.3 clearly states that the node is not to be
copied. Instead it is inserted multiple times into the scene graph.
Therefore, there is clearly only one ‘instance’.
Now four other paragraphs (22.4.1, 22.4.2, 22.4.3 and 23.4.1) all use
the expression ‘multiple instances’ when referring to DEF/USE
semantics. This is clearly incorrect. The one instance is merely
‘referenced’ multiple times.
The three sensor nodes referred to above are all quoted as using the
union of their boxes. All three nodes have ‘centre’ and ‘size’ fields
that define the box within which to sense. All three are affected by
the hierarchical transformations of their parents.
For each of the references to a given node (assuming that no other
parts of the scene graph modify the ‘size’ and ‘centre’ fields during
the traversal) the size and location of the box, in the local
coordinate system, will be unchanged.
Now, consider the process of traversing a scene graph with DEF/USE
nodes. The instance of the node (with the DEF) will be traversed first.
The parental transformations will be applied to the box to convert the
coordinates to world coordinates (or this could be considered in
reverse whereby the world coordinates are converted to the local
coordinates) and perform the appropriate sensing. When the next
reference is encountered (i.e. the first USE) the same instance will be
traversed again. However, it is likely to have different parental
transformations and so result in a box in a different location and
perhaps with a different size. Similarly for any further USE reference.
So each traverse of the one instance is handled in an identical manner,
generating events as appropriate. To say that they use the union is
technically incorrect. The union is never generated. To the viewer of
the rendered scene it might appear to be a union. But it is not so.
Events are not based on a union. They are based on multiple traverses
through the one instance.
Now, consider the case where multiple references have the same parental
transformations. The box size and locations will be identical in each
case. Each traverse will generate the same events cycle, resulting in
multiple identical events from the same instance, being sent along the
same routes, except for one point. The isActive state will be set /
cleared by the first traverse through the DEF’d node. Subsequent
traverses through any USE node will therefore not generate any new
events (assuming that the viewer has not altered position during the
interval between the traverses).
The specification refers to the results being undefined for overlapping
bounding boxes. Yet we can see that the results are predictable on the
basis of multiple traverses, albeit that there is no simple rule
defining what the results are. They will vary on a case by case basis,
being dependent on the viewer position relative to each of the multiple
references and the isActive status at the start of the scene graph
traversal.
Roy Walmsley
</pre>
</blockquote>
<pre wrap="">Roy,
Your analysis seems to jive with what I know so far, as a member of the general public who does some opensource programming to comply with the specs. Except you are much more precise in your reasoning. web3d.org community could use your talents, perhaps first to clean up its specs, where it has been using 'results are undefined if ..' a little too liberally.
-Doug
more..
I thought by 'union' they were using a cute word to help summarize, but I always thought of it more like the union of mars, earth and venus - not 3 scrunched together or expanded to fill the space between, rather 3 working separately but on the same cause, and since there's only one avatar or pointing sensor which can only be in one place at a time (and all this would break for multi-avatar or multi-touch), it has the effect of working like a union-of-purpose, not spatial union.
Some have worked on the multi-touch issue, doing prototypes and writing papers, but it hasn't got into the specs. That's something that needs work.
more..
DEF vs USE is for parsing, and once parsed into a scenegraph there's no record of which reference was the def (vs use)., but I gather you were just trying to say something like "3 references A,B,C where A is traversed first" we could use clearer terminology for talking about different references - perhaps you can come up with some better terminology for us.
_______________________________________________
X3D-Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:X3D-Public@web3d.org">X3D-Public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
X3D Co-Chair<br>
Cloud Consultant<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>