[Fiware-miwi] the entity system

[Toni Alatalo]

Hi,

this post is in a way a general observation of the reviews and the overall situation, not about any particular current GE but more to point out that we are kind of missing one. I don't think it is a problem for the current spec reviews so was postponing this till now when those are already done. We can perhaps talk about this in the weekly so i post quickly before that now.

The question is about the entity system. Who 'owns' it? How do we work on it?

It is assumed by many GEs and is considered the central mechanism via which we integrate parts. We discussed it in the Oulu meet last week and later on IRC then with Lasse. He made a point about how it can be implicitly thought of as a part of the Synchronization GE and it is true that a key aspect of the entity system is to provide the networked multiuser functionality. In the sense that you basically only need it for networked apps -- making a single user app works also just by using e.g. current xml3d.js or three.js directly. That's not completely true though as the way it (for example in native Tundra) integrates physics and scripting can be useful for non-networked apps too.

Besides synchronization, the entity system is obviously central for the 3d UI epic area. Indeed, the xml3d GE describes a data model and a way to use the DOM which is similar to how we've been using the entity system in Tundra. Basically they are the same thing as we discovered when specifying the mapping between them. For example, this is how to create a mesh component with xml3d -- example from the GE spec:
// Create a new mesh element
var newMesh = XML3D.createElement("mesh");
newMesh.setAttribute("src", "teapot.xml#meshData");

I was also originally thinking that the DOM is the API so we don't need to create a new API for the entity system.

Jonne however made I think a good counterargument a while ago: using the generic DOM funcs like createElement and setAttribute with the string attributes to identify what you want to work on is not really a nice API, compared to something like this:

// Create a new mesh component:
var mymesh = new x.ec.Mesh();
mymesh.src = "teapot.xml#meshData"; //this can validate the attribute etc. - i don't know if that's possible with plain DOM setAttribute

We have that kind of implementations of the realXtend entity system in the pre-existing incarnations of WebTundra: in Chiru-WebClient and Admino's WebRocket. At Playsign we've actually worked a few days now with Chiru-WebClient as ended up testing the scene loading code when starting work on large scene scalability (paging, LoDs etc) and encountered problems both with the Three's native JSON and with Collada pipelines from Blender to Three.js, that's a different story however. Anyhow it has been a nice exercise as has taught concretely how CIE/Chiru's implementation (by Toni Dahl, now at Cyberlightning AFAIK) of this kind of an entity system works. The EC model implementation in that codebase is at https://github.com/Chiru/Chiru-WebClient/tree/master/src/ecmodel . I think it is well documented too as Toni D. wrote his diploma thesis and a conference article about it - I haven't had access to those, though -- perhaps Jarkko or someone could provide the docs for us?

The similar implementation on the Adminotech side has API docs in http://doc.meshmoon.com/doxygen/webrocket/

About other GEs, the Interface Designer (aka. scene builder) explicitly specifies using the entity system as the central model for the editor.

With other GEs, I suspect that we encounter cases where in some GE it would be nice to implement new Component types -- that has been the common way for many plugins to extend realXtend so far. On the C++ side we have the IComponent interface for that, http://doc.meshmoon.com/doxygen/webrocket/classes/tundra.IComponent.html . WebRocket version of that is documented at http://doc.meshmoon.com/doxygen/webrocket/classes/tundra.IComponent.html and in Chiru's version for example the implementation of the Mesh component shows how to do it: https://github.com/Chiru/Chiru-WebClient/blob/master/src/ecmodel/EC_Mesh.js

But again now I think the question is: how do we organize the development related to this? Who 'owns' it, in the sense of being responsible but also having authority for the design? Is this driven by Synchronization, or somehow else if sync just focuses on the network messaging and assumes the entity system just be there like all the other GEs do too?

talk to you soon,
~Toni


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131009/d9db9b06/attachment.html>