Hi Toni, Nice work! The internal separation certainly makes a lot of sense. It would be great to add option (b) so that we can test a full XML3D-based connection to realXtend soon. Would be a great step forward for the integration. Great! Our sync server is getting into shape as well right now and already can move animated XML3D/Xflow characters around in a larger city model. Sergiy and Torsten are ironing out some performance issues right now and are working on a modified version of scalability approach, so we can separate and distribute larger worlds dynamically. There is still quite a bit of work that remains, though. Our KIARA work is also progressing nicely. There will be a first release coming now in January. This could be a basis for discussing if or how this may be a good basis for abstracting the networking layer behind a nice API. Best, Philipp Am 22.12.2013 10:25, schrieb 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 > > > _______________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-miwi > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20140102/c5f012a2/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy