[Fiware-miwi] EntSys: has Scene, integrates Networking & 3DUI + possibilities for XML3D

[Toni Alatalo]

About 3 weeks ago we presented a plan for an implementation of the entity system and how it would integrate networking (Synch GE) and rendering (3DUI GE). 

A key aspect in the design was to separate data and view parts of the EC implementations — unlike in any previous Tundra implementation, where the scene internals and all EC implementations have been directly tied to certain graphics renderer (Ogre or Three.js). The motivation here was to support ‘headless clients’ or ‘simulation servers’ — for example for a Node.js server side service running some simulation or AI code to use this library to connect to a Tundra server to manipulate the scene (possibly what the SceneAPI Epic is after). Without ugly hacks like the !headless checks in many parts of the C++ Tundra code. When the renderer-dependent view code is a separate optional module the scene & network parts can be used also without it but the programming model (against the scene with the entities) is always the same. Consequently, the proposal in this plan was to *not* use the DOM as the internal data storage for the Scene — simply because there is no (native) DOM implementation available e.g. in the Node.js environment. The original post with more explanations is https://lists.fi-ware.eu/private/fiware-miwi/2013-November/000330.html

No one objected, so we went with the plan and I’m very happy to tell that the basics for it are implemented and work now. As planned in that post, we (Ludocraft & Playsign so far) moved to work in a common repository based on Lasse’s Synchronization GE work — WebTundraNetworking was renamed to WebTundra and we added a view/ directory there: https://github.com/realXtend/WebTundra

To see it in action you'll need a recent development build of Tundra WebSocketServer plugin enabled. realXtend will make an official release in January so it will become readily available then. And perhaps we can run Tundra servers in FI-LAB at some point to be able to host web services then. But if you build it yourself, it’s very easy to test with the web-hosted test scene we provide: https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/3DUI-WebTundra_-_Installation_and_Administration_Guide#Test_with_provided_web_hosting_for_scene_data

To test the tech and verify and improve the application programming model etc. we’ve ported the Pong example on top of Tundra (server-side js) and WebTundra (browser client-side) — more info about that later separately, but if someone wants a pre-peek that work is in https://github.com/playsign/PongThreeJS/tree/ec (includes server/ dir for the Tundra scene). The Pong example is used also in the dev guide docs in https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/3DUI-WebTundra_-_User_and_Programmers_Guide (to be improved but has basics now).

With this some things are clear: we already have a platform on which can develop apps. But all FI-WARE goals are not delivered yet and there are some options so I’ll describe the status briefly here:

XML3D Support: in the F2F I promised we’ll do 3 things: 1. the entity system integration (done as reported here now), 2. recommended asset pipeline research & impl (on-going, now waiting for the updated three.js glTF loader by mr. Parisi) and finally 3. a proposal how to proceed with the rendering choice / alternatives. The current WebTundra implementation gives two, I find quite nice, alternatives for XML3D support:

a) add XML3D parsing to WebTundra so that it can read XML3D declarations and populate the internal Scene correspondingly, hence resulting in a 3d rendering when the view module is enabled. Erno actually implemented a first version of this this week. It was made by changing the pre-existing WebTundra TXML parser in Toni Dahl’s Chiru-WebClient to read XML3D instead, this work is in https://github.com/playsign/WebTundraNetworking/commits/sceneparser . I find this approach has interesting upsides: is simple, and thanks to the entity-system is transparent to the other parts — for example the networking works normally so that in fact this works as a way to populate a Tundra server from XML3D (when the client reads xml3d and creates the entities, they get replicated to the server too :) . Also for XML3D standardization efforts it can be interesting that there is another implementation of it. Obvious downsides are that it’s a small incomplete subset of the spec (at least now) and it doesn’t use the xml3d.js engine which has xflow support with hw acceleration coming etc. 

b) add XML3D.js view module to WebTundra. Now that the core scene and ECs are renderer independent, it is easy and totally feasible to add a xml3d.js renderer. The ThreeView is currently just one file with not an awful lot of code — same with XML3D.js would probably be as simple. This is helped by Erno having applied the MVC pattern in the code so that besides the data in the scene there are model and controller codes which manage the state and observe data coming in from the net and track Placeable and Mesh references and dependencies etc. so that the View is told to display things when they are ready (instead of the view requiring all that tracking in itself). So with the complexities in Model & Controller parts, possibly already in a renderer agnostic way (we didn’t check with this in mind), possibly not so much is left for the potential alternative Views to handle. We currently need the Three.js view in any case as e.g. Meshmoon has a lot of components & rendering made with three so at least first the XML3D.js view would be an alternative only.

Another topic is the DOM integration. Current WebTundra has none. There again I think there are two ways: 

1. The previously discussed ‘DOM as UI’ idea where the internal Scene is just mirrored to DOM (this is simple and Jonne already did it in WebRocket). This might also be one way to implement xml3d.js view support .. if we just populate the DOM it should show when xml3d.js is active (but when using ThreeView the DOM population would be only for developer purposes, to allow seeing the values in debugger etc).

2. Change the scene internals so that it would use the DOM directly. Erno actually prototyped this before we decided to not require DOM in the core to support the node.js case. I don’t know if the scene core could somehow sensibly use the DOM when it’s there, but work without it when it’s not (except ofc with the simply optional mirroring option of 1.). Perhaps somehow doing what Philipp outlined at the F2F, put own JS objects to the DOM nodes (so we could have the Attribute objects with the type info that the net sync (& interface designer) require there).

Anyhow, this is where we are now — I’m very happy that the basics work and we have a common base on which can work and where to integrate things (e.g. 2D UI, Input, Interface Designer, possibly app specific components from other GEs like POI & real-virtual interaction or GIS?) and on which we can implement apps like the Pong example illustrates.

The XML3D support and DOM integration we can have at least with the a) and 1) options that have already been implemented. We are however open to discuss alternatives and possible clever techniques to address those.

Thanks to everyone for the efforts so far! Looking forward to tackling the last remaining issues & packaging first releases after the holidays then..
~Toni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131222/31531df4/attachment.html>