<div dir="ltr"><div dir="auto"><div dir="ltr"><div>There is room for many 3d engines/frameworks/players/browsers on the very wide web, and there are many. In the declarative space there is really only a-frame which can be seen as a competitor. The success of a-frame is partially due to its ECS design, but equally due its continued, stable development and good support of developers via many channels including GitHub, slack, and meetings.<br></div><br></div><div>While I consider a-frame's ECS design sound, I think bringing ECS to X3D would be more of a distraction than helpful at this point.<br></div><div dir="ltr"><br>In fact, there is also a demand for an object-oriented, hierarchical, and declarative scene graph, and x3dom currently fills that niche. Many developers may prefer an imperative approach, and fine grained control down to hardware details, but there is also a large group which is less performance minded and more structure, app minded. <br></div><div dir="ltr"><br></div><div dir="ltr">To me the innovation the formal object model provides is in making the spec. and implementations more robust. However, I am not sure if it makes meaningful improvement or functional changes easier or harder. In a sense it seems to engrave the status quo more deeply, into xml. John Carlson had good ideas about that.<br></div><div dir="ltr"><br></div><div dir="ltr">This is where the visions for a future x3d seem to diverge between a conservative and a progressive approach.</div><div dir="ltr"><div dir="auto"><div dir="auto"><br></div><div>Given limited participation, I think leveraging as much as possible of the existing investments in the spec., tools, and implementations will be a necessity for the foreseeable future. This favors a conservative approach unless some entity wants to provide resources for a more ambitious rethinking and overhaul. Autogenerated interface code is a good example for leveraging, among others.<br><br></div><div>How can the object model be leveraged to help deep DOM integration ? By generation of IDL ?<br><br></div><div>-Andreas<br><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Message: 4<br>
Date: Sat, 19 Aug 2017 19:11:31 -0700<br>
From: Leonard Daly <<a href="mailto:Leonard.Daly@realism.com" target="_blank">Leonard.Daly@realism.com</a>><br>
To: Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>>, X3D Graphics public mailing list<br>
<<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
Cc: Myeong Won Lee <<a href="mailto:mwlee@suwon.ac.kr" target="_blank">mwlee@suwon.ac.kr</a>>, Michael Russalesi<br>
<<a href="mailto:mike@ssdllc.biz" target="_blank">mike@ssdllc.biz</a>>, Masaki Aono <<a href="mailto:aono@tut.jp" target="_blank">aono@tut.jp</a>><br>
Subject: Re: [x3d-public] motivations and potential renaming of OM4X3D<br>
as X3D Unified Object Model (X3DUOM)<br>
Message-ID: <<a href="mailto:6869657a-4cef-4c1a-f380-3ae7de6a0266@realism.com" target="_blank">6869657a-4cef-4c1a-f380-3ae7d<wbr>e6a0266@realism.com</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
Don et al,<br>
<br>
I appreciate the construction of an object model for X3D as laying a<br>
strong foundation for understanding the structure of the existing<br>
standard and providing a path for future evolutionary development of the<br>
standard.<br>
<br>
I do have the following concerns:<br>
1) The name is very close to an existing and well-known product - X3DOM.<br>
In fact this name looks like a typo of that. Unless a major education<br>
effort is made, there will be confusion when people see just the name;<br>
beside the verbal use will sound like "X3 dumb". Since the Consortium is<br>
very resource-limited, I suggest the (significantly less) effort be put<br>
into developing a new and non-conflicting name.<br>
<br>
2) No work has been done to identify what features should be in a<br>
web-based 3D/VR/xR graphics standard. This starts with a basic premise<br>
that the standard needs to support 3D (and other) graphic capabilities<br>
in a specified collection of environments. Then the concept requirements<br>
are developed and refined so that they meet the usual requirement<br>
conditions (consistent, complete, etc.) plus there exists a path from<br>
the existing situation (probably X3D V3.3) to the desired end goal. Not<br>
doing this reach step leads to incremental enhancement of the existing<br>
standard. We know that incremental enhancement is insufficient because<br>
there is minimal adoption of X3D compared to other standards that have<br>
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<br>
developed DLLs and other libraries that would read and write X3D to<br>
compete with FBX (primarily) and glTF (by extension). X3D does a lot<br>
more than FBX and a bit more than glTF, especially in the area of user<br>
interaction. Developing an Object Model for V3.x and applying that to<br>
the future (V4+) will not address the need to I/O libraries and the need<br>
and requirements for an interchange format. For example, X3D and glTF<br>
both include lights. In cinematic computer graphics (the kind used for<br>
movies, TV, and games), lighting of all kind is the responsibility of<br>
the lighting technical director. It does not belong with the modeler or<br>
animator (though on small productions these may be the same person with<br>
different responsibilities). A modeler who insists that his/her lighting<br>
be used will not have a job for very long.<br>
<br>
4) As I understand object modeling in computer science, it is done<br>
before the specification is developed. I have never heard of an object<br>
model being auto-generated from an XML Schema from a specification<br>
document. The (ASCII-Art) diagram developed by Joe was originally done<br>
to make sure that the interfaces and node hierarchy was consistent and<br>
complete, and to illustrate the relationships between the various nodes<br>
(abstract and concrete) and interfaces. The source for this diagram was<br>
the specification text, not the other way around. I do not remember ever<br>
trying to fit X3D into DOM (especially since DOM is an API), though it<br>
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<br>
Component System (ECS). ECS was developed in the early 2000's because of<br>
performance issues with handing extensive object hierarchy. ECS is how<br>
Unity, Unreal, and A-Frame work. It drives their internal data structure<br>
and run-time. Without some sort of explanation of how X3D can be used in<br>
an ECS, it will be dismissed by the entire game community. [Note that<br>
THREE more closely aligns with WebGL and is more object-oriented.]<br>
<br>
6) The Consortium is very resource limited. It has having difficulty<br>
keeping up. One of the recommended standards is over 10 years old<br>
(19777-2) and other one is only at Committee Draft (CD) text level. The<br>
graphic capability of X3D is significantly behind the industry for<br>
appearance (no bump maps, occlusion maps, opacity maps, displacement<br>
maps,...), animation using GPUs, multiple lighting models, and<br>
physically based rendering. Creating more work, especially in the area<br>
of ISO standardization will totally exceed the capacity of the<br>
volunteers who do this work. There is significantly less work involved<br>
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<br>
achieve and develop a plan (including schedule and budget) necessary to<br>
get there. Work that is not specifically on the plan that does not<br>
impede the plan is great, but cannot use Consortium resources that<br>
interfere with work on the plan. This plan needs to be approved by the<br>
BOD so everyone is on board. It can then be used as a selling point for<br>
membership because it is clear what is being worked on and what is the<br>
schedule.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
<br>
> Earlier this week I had an excellent in-depth discussion with Mike<br>
> Russalesi on Object Model for X3D. Some of you may already know that<br>
> Mike has provided strong encouragement towards creating DLLs for X3D.<br>
> Here is a recap with further analysis and some excellent go-forward<br>
> options.<br>
><br>
> 1. *Problem*. The existing X3D abstract interfaces in the X3D<br>
> Specification are sufficiently general to map to a variety of<br>
> programming languages, but unfortunately are incomplete. While all<br>
> nodes and fields are included with strong typing throughout, X3D<br>
> statements (such as ROUTE, IMPORT/EXPORT, PROTO etc.) are not<br>
> specified in an object-oriented manner. This occurred because the<br>
> original design of X3D was focused on code blocks within the Script<br>
> node, and were not looking at more-general goals like<br>
> HTML-page-inclusion or programmatic-construction of full X3D models.<br>
><br>
> X3D Abstract Specification: 4.4.2 Object model<br>
> <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Objectmodel" rel="noreferrer" target="_blank">http://www.web3d.org/document<wbr>s/specifications/19775-1/V3.3/<wbr>Part01/concepts.html#Objectmod<wbr>el</a><br>
><br>
><br>
> An ASCII-art diagram originated by Joe Williams shows all interfaces<br>
> and nodes (but no statements) and is found at<br>
><br>
> X3D Abstract Specification: 4.4.2.3 Interface hierarchy<br>
> <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#InterfaceHierarchy" rel="noreferrer" target="_blank">http://www.web3d.org/document<wbr>s/specifications/19775-1/V3.3/<wbr>Part01/concepts.html#Interface<wbr>Hierarchy</a><br>
><br>
><br>
> 2. *Motivation*. Our original efforts to fully specify all aspects of<br>
> X3D for any object-oriented use were first inspired by mapping<br>
> everything to fit inside HTML5 Document Object Model (DOM). This<br>
> early effort identified a number of gaps. When we continued to work<br>
> on a JSON encoding for X3D, these same issues were cast in sharp<br>
> relief because JSON is exceedingly strict and thorough (hence the "O"<br>
> in JSON).<br>
><br>
> 3. *Approach*. As a result of these gaps, much discussion on the<br>
> mailing list and much effort by Roy Walmsley, John Carlson and myself<br>
> was applied. The X3D XML Schema as further annotated to list all<br>
> fields with accessType inputOnly or outputOnly (which cannot by<br>
> themselves appear in an XML or VRML model). Strong typing and a<br>
> consistent abstract interfaces were also applied to previously ignored<br>
> X3D statements. Corresponding implementations in JavaScript and Java<br>
> have been built to demonstrate the soundness of these improvements.<br>
> This work is described in detail as part of the Web3D 2017 Conference<br>
> Tutorial.<br>
><br>
> Figure: Creation and Autogeneration of Object Model for X3D<br>
> <a href="http://www.web3d.org/specifications/X3DUOM/ObjectModelForX3dCreation.png" rel="noreferrer" target="_blank">http://www.web3d.org/specific<wbr>ations/X3DUOM/ObjectModelForX3<wbr>dCreation.png</a><br>
><br>
><br>
> Design tutorial: Object Model For X3D (OM4X3D) Master Class, Web3D<br>
> 2017<br>
> <a href="http://www.web3d.org/specifications/X3DUOM/ObjectModelForX3dMasterClassWeb3dConference2017June7.pdf" rel="noreferrer" target="_blank">http://www.web3d.org/specific<wbr>ations/X3DUOM/ObjectModelForX3<wbr>dMasterClassWeb3dConference201<wbr>7June7.pdf</a><br>
><br>
><br>
> 4. *Insight*. As originally hoped, many benefits and much progress<br>
> has flowed from this effort. In our discussion, it became clear that<br>
> these X3D object model efforts are<br>
> a. making it progressively easier to define closely matching APIs in a<br>
> variety of programming languages,<br>
> b. coherently simplifying and streamlining X3D, not creating "node<br>
> bloat" or further variations, and<br>
> c. defining a _unified_ object model that makes X3D widely applicable<br>
> 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<br>
> the recently proposed Specification Relationships diagram update, is a<br>
> straightforward matter.<br>
> b. As X3DJSAIL has shown, such APIs can even be automatically created<br>
> - meaning that future X3Dv4+ evolution is easily accommodated without<br>
> error.<br>
> c. Renaming the (awkward) Object Model for X3D (OM4X3D) as X3D Unified<br>
> Object Model (X3DUOM) better describes these powerful benefits.<br>
> d. Object model progress should be part of X3Dv4 Abstract<br>
> Specification, updating and completing the existing interface hierarchy.<br>
> e. Corresponding updates should be applied to 19775-2, the Scene<br>
> Access Interface (SAI) Abstract Specification. We're going beyond<br>
> Script node.<br>
> f. Development of programming-language APIs for X3D using JavaScript,<br>
> Java, C, C++, C# and Python can continue to proceed in parallel.<br>
><br>
> Given the many efforts to date, renaming opinions by other<br>
> contributors to the X3D object model are especially welcome.<br>
><br>
> I've taken the liberty of applying this potential rename so that we<br>
> can see how it looks. Improvements and informed consensus are always<br>
> welcome. A first-draft page collecting the current set of related<br>
> assets can now be found at<br>
><br>
> X3D Unified Object Model (X3DUOM)<br>
> <a href="http://www.web3d.org/specifications/X3DUOM.html" rel="noreferrer" target="_blank">http://www.web3d.org/specific<wbr>ations/X3DUOM.html</a><br>
><br>
> X3D Graphics Standards: Specification Relationships (proposed update)<br>
> <a href="http://www.web3d.org/specifications/X3dSpecificationRelationships.2017August11.png" rel="noreferrer" target="_blank">http://www.web3d.org/specific<wbr>ations/X3dSpecificationRelatio<wbr>nships.2017August11.png</a><br>
><br>
><br>
> More slidesets and resource links will be added. For example, Dr.<br>
> Myeong Won Lee has an excellent Unity application running on a mobile<br>
> phone that uses the draft X3D SAI for C++ to load H-Anim characters<br>
> and X3Dv4 Motion nodes that provide BVH mocap animations. Dr. Masaki<br>
> Aono has also been experimenting with Python design patterns, we hope<br>
> to compare these constructs to the pyjnius transcoding produced by<br>
> John Carlson. Additional experiments welcome.<br>
><br>
> It is interesting to consider how this effort has streamlined and<br>
> consolidated X3D, reducing mismatches and unifying different<br>
> approaches coherently. I think that the object model unifications can<br>
> be considered as useful progress in streamlining and modernizing X3Dv4.<br>
><br>
> All discussion welcome, what do you think? Looking forward to further<br>
> comment plus continuing dialog during X3D Working Group meetings.<br>
><br>
> all the best, Don<br>
<br>
<br>
--<br>
*Leonard Daly*<br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - /Creating the Future/<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170819/2dc5c314/attachment.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x3<wbr>d-public_web3d.org/attachments<wbr>/20170819/2dc5c314/attachment.<wbr>html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listi<wbr>nfo/x3d-public_web3d.org</a><br>
<br>
<br>
------------------------------<br>
<br>
End of x3d-public Digest, Vol 101, Issue 50<br>
******************************<wbr>*************<br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="m_-4521438275472207017m_1473949449749327413gmail_signature" data-smartmail="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div></div></div></div>
</div>