[x3d-public] NIST conformance example behaviour
Joe D Williams
joedwil at earthlink.net
Fri Jan 27 16:56:22 PST 2017
> A) without directOut: route out event from script to bindable node's
> field;
Of course this is the simpe way to do it.
> B) with directOut: route bindable node itself to XFNode script field
with directOUt it is the same result except the node's field is set
directly.
No difference in functionality - both have the same result.
> To me the last method (as used in the example) does feel like a
> shortcut or
a trick
Not a trick really, just a not recommended way to avoid using
Route(s).
Joe
----- Original Message -----
From: "Andreas Plesch" <andreasplesch at gmail.com>
To: "Don Brutzman" <brutzman at nps.edu>
Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org>
Sent: Friday, January 27, 2017 11:06 AM
Subject: Re: [x3d-public] NIST conformance example behaviour
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>
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
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/conte
nt/examples/Basic/ScriptConformance/CreateNodesFromPrototype
ECMAScriptIndex.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 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/P
art01/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>
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
>
> 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
>
> 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
> 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
--------------------------------------------------------------------------------
> _______________________________________________
> 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