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

[Don Brutzman]

Thanks for several good insights Leonard.  I have responded to all your points, many of which are contentious but familiar, so that a balanced perspective is better reflected for everyone.

On 8/19/2017 7:11 PM, Leonard Daly wrote:
> 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".
Agreed that naming is important - for clarity and correctness and communication.  OM4X3D acronym is also a bit clumsy, but is not incorrect.

The key recent insight is the unifying nature of the X3D object model design.  "Universal" was also a suggested term but that seems much too encompassing, since there are many many approaches to 3D graphics - we never want to overstate.

X3DOM is wonderful and no education effort is needed regarding that, whatever new term gets used simply needs to be different.

It is always worth considering whether better phrasing and better acronyms are possible.  Thanks for doing that.

Success metric: you know you have chosen the right name when no one questions that name any more...

So far "X3D Unified Object Model" seems clearest, reasonably accurate, and least worst of several candidates.

> Since the Consortium is very resource-limited, I suggest the (significantly less) effort be put into developing a new and non-conflicting name.

I must continue to respond and disagree, this is not really an accurate point.  Strictly speaking, the Consortium is not resource limited since X3D version 4 activities are not directed by "top down" funding and not directly applying any labor resources to any of these development efforts.  There is not a resource choice or labor decision being made by funding administrators, as in a company or agency.  Rather: individuals and teams working towards compatible capabilities and consensus, in X3D Working Group and in larger community, is what drives all this work.

I don't plan on asking anyone to put "significantly less" effort into anything.  Many opportunities for X3D on the Web exist now, we should accelerate.

Wisdom of the group is essential.  Reviewing design and implementation progress on the mailing list is how we have progressed for the past 23 years.  Archived mailing list dialog is central to our decades of sustained success.  People sharing ideas is not something to avoid, rather sharing ideas is a fundamental benefit of participation.

The unified object model discussion shows how this progress helps advance all X3D future versions.  So there is no conflict of interest.

Can further member resources and commitments help?  Of course.  Web3D working groups all remain ready for further activity and growth.

*Our community and our consortium are only limited by our desire and abilities to make progress together.*

> 2)  No work has been done to identify what features should be in a web-based 3D/VR/xR graphics standard. 

As you well know, I think that this characterization remains quite incorrect and insulting/dismissive/divisive.

You are welcome to your opinion, but continually repeating it without acknowledging responses and facts is problematic.

> 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.

Much much design work, much much implementation work, and much much communication has been accomplished.  For instance, deliberately separating X3D v4.0 HTML5/DOM and X3D v4.1 MAR indeed lets all progress continue compatibly, especially without blocking or being confounded by the differing maturity and sophistication of each.

Recent presentations at Web3D 2017 Conference and much carefully evolved working-group documentation again describes X3D v4.0 and v4.1 paths + alternatives in much detail.

Each week provides reports of further X3D adoption.  Such steady growth has been occurring for quite some time.

The Web3D process produces progress.  Improvements to current efforts are always welcome.

> 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.

DLLs are a special form of object-oriented implementation.  It appears likely that creation of X3D SAI DLLs will be possible once we have C++ and C# language bindings.

	Wikipedia: Dynamic-link library
	https://en.wikipedia.org/wiki/Dynamic-link_library
"Dynamic-link library (or DLL) is Microsoft's implementation of the shared library concept in the Microsoft Windows and OS/2 operating systems."

FBX is a many-versioned commercial product and one of many formats for which converters already exist.  Perhaps further opportunities await.

	Wikipedia: FBX
	https://en.wikipedia.org/wiki/FBX
"FBX (Filmbox) is a proprietary file format (.fbx) developed by Kaydara and owned by Autodesk since 2006. It is used to provide interoperability between digital content creation applications. FBX is also part of Autodesk Gameware, a series of video game middleware."

Our X3D converters list currently includes 36 independent capabilities (and some include FBX paths).  More are out there, additions are appreciated.

	X3D Resources: Conversions and Translation Tools
	http://www.web3d.org/x3d/content/examples/X3dResources.html#Conversions

