Thanks, and a note about the option b) considered there -- implementing xml3d.js rendering: With the current WebTundra implementation with that MVC idea the XML3dJsView would still mean that the internal scene model is the reX EC one — at least in our current thinking, the API for devs to move objects etc would be the WebTundra Scene API (as documented in the 3dui-webtundra & sync GE docs now), and the network synchronization would be however we get it done now (a topic of the tomorrow thu 13 meet). That might be completely fine if the mappings turn out perfect but it’s possible that there’ll be problems too. Is good to check the situation and discuss issues and alternatives etc. so I’m very happy that the tomorrow thing is coming, and the meet now. BTW we discussed Admino’s Interface Designer (or ‘scene editor’) yesterday too, and after completing the rex-ec implementation of it they’ve now implemented it as an editor for xml3d too. Is good that we can now take a look at those too, for example how the editor works with the APIs of webrocket (~webtundra scene api) and xml3d(.js?, or using dom?) regarding attribute metadata requirements etc. which have been discussed earlier. And very cool to hear about the fives & KIARA works, looking forward to looking into those at some point. Ah and very good to know from Torsten’s mail this part: "Upon receiving updates for an entity, this entity updates the internal data representation (java script objects) and updates the respective fields in its XML3D DOM element via sceneManager, if necessary:” — so that’s the other ‘b)’ alternative from the ‘DOM as UI’ talks .. as in internal reprs being js objects like current webtundra too, the case of this diagram: https://rawgithub.com/realXtend/doc/master/dom/rexdom-dom_as_ui.svg (instead of https://rawgithub.com/realXtend/doc/master/dom/rexdom.svg) ~Toni On 02 Jan 2014, at 16:02, Philipp Slusallek <Philipp.Slusallek at dfki.de> wrote: > 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 > --------------------------------------------------------------------------- > <slusallek.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy