[x3d-public] NIST conformance example behaviour
Joe D Williams
joedwil at earthlink.net
Thu Jan 26 05:55:27 PST 2017
I don't get why you say that the USE node in the script is another
instance of the DEFed node. Whatever the USEd node is, it has no
lifetime and only serves during script execution.
For directOut, the script needs to read or change the DEFed node
filelds, not create a copy, change it, then replace the original. So,
the standard should not infer that the USEd node is an instance of
anything. It is just a replacement for Route(s) and never needs to
actually be an entity in the scenegraph.
Thanks,
Joe
----- Original Message -----
From: "Roy Walmsley" <roy.walmsley at ntlworld.com>
To: "'Don Brutzman'" <brutzman at nps.edu>; "'Patrick Dähne'"
<patrick.daehne at igd.fraunhofer.de>
Cc: "'Andreas Plesch'" <andreasplesch at gmail.com>; "'X3D Graphics
public mailing list'" <x3d-public at web3d.org>
Sent: Thursday, January 26, 2017 2:46 AM
Subject: Re: [x3d-public] NIST conformance example behaviour
Hi all,
Patrick, many thanks for your further comment. As Don said, we did
discuss this at the X3D WG meeting yesterday. It is a difficult point
to get technically correct in the standard. You are right to point out
that the text in the standard needs to be precise.
It is worth reproducing the example here. It helps to consider what is
going on. So, here is the listing for the XML encoding, minus the
header information:
<Scene>
<Background groundAngle='1.57' groundColor='0 0.5 0 0 0.5 0'
skyColor='0 0 1'/>
<Viewpoint description='Front View'/>
<NavigationInfo DEF='NAV1'/>
<Transform>
<TouchSensor DEF='TOUCH' description='touch to toggle light
switch'/>
<Shape>
<Appearance>
<Material/>
</Appearance>
<Box/>
</Shape>
</Transform>
<Script DEF='LIGHTSWITCH' directOutput='true'
url='"headlight_range.js"
"http://www.web3d.org/x3d/content/examples/ConformanceNist/BindableNodes/NavigationInfo/headlight_range.js"'>
<field accessType='initializeOnly' name='nav1' type='SFNode'>
<NavigationInfo USE='NAV1'/>
</field>
<field accessType='inputOnly' name='toggle' type='SFBool'/>
</Script>
<ROUTE fromField='isActive' fromNode='TOUCH' toField='toggle'
toNode='LIGHTSWITCH'/>
</Scene>
Let’s consider some terminology, as it applies to this example.
The bindable node in question is the NavigationInfo node with the DEF
name “NAV1”. This node also appears as a child of the user-defined
SFNode field ‘nav1’ in the Script node, where it is USEd. Of course,
as the standard 19775-1 subclause 4.4.3
(http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#DEFL_USESemantics)
states, the USE reference is not a copy, but a reference to the
original definition. So, nodes are never multiply instanced, which is
contrary to what the text says in subclause 7.2.2
(http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#BindableChildrenNodes).
This was, in fact, the reason that the Mantis issue 749 was raised,
where the original proposal was to change “multiply instanced” to
“multiply referenced instance”.
However, this node does appear multiple times in the scene graph. User
defined fields of a Script node are treated the same as all the other
built-in fields, in terms of instantiation. There is nothing special
about them. So, the NavigationInfo node does appear in the scene graph
as a multiply referenced node instance. When an implementation loads
this file, it will create one instance of the NavigationInfo node.
That instance will be referenced by whatever mechanism in the
implementation is used to keep track of root nodes, and also by the
Script node field ‘nav1’. We conclude, therefore, that the
NavigationInfo node will appear twice in the scene graph hierarchy.
This, therefore, cannot be used as the differentiator.
What about ‘traversal’. What do we mean by that? When does it occur? A
scene may be traversed for multiple reasons. For example, it could be
for rendering, or determination of a bounding box, or for searching,
or for counting polygons, to name but a few. All these involve scene
graph traversal. What happens in a Script node in these cases? This
question can be answered by asking when the script is activated.
Referring to subclause 29.2.2
(http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/scripting.html#Scriptexecution)
we see that the primary cause of activation of a Script node is the
receipt of an event, although it may also be activated on
initialization and shutdown (Note: we won’t get bogged down by
asynchronous scripts here). There is no other source of activation. So
we conclude it does nothing in response to direct scene graph
traversal for purposes such as rendering.
In summary, a Script node can be thought of as an event handling node.
Hence, in order to enable event handling using it’s directOutput
mechanisms, it must be able to reference other nodes. There is only
one mechanism to accomplish this. And that is USE. So, Script nodes
have to be an exception to the rule relating to multiply referencing
bindable nodes. With this in mind we tried to add text to the standard
to permit this exception. Perhaps, with further consideration, we can
improve the presentation of this, remarking on the exception directly
in the paragraph with the restriction, so that the exception
immediately follows, and is associated with, the restriction.
All the best,
Roy
-----Original Message-----
From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of
Don Brutzman
Sent: 26 January 2017 06:28
To: Patrick Dähne <patrick.daehne at igd.fraunhofer.de>
Cc: Andreas Plesch <andreasplesch at gmail.com>; X3D Graphics public
mailing list <x3d-public at web3d.org>
Subject: Re: [x3d-public] NIST conformance example behaviour
Sincere thanks for your follow-up note Patrick.
On 1/25/2017 4:50 PM, Patrick Dähne wrote:
> Hello Don,
>
>> "A Script node with a field containing a USE reference to a
>> bindable node has the ability to bind a node directly by changing
>> the value of the bind field. Setting the bind value is equivalent
>> to receiving a set_bind event.“
This statement was the result of 20-30 minutes careful discussion on
the weekly teleconference today.
I should have also noted that it was refined and documented as part of
Mantis issue 749, which was previously submitted. Web3D Consortium
Member access on the website is necessary to view these issues.
Mantis 0000749: 7.2.2 Bindable children nodes - Amend
prose
<http://www.web3d.org/member-only/mantis/view.php?id=749>
http://www.web3d.org/member-only/mantis/view.php?id=749
It seems to me that most everything said by everyone on this topic
(both email and teleconference) has essentially agreed on
functionality: that a Script field USE node does not get processed as
part of the scene-graph traversal, nor does it get bound simply by
being referenced as an SFNode field. We carefully discussed the
specification prose today to ensure that all cases were considered.
Interestingly the participants (Dick Roy Joe Leonard Vince and myself,
maybe Nicholas was still with us) looked quite closely at the exact
same sentence identified by you. We tried a few prose variations
along the lines of what you are suggesting as well. We decided
eventually that the words there were still the best we could achieve.
Perhaps your phrasing is more helpful, but functionality is agreed
upon at least.
So, for your question below, why do we want to add this additional
sentence quoted at the top of this message? Continued review of
paragraph 7.2.2 steps (a) through (i) describes binding behaviors on
the basis of events being received. The case of a Script node with a
field USE reference and directOutput='true' which subsequently sets
the value of 'bind' field during Script invocation wasn't addressed...
so this extra sentence was added for clarity, to explicitly note that
the bind/unbind operations are equivalent for event access and direct
access.
I hope this helps explain the additional sentence.
Of note is that the in-person discussions are really helpful.
Interpreting the specification prose can be a tricky business! We do
our best to listen to every option together and achieve concise
descriptions. We also reference the email thread and every direct
suggestion in Mantis for future reference as well. Also essential is
the presence of a good example scene with agreed-upon semantics for
rendering and user interaction.
Since Fraunhofer is a member you are of course welcome to join. If
you or anyone else wants to propose a further improvement, we will be
happy to schedule a good time for that. Member connection information
is online, non-member invitations are not a problem for these topics.
<http://www.web3d.org/member/teleconference-information>
http://www.web3d.org/member/teleconference-information
So... lots of careful listening and due diligence. We are further
paying close attention to using Mantis when performing the
corresponding X3D specification editing in Github.
Please check out the mantis issue if you still have concerns, and
let's review again at a good time for you (and Andreas as well).
There is little value in "winning" an email debate, rather we always
want to achieve common ground, shared understanding and (hopefully!)
consensus so that all implementations can consistently handle X3D
content. So these efforts are all worthwhile, especially for the
special semantics of bindable nodes, Script execution and DEF/USE
referencing.
More specification issues await... but we are certainly operating at a
greater level of working group + community knowledge than ever before.
Apparently benefits are cumulative! 8)
Hope we're looking ~ acceptable now. Further improvement always
welcome. Looking forward to continuing progress together with all of
X3D, again thanks to all involved.
v/r Don
> Sorry, I did not want to resume that nitpicking discussion, but you
> are taking the wrong direction :-(
>
> My point is:
>
> 1. There is this sentence in section 7.2.2 of the specification:
> „The results are undefined if a multiply instanced (DEF/USE)
> bindable node is bound.“
>
> 2. In the NIST example we exactly do have that case - a bindable
> node (DEF nav1 NavigationInfo) that is multiply instanced - once as
> a child of the (implicit) root Group node, and once as a child of
> the Script node.
>
> 3. => According to the specification, the example is undefined.
> Q.E.D.
>
> I do not claim that there *actually* is a problem with the NIST
> example, I just say that *formally* the example is invalid because
> of that sentence in section 7.2.2 of the specification.
>
> So what is the rationale behind that sentence? That is explained in
> the Annotated VRML97 Reference. The browser needs to determine the
> transformation of the currently bound Viewpoint, Background or Fog
> node. The NavigationInfo node actually is a special case, because
> for that node the transformation of the currently bound Viewpoint is
> taken. Now, when you DEF/USE a bindable node (or any group node
> above a bindable node), you have to take care that you do not add
> the bindable node more than once to the transformation hierarchy,
> because otherwise the browser cannot decide which of the
> transformations to take. Adding a bindable node to the Script node
> does *not* add it to the transformation hierarchy (see section 4.3.5
> of the specification) - that is why there is no problem in the NIST
> example.
>
> So, what to do with that awkward sentence in section 7.2.2? My
> recommendation would be to replace it with a sentences like this: „A
> bindable node may only be bound when it is part of the
> transformation hierarchy exactly once, otherwise the result is
> undefined.“ But I’m sure a native english speaker can word that much
> better.
>
> Bye,
>
> Patrick
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br
<mailto:brutzman at nps.edu> 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> http://faculty.nps.edu/brutzman
_______________________________________________
x3d-public mailing list
<mailto:x3d-public at web3d.org> x3d-public at web3d.org
<http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
http://web3d.org/mailman/listinfo/x3d-public_web3d.org
--------------------------------------------------------------------------------
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
More information about the x3d-public
mailing list