Process note: anyone really wanting close comparison between FBX and X3D features might make some excellent contributions, hope that happens.  Meanwhile we'd have to carefully ensure that Web3D IPR policy isn't violated along the way.  Not a new point or a blocker - we just need to be careful.  Perhaps Autodesk can be convinced to contribute as a member - why not, worth trying, it is a big Web.

	Web3D Consortium Intellectual Property Rights (IPR) Policy
	http://www.web3d.org/sites/default/files/page/Join%20the%20Web3D%20Consortium/Web3D_IPR.pdf

Much current and prospective X3D progress with respect to glTF has been reported on this list from recent Web3D 2017, SIGGRAPH and ISO conferences this summer.  Two very nice aspects of the advanced capabilities in the glTF lighting model are that it provides the same physically based material capabilities proposed by Fraunhofer a year ago, and that it is widely supportable in software and hardware thanks to Khronos member efforts.  Upgrading X3D 4.0 lighting and appearance to match glTF 2.0 appears to be a great strategy for progress; given glTF announcements at Web3D 2017 and SIGGRAPH, the X3D working group is finally in position to consider how to best integrate such improvements in the X3D specifications.

> 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.

DOM is the Document Object Model, and DOM is the reason that HTML4 finally succeeded in resolving HTML4/XHTML encoding issues to produce HTML5 after 14 years of effort.

So, of necessity, aligning X3D v4 with HTML5 has to align an X3D object model with DOM.  Reading HTML 5 Recommendations makes this very clear.

These are not new points.  Aligning object models remains fundamentally important for full HTML5 integration of X3D.

It remains exciting to see how the object modeling work provides an innovative way that helps to meet these important challenges.

> 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.]

See next messages in thread regarding ECS and object model similarities & capabilities.  They don't seem to be mutually incompatible.

As far as I can tell, everything in game engine development is based on dismissing and rejecting (and debatably exceeding) other approaches.  That is the business model, for decades now.  YMMV.

> 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.

Hmmm not seeing anything on your list here that isn't on the X3D work list already.

Please review our design mandates on backwards and forwards compatibility, components and profiles, X3D v4 proposed capabilities, and standards development process.  It defines what Web3D Consortium is, how the process works, what is required for adding something new (e.g. prose + code + examples) to X3D version 4.  Web3D Consortium is a non-profit organization with many excellent goals and capabilities.  We are not competing with companies.  The object model issues are not creating more work, instead we are diligently working through necessary details of agreed-upon strategies.

Most of all, X3D progress is undeniable.  Two excellent and improving render implementations (Cobweb and X3DOM) are pulling us through every issue.  Many other tools are available and evolving to match other necessary X3D evolution activities.  3900 example scenes with multiple round-trip unit tests are a major asset.  Quite an ecosystem actually.

> 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

Many dedicated individuals have accomplished a lot for Web3D Consortium despite small levels of funding.  Other activities are important too.

If you truly want schedule and budget, then please review cause and effect relationships:

	More Web3D membership -> funding -> resources -> mission priority balancing -> Board decisions -> labor -> schedule of work for funded individuals.

Note that Web3D Consortium responsibilities include, but also go far beyond, X3D v4 specification development.

Further note that completion of specification deliverables is controlled separately by a mature process guiding writing/implement/evaluate/review/acceptance progress.  Observing World Wide Web Consortium (W3C) progress reveals a similar focus on process (not arbitrary deadlines) to achieve approval and success.  This is very sensible.

Anyone wanting to help with member outreach is welcome to join as a member and participate in Friday-morning Communications Team teleconferences.

Everyone should be very grateful for the many significant volunteer efforts that are essential to all progress.  I sure am!  The brilliance and dedication of everyone involved is inspiring and totally motivating.

Am happy to report (as have others, many times) that the X3D v4 strategies plans and work continue with full review in every direction, including Board approval.  So please rest assured on that point.  As activity progresses, we get closer to completion.  Further contributions are always welcome.

Key links to X3D version 4 remain regularly reported and reviewed, on this list and elsewhere.  Once again:

	X3D Version 4 | Web3D Consortium
	http://www.web3d.org/x3d4

	X3D version 4.0 Development
	http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development

	Web3D Consortium: Participate
	http://www.web3d.org/participate

	Join the Web3D Consortium
	http://www.web3d.org/join

Hope this helps everyone understand the "big picture" of what is indeed occurring before all our eyes.  Onward we go.  8)


On 8/19/2017 7:11 AM, Don Brutzman wrote:

>> 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/


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