Hi Toni, sorry for not having replied earlier. I was spending Sunday with recovering from CeBIT, and am now about to catch up with the FI-Ware emails that arrived during the last days. I'm happy to hear that you could made use of the FiVES code and that it worked to turn it to a WebTundra view. :) This development is definitely interesting. With just a bit more of work on both client and server side (by introducing a slim KIARA layer in realXtend, for example), I can even see a use case where Synchronisation- and 3D-UI-Implementations are fully exchangeable, i.e. our FiVES client can connect to realXtend, and WebTundra GEi can connect to FiVES without any modifications. Concerning licensing, I also think that LGPL should be no problem. If this is a suitable choice for you, we're going to discuss this with Sergiy and release the client code respectively. I am also starting to think about separating the client code from the FiVES repo and put it in a repo of its own (with possibly a different, less restrictive license). We have to think about this anyway, as further plans about FiVES are involving more the client side rather than the server side. And for client development, a repository on its own means that one would not have to check out the whole server code as well when being interested only in the client frameworks. Our plans concerning the Web client are currently to get rid of the few remaining hard coded hacks (e.g. fixed set of components to be initialised with new entities on client side, fixed set of plugins the client expects from the server to run, and some more minor things), and provide a Web Client skeleton without any plugin specific code (i.e. only communication and XML3D scene management) to build upon, in addition to the current client that implements more or less most of the features the server offers. As Philipp already mentioned, I am moreover going to improve C# KIARA implementation. Background of this is also that in addition to XML3D / JavaScript WebClient, we would like to have basic client implementations for C# and, with the improvements introduced in C++ KIARA, also in C++, to derive distinct client implementations from. Best, Torsten Am 3/16/2014 7:08 PM, schrieb Philipp Slusallek: > 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 >> > > > > > _______________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-miwi -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20140317/98f54aee/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy