[x3d-public] motivations and potential renaming of OM4X3D as X3D Unified Object Model (X3DUOM)

[Leonard Daly]

Don et al,

I appreciate the construction of an object model for X3D as laying a 
strong foundation for understanding the structure of the existing 
standard and providing a path for future evolutionary development of the 
standard.

I do have the following concerns:
1) The name is very close to an existing and well-known product - X3DOM. 
In fact this name looks like a typo of that. Unless a major education 
effort is made, there will be confusion when people see just the name; 
beside the verbal use will sound like "X3 dumb". Since the Consortium is 
very resource-limited, I suggest the (significantly less) effort be put 
into developing a new and non-conflicting name.

2)  No work has been done to identify what features should be in a 
web-based 3D/VR/xR graphics standard. This starts with a basic premise 
that the standard needs to support 3D (and other) graphic capabilities 
in a specified collection of environments. Then the concept requirements 
are developed and refined so that they meet the usual requirement 
conditions (consistent, complete, etc.) plus there exists a path from 
the existing situation (probably X3D V3.3) to the desired end goal. Not 
doing this reach step leads to incremental enhancement of the existing 
standard. We know that incremental enhancement is insufficient because 
there is minimal adoption of X3D compared to other standards that have 
been around a shorter amount of time - glTF, WebGL, THREE.js, etc.

3) In my conversations with Mike Russalesi, I understood his interest in 
developed DLLs and other libraries that would read and write X3D to 
compete with FBX (primarily) and glTF (by extension). X3D does a lot 
more than FBX and a bit more than glTF, especially in the area of user 
interaction. Developing an Object Model for V3.x and applying that to 
the future (V4+) will not address the need to I/O libraries and the need 
and requirements for an interchange format. For example, X3D and glTF 
both include lights. In cinematic computer graphics (the kind used for 
movies, TV, and games), lighting of all kind is the responsibility of 
the lighting technical director. It does not belong with the modeler or 
animator (though on small productions these may be the same person with 
different responsibilities). A modeler who insists that his/her lighting 
be used will not have a job for very long.

4) As I understand object modeling in computer science, it is done 
before the specification is developed. I have never heard of an object 
model being auto-generated from an XML Schema from a specification 
document.  The (ASCII-Art) diagram developed by Joe was originally done 
to make sure that the interfaces and node hierarchy was consistent and 
complete, and to illustrate the relationships between the various nodes 
(abstract and concrete) and interfaces. The source for this diagram was 
the specification text, not the other way around. I do not remember ever 
trying to fit X3D into DOM (especially since DOM is an API), though it 
may have been an effort not part of the X3D WG.

5) Game engines for at least the last 10 years have used an Entity 
Component System (ECS). ECS was developed in the early 2000's because of 
performance issues with handing extensive object hierarchy. ECS is how 
Unity, Unreal, and A-Frame work. It drives their internal data structure 
and run-time. Without some sort of explanation of how X3D can be used in 
an ECS, it will be dismissed by the entire game community. [Note that 
THREE more closely aligns with WebGL and is more object-oriented.]

6) The Consortium is very resource limited. It has having difficulty 
keeping up. One of the recommended standards is over 10 years old 
(19777-2) and other one is only at Committee Draft (CD) text level. The 
graphic capability of X3D is significantly behind the industry for 
appearance (no bump maps, occlusion maps, opacity maps, displacement 
maps,...), animation using GPUs, multiple lighting models, and 
physically based rendering. Creating more work, especially in the area 
of ISO standardization will totally exceed the capacity of the 
volunteers who do this work. There is significantly less work involved 
in producing a Consortium standard, so that might be more achievable.

7) I believe that the Consortium should clearly define what it wants to 
achieve and develop a plan (including schedule and budget) necessary to 
get there. Work that is not specifically on the plan that does not 
impede the plan is great, but cannot use Consortium resources that 
interfere with work on the plan. This plan needs to be approved by the 
BOD so everyone is on board. It can then be used as a selling point for 
membership because it is clear what is being worked on and what is the 
schedule.


Leonard Daly




