[x3d-public] Nodes for V4; X3D Script and HTML script coexist; prototypes without embedded Script nodes

[Leonard Daly]

Edited to try to focus on comments that have a response.



> On 8/28/2016 9:32 PM, Leonard Daly wrote:
>> catching up....
>>
>>> Thanks for your continuing efforts. Feedback:
>>>
>>> a. Not clear what your motivation is.  What functionality does a 
>>> Macro node provide that isn't already available using Script and 
>>> Prototype definitions?  Getting clear about differences helps 
>>> getting clear about goals.
>>
>> X3D Script is not available in HTML as it is already being used.
>
> The X3D Script node is not the same as the HTML script element. So 
> there is no collision, only the need for precision when discussing 
> it.  Both coexist nicely already, as they have for two decades.

They exists in different spaces because X3D browsers that run in a web 
page (e.g., BS Contact) run as a plugin. X3D Script node never exists in 
HTML space because the name is the same (at least to an HTML parser) and 
the syntax is different.



>
> The Scene Authoring Interface (SAI) efforts for X3D (probably v3.0) 
> was able to successfully reconcile differences in JavaScript and Java 
> that were necessary under the VRML97 External Authoring Interface 
> (EAI).  In that way, the same class structures and programming 
> patterns were usable in author source code - an author could write the 
> same kind of X3D-related source code in JavaScript or Java, with event 
> updates and field updates still working consistently.
>
> Among multiple reasons, it is also good to note that HTML5 explicitly 
> supports the <object> tag for plugins, so we can expect that the 
> consistency of SAI is likely to still work across various forms of 
> invocation.  As ever, exploration and testing is advisable.
>
>> After repeated requests to X3D and X3D-Public mailing lists, no one 
>> could supply an example of a trivial PROTO (one without a Script 
>> node) that was not convenience definition.
>
> I repeatedly provided the Universal Media Materials examples in 
> response to your request, both on the email list and I also believe it 
> came up during a teleconference.
>
> These are found in the X3D Basic Examples archives.
>
>     http://www.web3d.org/x3d/content/examples/Basic/UniversalMediaMaterials 
>
>
> Sample declaration:
>
> <ProtoDeclare name='ArtDeco00' appinfo='UniversalMediaMaterials 
> prototype' documentation=' 
> http://www.web3d.org/x3d/content/examples/Basic/UniversalMediaMaterials 
> '>
>     <ProtoBody>
>         <Material ambientIntensity='0.25' diffuseColor='0.282435 
> 0.085159 0.134462' shininess='0.127273' specularColor='0.276305 
> 0.11431 0.139857'/>
>     </ProtoBody>
> </ProtoDeclare>

Unless I am serious missing something, this PROTO is a convenience 
definition (labeling) of a specific material with the name 'ArtDec00'.



>
> Another interesting scene that does not include a Script node can be 
> found in the same directory:
>
>     http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/HeadsUpDisplayPrototype.x3d 
>
>     http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/HeadsUpDisplayPrototype.html 
>
>
>     http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/HeadsUpDisplayExample.x3d 
>
>     http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/HeadsUpDisplayExample.html 
>
>

HeadsUp displays are a more interesting case; however, this is better 
handled in HTML because it is easier to do so.

> Looks like 5 more examples (5deepinternalroute.x3d 5deepnesting.x3d 
> def.x3d route_inside.x3d and simple.x3d) can be found in
>
>     X3D Example Archives: Conformance Nist, Miscellaneous, PROTO.
>     http://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/PROTO 
>
>
> Eight more scenes appear in
>
>     X3D Example Archives: VRML 2.0 Sourcebook, Chapter 31 - Prototypes
>     http://www.web3d.org/x3d/content/examples/Vrml2.0Sourcebook/Chapter31-Prototypes/ 
>
>
> Of those, most do no include Script.  Perhaps of special interest is 
> the SpinGroup prototype, which was originally proposed as a VRML 
> node.  Demonstrating this node as a prototype in VRML showed that 
> specification addition was not necessary.  The term commonly used in 
> those days was "avoiding node bloat" to keep the VRML vocabulary as 
> concise as possible, i.e. avoiding the addition of duplicative nodes.
>
>> I felt that the ability to define a set of nodes at initialization 
>> (parse-type) was useful. I added the ability to vary the parameters 
>> from one instance to the next as important to provide variability in 
>> the scene.
>
> ProtoDeclare field declarations, and ProtoInstance fieldValue 
> instances, can contain either simple types (MFVec3f etc.) or SF/MFNode 
> initializations.
>
> Thus prototypes have full expressivity to extend any node 
> functionality in X3D.
>
> ProtoInstance fieldValue insertions would be the right place to vary 
> parameters from one instance to the next.
>
> Similarly Inline IMPORT/EXPORT can pass initialization values that are 
> either simple types or node types, as singletons or as arrays.
>
> Hence the questions regarding how Macro compares and contrasts. 
> Differences hold the greatest interest.

In this implementation Macros add the nodes to the namescope of the 
Macro node. This does not happen for Inline nor PROTO.


>
>>> c. Previous efforts on NetworkSensor node, and the difficulties 
>>> encountered, may be worth considering:
>>>
>>> http://www.web3d.org/x3d/content/examples/Basic/Networking/
>>> http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionPrototypes.x3d
>>> http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionPrototypes.html
>>>
>>> http://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionNodes.html
>>
>> Communication between users (networking) is a useful area to 
>> investigate. I was involved in the previous attempt and remember many 
>> of the difficulties and different approaches that the WG had. In the 
>> end we were unable to define anything for the specification because 
>> the problem scope was not sufficiently well-defined and agreed-upon. 
>> Things in the HTML world have changed considerably since then and it 
>> would probably be useful to try to get that kind of communication 
>> going again. I do not know if it is appropriate to put that in X3D or 
>> better to handle external of X3D in (e.g.) WebRTC.
>>
>> I do not understand why it was brought up here. It is not a topic I 
>> brought up.
>
> Apologies for not expressing that relationship more clearly.  The 
> topic pertains because NetworkSensor is similar to Prototype in that a 
> player needs to create custom scene-graph fields, just as Prototype 
> declarations do.  Thus the design of NetworkSensor (which has 
> different goals that Macro) and its dynamic parameters seems quite 
> reasonable.  Unfortunately no successful implementations occurred 
> because all of the prototype implementations were inside player 
> codebases and the owners/principals didn't want to pursue it.  Even 
> so, given the greater number of options now, someone might want to 
> implement it.
>
> Hopefully the lessons learned from dynamic creation of X3D content by 
> NetworkSensor can also inform your design.


I do not believe it is appropriate for X3D to duplicate an existing 
functionality (e.g., WebRTC). Developing a support library to share 
(between browsers) various information, from scalar fields to node 
sub-trees is probably a better way to go.



-- 
*Leonard Daly*
X3D Co-Chair
Cloud Consultant
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160901/f30f3bf8/attachment.html>