[X3D-Public] Comment on ISO/IEC IS 19775-1:2013 - DEF/USE

[Leonard Daly]

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.

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.

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.

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.


Leonard Daly


>> 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
>>
> 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
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>


-- 
*Leonard Daly*
X3D Co-Chair
Cloud Consultant
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20141230/8fd0fdcc/attachment.html>