> Earlier this week I had an excellent in-depth discussion with Mike 
> Russalesi on Object Model for X3D.  Some of you may already know that 
> Mike has provided strong encouragement towards creating DLLs for X3D.  
> Here is a recap with further analysis and some excellent go-forward 
> options.
>
> 1. *Problem*. The existing X3D abstract interfaces in the X3D 
> Specification are sufficiently general to map to a variety of 
> programming languages, but unfortunately are incomplete.  While all 
> nodes and fields are included with strong typing throughout, X3D 
> statements (such as ROUTE, IMPORT/EXPORT, PROTO etc.) are not 
> specified in an object-oriented manner.  This occurred because the 
> original design of X3D was focused on code blocks within the Script 
> node, and were not looking at more-general goals like 
> HTML-page-inclusion or programmatic-construction of full X3D models.
>
>     X3D Abstract Specification: 4.4.2 Object model
>     http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Objectmodel 
>
>
> An ASCII-art diagram originated by Joe Williams shows all interfaces 
> and nodes (but no statements) and is found at
>
>     X3D Abstract Specification: 4.4.2.3 Interface hierarchy
>     http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#InterfaceHierarchy 
>
>
> 2. *Motivation*. Our original efforts to fully specify all aspects of 
> X3D for any object-oriented use were first inspired by mapping 
> everything to fit inside HTML5 Document Object Model (DOM).  This 
> early effort identified a number of gaps.  When we continued to work 
> on a JSON encoding for X3D, these same issues were cast in sharp 
> relief because JSON is exceedingly strict and thorough (hence the "O" 
> in JSON).
>
> 3. *Approach*.  As a result of these gaps, much discussion on the 
> mailing list and much effort by Roy Walmsley, John Carlson and myself 
> was applied.  The X3D XML Schema as further annotated to list all 
> fields with accessType inputOnly or outputOnly (which cannot by 
> themselves appear in an XML or VRML model).  Strong typing and a 
> consistent abstract interfaces were also applied to previously ignored 
> X3D statements.  Corresponding implementations in JavaScript and Java 
> have been built to demonstrate the soundness of these improvements. 
> This work is described in detail as part of the Web3D 2017 Conference 
> Tutorial.
>
>     Figure:  Creation and Autogeneration of Object Model for X3D
>     http://www.web3d.org/specifications/X3DUOM/ObjectModelForX3dCreation.png 
>
>
>     Design tutorial: Object Model For X3D (OM4X3D) Master Class, Web3D 
> 2017
>     http://www.web3d.org/specifications/X3DUOM/ObjectModelForX3dMasterClassWeb3dConference2017June7.pdf 
>
>
> 4. *Insight*.  As originally hoped, many benefits and much progress 
> has flowed from this effort.  In our discussion, it became clear that 
> these X3D object model efforts are
> a. making it progressively easier to define closely matching APIs in a 
> variety of programming languages,
> b. coherently simplifying and streamlining X3D, not creating "node 
> bloat" or further variations, and
> c. defining a _unified_ object model that makes X3D widely applicable 
> in many domains and applications, using consistent APIs. (Thanks Mike!)
>
> 5. *Suggested steps*.  The work is converging nicely.  More to follow:
> a. Adding different programming-language bindings to X3D, as shown in 
> the recently proposed Specification Relationships diagram update, is a 
> straightforward matter.
> b. As X3DJSAIL has shown, such APIs can even be automatically created 
> - meaning that future X3Dv4+ evolution is easily accommodated without 
> error.
> c. Renaming the (awkward) Object Model for X3D (OM4X3D) as X3D Unified 
> Object Model (X3DUOM) better describes these powerful benefits.
> d. Object model progress should be part of X3Dv4 Abstract 
> Specification, updating and completing the existing interface hierarchy.
> e. Corresponding updates should be applied to 19775-2, the Scene 
> Access Interface (SAI) Abstract Specification.  We're going beyond 
> Script node.
> f. Development of programming-language APIs for X3D using JavaScript, 
> Java, C, C++, C# and Python can continue to proceed in parallel.
>
> Given the many efforts to date, renaming opinions by other 
> contributors to the X3D object model are especially welcome.
>
> I've taken the liberty of applying this potential rename so that we 
> can see how it looks.  Improvements and informed consensus are always 
> welcome.  A first-draft page collecting the current set of related 
> assets can now be found at
>
>     X3D Unified Object Model (X3DUOM)
>     http://www.web3d.org/specifications/X3DUOM.html
>
>     X3D Graphics Standards: Specification Relationships (proposed update)
>     http://www.web3d.org/specifications/X3dSpecificationRelationships.2017August11.png 
>
>
> More slidesets and resource links will be added.  For example, Dr. 
> Myeong Won Lee has an excellent Unity application running on a mobile 
> phone that uses the draft X3D SAI for C++ to load H-Anim characters 
> and X3Dv4 Motion nodes that provide BVH mocap animations.  Dr. Masaki 
> Aono has also been experimenting with Python design patterns, we hope 
> to compare these constructs to the pyjnius transcoding produced by 
> John Carlson.   Additional experiments welcome.
>
> It is interesting to consider how this effort has streamlined and 
> consolidated X3D, reducing mismatches and unifying different 
> approaches coherently.  I think that the object model unifications can 
> be considered as useful progress in streamlining and modernizing X3Dv4.
>
> All discussion welcome, what do you think?  Looking forward to further 
> comment plus continuing dialog during X3D Working Group meetings.
>
> all the best, Don


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170819/2dc5c314/attachment-0001.html>