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

[Leonard Daly]

John,

I hope I can and have answered all your questions here. I think I need 
to start with what is an ECS.

An Entity is a container that holds properties for each object in the 
scene. It can be as little as a unique identifier. It may be more.

A Component is a collection of data that described some aspect of the 
entity. It could be position, motion, interaction, collision, etc. 
Components are attached to entities. The same component definition can 
be used in multiple entities, but a specific component is attached to 
exactly one entity. In A-Frame a transform is three components - 
position, rotation, and scale. Additional components will be used for 
additional features. See the A-Frame page at 
https://aframe.io/docs/0.6.0/introduction/entity-component-system.html 
for more information (though I don't necessarily agree with all of the 
enthusiasm in their statements).

A System is the processing of entities for a specific operation. For 
example, translation can be a system. A more general system may handle 
translation and rotation. Collision detection is also a system. A system 
operates on all entities that have all of the necessary components. For 
example, the collision detection system would not operate on an entity 
that has position and size, but not collision components.


To try to describe this in X3D-speak. Entities are like nodes. 
Components are like fields. X3D has only one System - the Event Model. 
This runs on all entities with the event-received or event-generated 
component. Note that these are very rough analogies.

If X3D is going to support generic ECS, the event system would have to 
be tremendously refined. ECS is also designed to run in a more real-time 
environment where you must render a frame every N milliseconds and some 
operations just don't get done.

An ECS is independent of data source or encoding. A-Frame is like HTML 
(but not fully declarative). It is written in JavaScript and uses THREE 
for rendering. (THREE is scene-graph based). Perhaps in an ideal 
environment, the browser (or other rendering engine) would handle all of 
the rendering requirements and the content could be expressed in a 
language and form that is very understandable by the content developer. 
X3D is more like a modeling language; A-Frame is not fully declarative; 
THREE is programmatic; and WebGL/OpenGL is abstracted-hardware oriented.

Right now it is difficult to use X3D as an input to Unreal, Unity, 
A-Frame because even at the simple level (see Interchange profile), X3D 
has a runtime (Interpolators at Interchange). Also the requirement that 
USE nodes refer to the matching DEF node and are not 
subclassed/copied/etc. present a problem for ECS (and HTML). An X3D 
document that just specifies a static model with no lights can be used 
as input. It is also difficult to use X3D as output from those sources 
because those packages have more capabilities than X3D in animation, 
modeling, appearance, cameras, and navigation.


Leonard Daly



> Leonard wrote:
>
>
>
>     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.]
>
>
> I think this is a good point and will drive separation of concerns in 
> X3D.   We already have components in X3DJSAIL and the object model.  
> You might think of container fields as containing less generic 
> components and children fields as a way a way to add generic components.
>
> We may want to make container fields children fields in the standard, 
> but there's probably a good reason for container fields?  Should we 
> alter the standard to support more generic ECS operations?
>
> There's also room for components dealing with things like bounding 
> boxes etc.  I believe the object model reflects this, but not so much 
> X3DJSAIL--I'd have to check. Perhaps it should?
>
> How does XML, HTML or SVG reflect an ECS? Should we be following those 
> or A-frame?
>
> I think I explained how X3D is an ECS an not how it can be used in an 
> ECS.  Leonard, do you want an explanation as to how X3D can be used in 
> Unreal, Unity and A-Frame? I believe my answer would be as XML 
> snippets for importing components, not as a full X3D file.   The XML 
> could be used as an imported namespace in a more engine-specific XML 
> file. This truly is the beauty of XML that probably isn't widely used. 
>   If only we had better APIs for dealing with multiple namespaces.
>
> How does one distinguish between a component and a transform in A-frame?
>
> John
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org


-- 
*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/20170820/81ac0764/attachment-0001.html>