[x3d-public] NIST conformance example behaviour

Andreas Plesch andreasplesch at gmail.com
Tue Jan 31 08:23:56 PST 2017

Hi Don,

travel or even commuting can be a good time to jot down thoughts.

Well, I actually thought that I did come out a slightly different place.
Let's consider this example:

<Viewpoint DEF='vp1' />
<Transform DEF='holder' translation='1 2 3' />
<Script directOut='true'>
  <field name='vp1Reference' type='SFNode' accessType='initializeOnly'>
    <Viewpoint USE='vp1'/>
  <field name='holderReference' type='SFNode' accessType='initializeOnly'>
    <Transform USE='holder'/>
function initialize() {
  vp1Reference.position = new SFVec3f(11, 11, 11);
  //not allowed/undefined
  holderReference.addChildren = vp1Reference;

The viewpoint vp1 is bound by default. Then the script is allowed to modify
it, but not allowed to add it to the Transform node as it would lead to
undefined behaviour (which position to use?).

The question then is if this restriction needs to be spelled out more
clearly in the spec. than it already is since it may be hard to understand
why a script can use a script field only in a restricted fashion.
Personally, I had to be directed to the relevant sentences but I do not
have a clear preference for more or less words.

Here is another script example related to the points about instancing and

<Transform DEF='holder' translation='1 2 3' />
<Script directOut='true'>
  <field name='ShapeInstance' type='SFNode' accessType='initializeOnly'>
    <Shape> ... </Shape>
  <field name='holderReference'' type='SFNode' accessType='initializeOnly'>
    <Transform USE='holder'/>
function initialize() {
  //ShapeInstance exists now
  holderReference.addChildren = ShapeInstance;

I think it is up to the browser implementation when the ShapeInstance field
is instanced. Straightforward, perhaps more robust implementations may
create the node instance right when the script node is parsed but keep the
node object separate from the scene graph. Others may wait until it is time
to call initialize() (or another script function), only create the node
then and add it to the scene graph as a child of a grouping node.
Is this a correct understanding ?

Finally, in the world of shaders and I think OpenGL, the phrase
'instancing' , I believe, does not mean to create new copies (of
geometries) but often the ability to reference many times a single entity
for very efficient display of a large number of objects (particles, smoke).



On Tue, Jan 31, 2017 at 12:32 AM, Don Brutzman <brutzman at nps.edu> wrote:

> (on travel)
> thank you Andreas, i like the logic because it looks like it landed right
> where we did after much discussion/consideration.
> so getting the spec wording crisp and understandable remains (as usual) a
> worthy challenge.  :0
> adding one thing: when a method call invokes a method in an OO language,
> the parameters are typically references and not a new object with global
> scope.  so that is why it seems that a Script node's fields (field
> parameters waiting to be referenced and invoked) do not rise to the level
> of independent objects instantiated in the parent program.  Rather they are
> SFNode field references that give the script a reference handle to tickle
> the original node via directOutput value modification.  nor are they
> traversed with the rest of the scene graph, since a Script's field
> containing an SFNode support your listed options (a) and (b) listed below.
> so they do not meet any of the criteria that lead to binding.  So the
> fields are not traversed.
> hope this helps.  onward...
> On 1/27/2017 11:06 AM, Andreas Plesch wrote:
>> Since a Script node can add a new node to the scene graph, it also should
>> be able to place a USE reference to a node somewhere in the scene graph in
>> the same (three) ways that it can place a new instance of a node into the
>> scene graph.
>> This is where then USEd bindable nodes as Script SFNode field default
>> values need to be considered. Since such USE references to bindable nodes
>> are discouraged/undefined outside of script nodes, using scripts to place
>> such node references is also discouraged/undefined.
>> There is a question if this script restriction needs to be made explicit
>> in the bindable nodes/script spec. sections or if it is implicit in the
>> existing language.
>> So how can one access a bindable node's fields from within a script ?
>> A) without directOut: route out event from script to bindable node's
>> field; others ?
>> B) with directOut: route bindable node itself to XFNode script field
>> (perhaps as children field of a group wrapper) to script field; use SAI
>> holder[0].set_headlight = ..
>> or set bindable node USE reference as default script field value and use
>> field name in script (as in example)
>> To me the last method (as used in the example) does feel like a shortcut
>> or a trick because it would be the only situation where a USEd bindable
>> node is required, establishing a sort of exception to a simple rule. The
>> problem in a way is that if a bindable node USE reference can be created as
>> a script field default value, there may be an expectation/temptation by
>> authors to then place this USE reference into the scene graph in some way.
>> So maybe this needs clarification:
>> "A Script node may define a field containing a USE reference to an
>> existing bindable node. However, this USE reference may not be placed into
>> the scene graph (see bindable nodes)." How does that sound ?
>> Ok, this turned out not very concise after all. Thanks for reading
>> through to the end,
>> Cheers
>> Andreas
>> On Jan 26, 2017 10:43 AM, "Andreas Plesch" <andreasplesch at gmail.com
>> <mailto:andreasplesch at gmail.com>> wrote:
>>     Here are my thoughts and I will try to be concise since I agree that
>> this really is not a major matter.
>>     The script node is part of the scene graph but its position in it
>> does not matter. (So it is effectively always a root node).
>>     Some script nodes will have (custom) SFNode fields which can be
>> assigned a default value. There are many other nodes which have SFNode
>> fields such as Shape.
>>     Can a script node create an additional node in the scene graph, not
>> considering USE for a moment ? Yes, indirectly and directly:
>>     A) Either a Route needs to place the created nodes in an existing
>> 'holder' (group) scene graph node:  See
>>     http://www.web3d.org/x3d/content/examples/Basic/X3dSpecifica
>> tions/ECMAScriptSaiCreateNodesIndex.html <http://www.web3d.org/x3d/cont
>> ent/examples/Basic/X3dSpecifications/ECMAScriptSaiCreateNodesIndex.html>
>>     B) Or the script places the new node directly in the scene:
>>     initialize()
>>       // Create nodes directly in the parent scene
>>         scene = Browser.currentScene;
>>       // Add the SFNode field value to the scene
>>         scene.rootNodes[0] = ScriptSFNodeFieldValue;
>>     (is there an example ?   http://www.web3d.org/x3d/cont
>> ent/examples/Basic/ScriptConformance/CreateNodesFromPrototyp
>> eECMAScriptIndex.html <http://www.web3d.org/x3d/cont
>> ent/examples/Basic/ScriptConformance/CreateNodesFromPrototyp
>> eECMAScriptIndex.html> is close.)
>>     C) or directOut is used:
>>     USEdHolder.addchildren = ScriptSFNodeFieldValue; // or perhaps
>> USEdHolder.children.push(ScriptSFNodeFieldValue)
>>     So I do believe that a Script field of type SFNode with a (non USE)
>> default value creates an instance of this node which then can be
>> subsequently placed into the scene graph by the script or with a route.
>>     Ok, lets take a break. Continued later,
>>     Andreas
>>     Some discoveries:
>>     http://www.web3d.org/x3d/content/examples/Vrml2Sourcebook/Si
>> ggraph98Course/LoaderIndex.html <http://www.web3d.org/x3d/cont
>> ent/examples/Vrml2Sourcebook/Siggraph98Course/LoaderIndex.html> is a
>> mind bender since the script uses itself as a field value ....
>>     Phrasing: "Instancing" is used here:
>>     http://www.web3d.org/documents/specifications/19776-1/V3.3/
>> Part01/examples.html#Instancing <http://www.web3d.org/document
>> s/specifications/19776-1/V3.3/Part01/examples.html#Instancing>
>>     The annotated VRML reference which Patrick offered specifically
>> discusses how USE is supposed to represent the pointer concept. But
>> instancing was probably still used in VRML discussions.
>>     On Thu, Jan 26, 2017 at 1:27 AM, Don Brutzman <brutzman at nps.edu
>> <mailto:brutzman at nps.edu>> wrote:
>>         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
>> brutzman at nps.edu <mailto:brutzman at nps.edu>
>>         Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
>> +1.831.656.2149 <tel:%2B1.831.656.2149>
>>         X3D graphics, virtual worlds, navy robotics
>> http://faculty.nps.edu/brutzman <http://faculty.nps.edu/brutzman>
>>     --
>>     Andreas Plesch
>>     39 Barbara Rd.
>>     Waltham, MA 02453
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br
> 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/brutzma
> n

Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170131/8524af1d/attachment-0001.html>

More information about the x3d-public mailing list