Hi, Am 15.01.2014 09:34, schrieb Toni Alatalo: > 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. Thins sounds great. Is there a chance to see anything of the editor yet? We would be extremely interested to get our hand dirty with it. I am sure we find people interested in working on this, too. > 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) Well, we never store the JS objects, they are only used in the API from KIARA to communicate the changes to the scene (and back). Best, Philipp > ~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> > -- ------------------------------------------------------------------------- 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/20140119/c0814cfc/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy