[x3d-public] concerns about focus on X3D Unified Object Model (X3DUOM) [was: Leonard Dalys response]
Andreas Plesch
andreasplesch at gmail.com
Sun Aug 20 08:51:12 PDT 2017
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.
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.
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.
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.
This is where the visions for a future x3d seem to diverge between a
conservative and a progressive approach.
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.
How can the object model be leveraged to help deep DOM integration ? By
generation of IDL ?
-Andreas
Message: 4
> Date: Sat, 19 Aug 2017 19:11:31 -0700
> From: Leonard Daly <Leonard.Daly at realism.com>
> To: Don Brutzman <brutzman at nps.edu>, X3D Graphics public mailing list
> <x3d-public at web3d.org>
> Cc: Myeong Won Lee <mwlee at suwon.ac.kr>, Michael Russalesi
> <mike at ssdllc.biz>, Masaki Aono <aono at tut.jp>
> Subject: Re: [x3d-public] motivations and potential renaming of OM4X3D
> as X3D Unified Object Model (X3DUOM)
> Message-ID: <6869657a-4cef-4c1a-f380-3ae7de6a0266 at realism.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> 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/ObjectModelForX3
> dCreation.png
> >
> >
> > Design tutorial: Object Model For X3D (OM4X3D) Master Class, Web3D
> > 2017
> > http://www.web3d.org/specifications/X3DUOM/ObjectModelForX3
> dMasterClassWeb3dConference2017June7.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/X3dSpecificationRelatio
> nships.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.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 101, Issue 50
> *******************************************
>
--
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170820/fbdef9d2/attachment-0001.html>
More information about the x3d-public
mailing list