As discussed often we are using three.js for rendering in WebTundra, mostly due to compatibility with existing realXtend requirements and applications for example on meshmoon.com. The requirement for declarative authoring is delivered by WebTundra’s SceneParser which can read an XML3D description and populate a reX EC scene from it. However thanks to applying the model-view-controller pattern the three.js dependency is limited to a view module in WebTundra: the networking and the internal core scene model, the entity-components which hold the data, don’t know anything about it. This was done mostly to allow running headless clients for example in node.js based simulation services. Erno is actually developing such bots now for the car & physics test/demo -- and as discussed this way the WebTundra codebase (without the view part) is an implementation of the Scene API epic too: it enables services to connect to a scene and modify it efficiently. However the MVC arch makes it also very straightforward to use xml3d.js for rendering instead, to get XFlow and Shade.js etc. support, and Philipp recommended in an email earlier that we’d implement that. I gave it a shot recently and am very happy to tell you that a simple proof-of-concept XML3DJSView was indeed quite straightforward to write and works enough now to initialize the view and show a test object in WebTundra. I used DFKI’s FiVES WebClient code as a reference for populating a scene from network data for xml3d.js to run. As also discussed already before the FiVES WebClient and WebTundra architectures are basically identical. It seemed that with some thought we might even share parts of the same code for FiVES WebClient and WebTundra’s XML3DJSView. Now I did it by copy-pasting and modifying appropriately. This brings up the question about FiVES licensing. It is currently GPL which we can not use in realXtend due to absolutely requiring support for also closed source proprietary applications. GPL requires any code that uses the library, in this case apps made on top of the FiVES WebClient framework, to provide the source code and AFAIK unlimited modification & redistribution rights for any user of the app. Even at Playsign where we use open source tech for basically everything and and happily participate in open source tool & platform development this is not possible for the applications: open sourcing our games and especially the graphics for them is out of the question (for one it would make it all too easy and legal to clone the games). I’m sure everyone knows how this is completely normal all around, both in games and other apps companies. I asked about the FiVES license previously at the F2F meet in Oulu and DFKI folks said they’d return to it but I suppose it has just fallen off the table due to other duties. So, is it possible to change the license? Do people find WebTundra with Tundra connectivity & XML3D.JS rendering interesting? What are the FiVES WebClient development plans, should we check if can reuse code in these two quite similar web clients? The little experimental code with the minimal required changes to get xml3d.js to run inside WebTundra are in a branch in Playsign’s fork of the repo. If the license is not changed I’ll never push this work to realXtend’s repo to keep the permissive licensing there absolutely clear. The current code is partly copy-pasted which AFAIK carries the license over. If the license is never changed but we need this functionality we’ll rewrite it somehow so that it is not a copy (some other person writes it without reading the FiVES code or so). Links for the curious tech folks who are not afraid of the GPL virus(*): https://github.com/playsign/WebTundra/tree/xml3djs https://github.com/playsign/WebTundra/blob/xml3djs/src/view/XML3DJSView.js https://github.com/playsign/WebTundra/compare/realXtend:dev...xml3djs I used the WebTundra XML3D-reading OpenCTM asset test, which is a copy of the original XML3D.JS OpenCTM demo (the ambulance) as the test -- so did not test by connecting to a Tundra server yet but populated the scene from a file instead (is faster to dev like that). The code should work for the networked case too though as the data source is almost completely invisible for the view module. Unfortunately I had trouble with xml3d.js openctm loading in my local dev setup (also for the normal xml3d.js ctm demo, which does work on-line) so had to hack the code just to show Suzanne for now. As the comparison against dev shows I just did all sorts of hardcoded mods for this now, there is no way to properly switch between the view implementations etc -- this was just a first stab to verify the idea and see what places would required changes etc. ~Toni (*) previously when we worked with OpenSimulator and the Linden labs Second Life viewer code, which was GPL back then (is largely LGPL now), we were taught to be quite paranoid about GPL. The OpenSim contributor agreement stated that no one who had looked at the SL viewer code in 6 months is allowed to commit code to OpenSim. This was due to advice by some mysterious lawyers (I suspect IBM, they did OpenSim dev at that time). I think it actually made sense: otherwise Linden labs could come and claim that OpenSim is derived work from SL (viewer) and that it should hence be GPLed as well (which again Opensim does not want due to supporting proprietary apps, like realXtend). So the solution within realXtend organization was to separate viewer and server development to different teams, in different companies at different locations .. Admino worked with Opensim and Ludocraft on the SL viewer based first realXtend viewer prototype. Now with our new codebases all that is luckily gone, and also for Opensim devs the SLViewer change to LGPL helped and IIRC they’ve dropped the contributor agreement so same people can work on server&clients there too. I’ve also encountered unrelated cases where professional programmers have steered away from even looking at GPL code for help / reference when implementing something to avoid problems (in a small completely not legalese database company, not related to 3d or VWs). -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20140316/fba0fb82/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy