<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
h2
{mso-style-priority:9;
mso-style-link:"Heading 2 Char";
margin-top:13.5pt;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:15.5pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.Heading2Char
{mso-style-name:"Heading 2 Char";
mso-style-priority:9;
mso-style-link:"Heading 2";
font-family:"Times New Roman","serif";
mso-fareast-language:EN-GB;
font-weight:bold;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><h2 style='text-align:justify'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";font-weight:normal'>Hello all.<o:p></o:p></span></h2><h2 style='text-align:justify'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";font-weight:normal'>This, my first posting here, is a comment on the DEF/USE syntax within the X3D specification. It is about the terminology used.<o:p></o:p></span></h2><h2 style='text-align:justify'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";font-weight:normal'>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’.<o:p></o:p></span></h2><h2 style='text-align:justify'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";font-weight:normal'>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.<o:p></o:p></span></h2><h2 style='text-align:justify'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";font-weight:normal'>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.<o:p></o:p></span></h2><h2 style='text-align:justify'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";font-weight:normal'>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.<o:p></o:p></span></h2><h2 style='text-align:justify'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";font-weight:normal'>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.<o:p></o:p></span></h2><h2 style='text-align:justify'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";font-weight:normal'>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.<o:p></o:p></span></h2><h2 style='text-align:justify'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";font-weight:normal'>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 <i>isActive</i> 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).<o:p></o:p></span></h2><h2 style='text-align:justify'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";font-weight:normal'>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 <i>isActive</i> status at the start of the scene graph traversal.<o:p></o:p></span></h2><h2 style='text-align:justify'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";font-weight:normal'>Roy Walmsley<o:p></o:p></span></h2></div></body></html>