Hi Toni, I think we have no issues going to LGPL if that is all that is needed. for now. Let me know and we will discuss this internally and get back to you. I think it would be great to merge the code bases and get to a common joint code that is much easier to maintain (particularly now in FI-Core). Also there are very interesting options to use this code to base Phase-3 project on, once we can commit them and make them more broadly available. Regarding further develoment, Torsten plan to soon start on a full KIARA implementation for FIVES (currently a lot is hardcoded), so we can have all the advantages of KIARA soon. We are also getting to the point where KIARA will become usable on the C/C++ side (for example, the latest benchmarks show that we can do roundtrip RPCs in less than 200 us on Gigabit Ethernet with it). This would allow the C/C++ Tundra to eventually switch to it as well. A number of other DFKI projects will also be porting to KIARA/FIVES in the upcoming weeks/months, so that we will get a lot more testing and extensions, where needed. It would be great to have you on board here as well. On a related note, we are working on large scene support right now using various techniques (this is needed for a nuber of automotive projects we are working on). We just got the first version of BLAST running which is a new highly efficient transfer format for XML3D (and also other formats). Jonne saw some demos at CeBIT, smoothly rendering a 5.7 Mtris city scene). We plan to publish this soon and submit it to Khronos as an alternative to their current glTF activities. At CeBIT we also showed first results of our new render pipeline implementation. Specifically it allowed to switch on Screen Space Ambient Occlusion (SSAO) as a post processing option. Other related effects should be realtively straight forward to implement. Let us know, if you are interested in adding your own extensions here. Best, Philipp Am 16.03.2014 16:11, schrieb toni at playsign.net: > 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). > > > _______________________________________________ > 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/20140316/803cdc17/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy