<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Don et al,<br>
<br>
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.<br>
<br>
I do have the following concerns:<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.]<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
<br>
</div>
<blockquote type="cite"
cite="mid:0d0d6570-b10f-9dd5-5ee8-6b6953096ace@nps.edu">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.
<br>
<br>
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.
<br>
<br>
X3D Abstract Specification: 4.4.2 Object model
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Objectmodel">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Objectmodel</a>
<br>
<br>
An ASCII-art diagram originated by Joe Williams shows all
interfaces and nodes (but no statements) and is found at
<br>
<br>
X3D Abstract Specification: 4.4.2.3 Interface hierarchy
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#InterfaceHierarchy">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#InterfaceHierarchy</a>
<br>
<br>
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).
<br>
<br>
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.
<br>
<br>
Figure: Creation and Autogeneration of Object Model for X3D
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/specifications/X3DUOM/ObjectModelForX3dCreation.png">http://www.web3d.org/specifications/X3DUOM/ObjectModelForX3dCreation.png</a>
<br>
<br>
Design tutorial: Object Model For X3D (OM4X3D) Master Class,
Web3D 2017
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/specifications/X3DUOM/ObjectModelForX3dMasterClassWeb3dConference2017June7.pdf">http://www.web3d.org/specifications/X3DUOM/ObjectModelForX3dMasterClassWeb3dConference2017June7.pdf</a>
<br>
<br>
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
<br>
a. making it progressively easier to define closely matching APIs
in a variety of programming languages,
<br>
b. coherently simplifying and streamlining X3D, not creating "node
bloat" or further variations, and
<br>
c. defining a _unified_ object model that makes X3D widely
applicable in many domains and applications, using consistent
APIs. (Thanks Mike!)
<br>
<br>
5. *Suggested steps*. The work is converging nicely. More to
follow:
<br>
a. Adding different programming-language bindings to X3D, as shown
in the recently proposed Specification Relationships diagram
update, is a straightforward matter.
<br>
b. As X3DJSAIL has shown, such APIs can even be automatically
created - meaning that future X3Dv4+ evolution is easily
accommodated without error.
<br>
c. Renaming the (awkward) Object Model for X3D (OM4X3D) as X3D
Unified Object Model (X3DUOM) better describes these powerful
benefits.
<br>
d. Object model progress should be part of X3Dv4 Abstract
Specification, updating and completing the existing interface
hierarchy.
<br>
e. Corresponding updates should be applied to 19775-2, the Scene
Access Interface (SAI) Abstract Specification. We're going beyond
Script node.
<br>
f. Development of programming-language APIs for X3D using
JavaScript, Java, C, C++, C# and Python can continue to proceed in
parallel.
<br>
<br>
Given the many efforts to date, renaming opinions by other
contributors to the X3D object model are especially welcome.
<br>
<br>
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
<br>
<br>
X3D Unified Object Model (X3DUOM)
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/specifications/X3DUOM.html">http://www.web3d.org/specifications/X3DUOM.html</a>
<br>
<br>
X3D Graphics Standards: Specification Relationships (proposed
update)
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/specifications/X3dSpecificationRelationships.2017August11.png">http://www.web3d.org/specifications/X3dSpecificationRelationships.2017August11.png</a>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
All discussion welcome, what do you think? Looking forward to
further comment plus continuing dialog during X3D Working Group
meetings.
<br>
<br>
all the best, Don
<br>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>