<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>I think the issue with ECS versus OO may be more of an implementation issue with X3DJSAIL rather than an issue with the Object Model (Node type versus Object type might handle it). Converting IS-A into a generic HAS-A is not that difficult—given that practically everything can be an Object in Java, and we may see alternate implementations of X3DJSAIL (not exactly the thing that Leonard wants to see). In fact, I would encourage the C implementation to take the HAS-A approach, since IS-A is general available only as function pointers in C (that I know of). If we use the C implementation as a guide, this may help with the rest of the implementations to be less OO and more ECS.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:yottzumm@gmail.com">John Carlson</a><br><b>Sent: </b>Sunday, August 20, 2017 4:10 AM<br><b>To: </b><a href="mailto:x3d-public@web3d.org">X3D Graphics public mailing list</a><br><b>Subject: </b>Fwd: Re: [x3d-public] motivations and potential renaming of OM4X3D asX3D Unified Object Model (X3DUOM)</p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>Leonard wrote:</p></div><div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal><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.]</p></div></div></blockquote></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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?</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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?</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>How does XML, HTML or SVG reflect an ECS? Should we be following those or A-frame?</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>How does one distinguish between a component and a transform in A-frame?</p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>John</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>