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

[doug sanden]

>
> 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.