[x3d-public] [x3dom-developers] updated X3D node, statement inventory spreadsheets: X3DOM node addition recommendations
Don Brutzman
brutzman at nps.edu
Sat Sep 2 08:01:46 PDT 2017
Thank you for snapshot analysis Andreas, very helpful.
Responding to your points - here is a more detailed rationale showing why X3D profile, CoordinateDouble, and event-utility support all have significant value.
Broad usage of X3D on the Web means that authors have stable and consistent palettes of nodes (profiles) they can work with, without worrying about versionitis of which player might (or might not) work.
The X3D profiles have all been arrived at by working group + community consensus - what makes sense for common authoring use cases, and what corresponding components makes sense for implementing X3D players in a modular fashion. They were carefully refined to achieve the best balance of usefulness.
This successful approach for X3D extensibility provides benefits to
a. authors, who can label a scene's complexity with profile and optional component statements;
b. developers, who get a coherent architecture to align with and implement;
c. end users, who get consistent cool content that is widely playable.
CoordinateDouble was indeed introduced as part of NURBS Component, but is also implements abstract type X3DCoordinateNode, which in turn is used by IndexedFaceSet, IndexedLineSet, LineSet, PointSet and the *Triangle nodes.
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html
Given our steady emphasis to build support for 3D printing and 3D scanning, widely used implementations such as X3DOM should not restrict or discourage content creators from using double-precision data when creating meshes.
On 9/1/2017 8:37 PM, Andreas Plesch wrote:
> CoordinateDouble for x3dom would be a bit pointless but easy to implement as a CoordinateDouble.js implementation would be identical to Coordinate.js, except for the node name. No other files would need to be touched.
Glad to hear that you think it is easy to implement. 8)
For X3DOM developers, and for those considering providing further support for X3DOM developers, an even more important reason to add CoordinateDouble.js at this point is to demonstrate that the X3DOM community can indeed work together effectively to add X3D nodes. It has been a looooong time since the last node was added to X3DOM.
Wondering: in addition to the initial implementation you describe, is any further work needed to integrate CoordinateDouble within X3DOM? Perhaps in other node lists or profile-support code up at the top level?
It is good to see that X3DCoordinateNode.js is implemented already, so hopefully the infrastructure within concrete nodes (IFS ILS PointSet etc.) is already in place. For example, PointSet looks to be already configured correctly:
https://github.com/x3dom/x3dom/blob/master/src/nodes/Rendering/X3DCoordinateNode.js
https://github.com/x3dom/x3dom/blob/master/src/nodes/Rendering/PointSet.js
==========================================================================
[lines 32..40]
/**
* Coordinate node specifiying the vertices used by the geometry.
* @var {x3dom.fields.SFNode} coord
* @memberof x3dom.nodeTypes.PointSet
* @initvalue x3dom.nodeTypes.X3DCoordinateNode
* @field x3d
* @instance
*/
this.addField_SFNode('coord', x3dom.nodeTypes.X3DCoordinateNode);
==========================================================================
> It is part of the Nurbs component which otherwise would require substantial effort to realize.
Agreed. Nurbs usage likely needs to be more widely supported before it becomes a higher priority in a future. Of course, if it is indeed straightforward to add X3D nodes to X3DOM, then adding CoordinateDouble.js encourages such work!
> The event utilities just feel like not a good fit for a declarative style but probably could be implemented if there is a real demand. They do not seem to be used much since generally it is more natural to use a x3d or dom script for logic. Is there a convincing use case/example somewhere to promote them ? Potential users understand routing and logic but do not want to bother with scripting. Perhaps a small group but who knows.
They definitely have value and reduce scene complexity. They further make it simpler for authors and higher-level tools to build animation/interaction event chains. They also avoid simple script-authoring bugs which are easy to fall into (and sometimes maddening to debug).
Given X3DOM's historic ambivalence about X3D/HTML scripting, avoiding the need for scripting in X3DOM would seem to be a convincing motivator right now.
I've suggested the event utilities component as next step because they are well defined, they are conceptually/computationally quite simple, and multiple open-source implementations are already available.
Additionally, if there are any tricky bits involved getting new nodes and a new component to work, that is good to discover! The extension process needs to be included in the X3DOM documentation, so that addition of prose might be accomplished as well during this task.
Once again, can we show that it is straightforward to add nodes and components to X3DOM? This encourages further development and further investment for X3DOM.
> I do not think x3dom's goal is to have complete node coverage.
It is a goal of the X3D Working Group (and no doubt many other individuals) to use X3DOM and Cobweb as implementation of X3D version 4.
Perhaps even more valuable, each X3D node and component that gets added will enable further cool content rendered by X3DOM.
Getting to the X3D Immersive Profile (equivalent to VRML97, umm 20 years old now) certainly seems reasonable for advanced technology like X3DOM.
> In fact, there was an attempt to define a special profile which would fit x3dom.
Not sure what this means, please explain.
Usually the primary value of profiles is to provide a common use-case authoring palette, producing content that works widely for authors, developers and end users.
> Although regrettably there is no developer documentation it is not hard to add functionality since the code is open and fairly well organized though aging at this point (some DOM methods it uses are deprecated for some time). X3dom is easy and fun to hack, mostly by overriding methods. Try things on glitch or jsfiddle.
cool! 8)
> On the other hand there is quite a bit of extra functionality in x3dom which should inspire standardization or more widespread implementation in other viewers. CommonSurfaceShader or turntable navigation comes to mind.
Enthusiastically agreed. Wondering who will propose these and other good innovations for broad adoption in the X3D version 4 Specification?
Advancing these nodes and modes is an excellent opportunity for individuals in the X3DOM community to influence X3D evolution, once again to everyone's benefit on the Web.
> For reference:
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/nurbs.html#CoordinateDouble
>
> Andreas
Again thanks Andreas. I hope that others are similarly encouraged by your insights to keep building up X3DOM, it is a powerful resource.
> -----Original Message-----
> From: Don Brutzman <brutzman at nps.edu>
> To: x3dom-developers mailing list <x3dom-developers at lists.sourceforge.net>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> Sent: Fri, Sep 1, 2017 09:21 PM
> Subject: Re: [x3dom-developers] updated X3D node, statement inventory spreadsheets: X3DOM node addition recommendations
>
>
> No doubt many people share the concern that X3DOM development, while actively continuing, has not added support for missing X3D nodes in a long while.
>
> In years past, community source-code contributions for new nodes in X3DOM always seemed to require updating by insider experts.
>
> Am wondering if remains difficult to add new X3D nodes to the primary X3DOM build? Making that task easier likely has great value.
>
> Towards that end, recommend the following progressive priorities to improve X3DOM node support towards X3D Immersive profile (essentially VRML97 capabilities).
>
> a. CoordinateDouble. Hopefully just a simple variation of Coordinate node. (Note that all floating-point values in Javascript have double precision.) Adding this simplest-possible variation will reveal what other X3DOM files have to be modified to recognize a new node.
>
> https://doc.x3dom.org/developer/x3dom/nodeTypes/Coordinate.html
>
> https://github.com/x3dom/x3dom/tree/master/src/nodes/Rendering
> https://github.com/x3dom/x3dom/blob/master/src/nodes/Rendering/Coordinate.js
>
> b. Event utilities: simple input-output type conversion algorithms.
> BooleanFilter
> BooleanSequencer
> BooleanToggle
> BooleanTrigger
> IntegerSequencer
> IntegerTrigger
> TimeTrigger
>
> EventUtilities component is not found in source tree,
> https://github.com/x3dom/x3dom/tree/master/src/nodes
>
> X3D Abstract Specification, Event Utilities component
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/utils.html
>
> Basic Examples Archive: example Javascript proto implementations
> http://www.web3d.org/x3d/content/examples/Basic/development/EventUtilityPrototypesIndex.html
> http://www.web3d.org/x3d/content/examples/Basic/development/EventUtilityExamplesIndex.html
>
> Applying and improving developer documentation for new nodes would be further important to accomplish at the same time. Not seeing a "How to Add a Node" section, however...
>
> X3DOM Developer API Documentation
> https://doc.x3dom.org/developer/index.html
>
> c. Prototype declarations and instances. As ever, prototypes remain fundamental and are a key part of extensibility, literally the "X" in X3D.
>
> There have been on-again/off-again efforts to define and implement a Prototype Expander algorithm as a preprocessor for X3D players. Seems like a good time to resume working at this.
>
> https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/MaterialModulatorPrototypeExpandedIndex.html
> http://web3d.org/pipermail/x3d-public_web3d.org/2016-July/004982.html
> and many follow-on threads, steadily progressing that work, especially
>
> Source is somewhere in:
> https://github.com/coderextreme/X3DJSONLD
>
> ... and so on. Possible?
>
> It will be great if some X3DOM developers might "step up" to show that node addition is do-able.
>
> Hopefully this list helps triage simple/moderate/advanced work that is needed.
>
> Have fun with X3DOM! 8)
>
>
> On 9/1/2017 5:31 PM, Don Brutzman wrote:
> > Am happy to report improvements and updates to the X3D node + statement inventory spreadsheets:
> >
> > http://www.web3d.org/specifications/X3dNodeInventoryComparison.xlsx
> > http://www.web3d.org/specifications/X3dNodeInventoryComparison.pdf
> >
> > Updates include readability improvements and addition of view3dscene (Castle Game Engine) support.
> >
> > Some interesting statistics follow, also attached in image.
> > =====================================================================
> > X3D Abstract Specification Cobweb Castle X3DOM X3D-Edit Xj3D
> >
> > Supported nodes and statements: 73% 57% 61% 87% 68%
> > (251 total, X3D specification) 182 144 154 218 171
> >
> > Unimplemented nodes: 69 93 97 33 80
> >
> > needed for HTML5 support goals
> > * required for X3D Immersive all all 19 all 2
> > * suggested for HTML5 support 2 14 13 all 5
> > * priority nodes missing: 2 14 32 0 7
> > =====================================================================
> >
> > Am willing to add others, now that spreadsheet refactoring permits it. Please send an alphabetized verified list of supported nodes.
> >
> > Have fun with X3D!
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> x3dom-developers mailing list
> x3dom-developers at lists.sourceforge.net <mailto:developers at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/x3dom-developers
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/brutzman
More information about the x3d-public
mailing list