I think we reX devs have all at least tinkered with the idea to make some kind of OpenSim support in our heads, and shortly at times on our IRC channel when the subject comes up. The idea is fun, and as we all worked on Naali before we know how it can be done. For me, this however should not touch the basic core of Tundra in any way. As Toni said Tundra is now a generic 3D application framework/engine that has its own thing. The code base and the framework/coreapi/application separation is much nicer, I could say its at least 100x nicer codebase to work on than what Naali was :)
This being said, I believe the Tundra framework/core apis are in fact so nice that OpenSim support could be done in a separate OpenSimModule that just _does it all_ and would not touch other parts of Tundra, if this can be done, its clean and we would have a non trivial testimonial that Tundra core itself is quite nice :) For logging in to OpenSim and getting the basic scene to render could be the first step. For this the OpenSimModule would need to do the following: 1. Do the login with xml-rpc (utilise code from Naali OpenSimProtocolModule, rewrite the somewhat ugly login code though and find nicer xmlrpc lib) 2. Create a new client scene with SceneAPI. 3. Handle the incoming LLUDP message (utilise code from Naali RexLogicModule). This would include making a translation layer for the scene coordinate system as we moved Tundra to Ogres system. 4. Translate the object messages into Tundra Entities/Components/Attributes. This would leverage our existing EC_Placeable + OpenSimModule would reintroduce EC_OpenSimPrim from naali codebase in some way). 5. Render the OpenSim scene, wohoo o/ I actually think this would not even be too much work. I think more work would be to do the avatar and after that finally syncing scene changes back to the OpenSim server. Not to mention inventory, opensim chat etc. to get a "fully featured" opensim client out of Tundra. I would also recon we would do it a bit differently this time with client side scripting support like Toni suggested also. The OpenSimModule should handle all the messaging and construct the scene for rendering it and all that basic stuff. I think how we went partly wrong in Naali was that all the UI for example was hardcoded in to the c++ code. Tundra basically has no UI when you log in to a world, the scripts from the scene define the UI of that particular server. I think even if we know OpenSim has chat and inventory etc widgets, we should handle those things in OpenSimModule emit some related Qt signals and make the ui in scripts (local in this case). People then could modify how their UI looks locally, make nice mods and share those scripts with other clients. Anyways the point is, imo we should not hardcode UI into the OpenSimModule, if something requires that emit the data to a scripting layer (if feasible, it is always not, but eg. for chat and inventory it would work great). That all being said, this is the for me at least still that "tinkering in our heads" kind of stuff :) Its fun to think for a coding challenge how to do it, but actually doing even the simple OpenSim scene rendering takes some serious works hours. Of course it would help if you get us reX devs on board, for a novice to Tundra/Naali/rex tech/C++ it might be a lot more work. So I guess I might ask a question too. Are you willing to put some effort into this by the OpenSim dev community or are you just asking "will you do this for us?". If it is the latter, at least speaking from our company perspective (don't want to but any words to other rex involved companies!) we are very happy with Tundra and OpenSim as a server is not in our roadmap. If you ask me personally I would be happy to chip in on my free time if this effort materializes :) It is easy as peanuts to fork Tundra and just get to work. But if we want the module to integrate cleanly into Tundra as an optional module, we should have some talks how we can accommodate this and what would be the best approach. I mean if someone starts working on this for two months then send a pull request that has added hacks around the core APIs to "just get it work" it would be swiftly rejected and no one wants that. Best regards, Jonne Nauha Adminotech developer On Sun, Apr 29, 2012 at 5:47 AM, Toni Alatalo <[email protected]> wrote: > On Apr 28, 2012, at 11:30 PM, Lord wrote: > > Recently, Linden Labs/Research announced an upcoming move (Havok AI > sublicensing) that seemed to indicate that they were going to develop their > Second Life(tm) viewer without further consideration of the Open Source > community. > > > I wonder what motivated that statement, seems a bit weird: "Sublicensee > must require the Third Party Viewer to connect only to servers owned or > operated by the Company [Linden Lab].” > > Is it perhaps because Linden has only paid for a license to use it for > their service? > > There are some who believe that they will just fork the SL(tm) viewer > without the changes needing licensing and continue onward, either with > open sourced solutions to the features they develop that can be used in > OpenSim, or simply by doing without those features. > > > Sure, people don't want to loose what they have. How much it would develop > further from there, well, who knows. > > While this may work for awhile, their message is of a slippery slope > variety, and will probably result in their closing it down more and more as > time goes on in order to make it a tradeable asset. > > > Is this a somehow known? We here haven't followed SL recently here, > everyone's been too busy working I guess. > > > In light of this development it has occured to some in OpenSim that they > need to break free of the ties to Linden Labs/Research(tm) and produce > their own open-sourced viewer with no LL dependencies. However, there are > strong reasons for not wanting to write one from scratch: mainly, time and > money. Due to this, it has been suggested that OpenSim start with an > already existing viewer, such as Radegast, or Tundra/Naali and build from > there. There seems to be growing support within the OpenSim community for > such a viewer. > > > This is a bit of a turn, no? > > Thinking about these things some 1-2 years ago, come to conclusion that > the Linden renderer is what many Opensim folks are happy with .. is > definitive, how all the graphics should look etc. And it was then LGPLed > and all (right?) so licensing became more Opensim compatible too. > > We've figured it has to do with the need: if you want an exact SL clone, > may be not a bad idea to use the SL viewer. And Imprudence and Aurora and > what not, KirstenLee for Cinematic / Machinima use etc. So I've been > concluding that that front continues on the same way. > > But if instead you are interested in a humble still a bit immature > candidate Internet standard virtual worlds thing based fully on open source > libs, which is modular (uses the same entity-component system for core > things than you can define for your own functionality, even from scripts) > etc .. then some other solutions are more interesting ;) > > With realXtend recently the most important thing has been to make a fully > generic application platform. Tundra reached that, and is solid and stable > now. We are happy and can make applications. > > The 'Second Life application' was one of the original use cases for Tundra > too. Already in the Naali version it was all modular -- for example prims > and other sl things were are in one app logic module (RexLogic is called, > to mean the legacy lludp+rex features .. could be LLLogic too). Inventory > was another module, there was actually two implementations: Linden inv in > C++ and a Webdav inventory too using a Python dav lib for the networking > (but the final QT Gui for it was written in c++). > > If you want, it is perfectly valid and possible to implement Opensim > things in modules for Tundra, for example. Some of them don't need anything > new from the core. With the old Naali builds you can already test if, if > the latest 0.4 release still connects to current Opensim .. it may :) > > Much could be written for example in Javascript, for example all the > inventory and if you want authention and such things .. such app logics are > often in js with Tundra. And UIs and custom editing tools etc. > > BTW I've found the effort to add 3d rendering to Radegast with pure OpenGL > a really nice exercise. And whole Radegast and actually the LibOMV in there > too. > > One way for Tundra-Opensim connection would be making some sort of > DotnetScriptModule to Tundra for C# plugin support (or can they integrate > just with c++ somehow) and use LibOMV. Naali of course has the old C++ > LLUDP code too. I'd probably first test first with pythondotnet bridging, > like did with Blender (in http://playsign.fi/engine/BlenderOMV). > > But I don't know if LLUDP is that interesting to use. > > In fact, both Ilan Tochner of Kitely, and Tranquility Dexler(David > Daeschler) of InWorldz were *very* interested in the possibility ( > http://www.hypergridbusiness.com/2012/04/new-linden-policy-may-hurt-viewer-development/) > . > > > Yes, we have been talking with Ilan about these things for a while now. > > He explained well how sees content interoperability as the key. I think > that makes a lot of sense. So we might consider e.g. OAR import&export to > Tundra (EC_Prim), not SL protocol things etc. > > Though in general it at least used to be so that e.g. Collada support is > much more important for typical reX users than OAR. Might be an interesting > effort to write Collada scene saving to the Opensim .. put the primdata in > collada's xml somehow, the X is for eXtensible after all. > > Would it be possible to achieve an OpenSim compatible version of the > viewer (and possibly the platform) ? I think it would draw more people to > the entire Tundra platform as they use the viewer. > > > Is certainly possible. And I think if something like that is made, it > easily becomes a feature for the platform. For example if you make a Prim > entity-component, can put the data in the attributes there so that they are > automatically saved to Tundra files, synched over the net in realtime etc. > > To complete the features for a really useful level would take some > substantial development effort. Quite a lot was made in the Naali project > back then. Prim rendering and avatar support (also to get the animations, > Melanie's LegacyAvatarModule project). Ilan has been asking about those and > we've tried to estimate the amount of work to for example integrate that > old LegacyAvatarModule, for LL avatar support, to current Tundra. Is not > trivial mostly because the format is undocumented and only a few people > have reverse engineered it afaik etc. > > One thing I've wondered about Opensim and reX is connecting from WebNaali > to Opensim. It would be very simple, at least if there is a nice working C# > websocket server module (and I'm sure there is nowadays) (also some Python > one might make sense if could then share the code between Opensim and > Tundra, as the Tundra one uses py). Basically to repeat the old WebNaali > demo by logging in to some Opensim server, and getting an avatar and moving > and chatting there -- the others using Linden viewers or whatever. Could > sync some cube position to test how collaborative editing could work > (another point Ilan advocates is having good simple editing, creation > tools, even just basic at start). > > This could be done either with the WebGL+WebSockets based original > WebNaali, or the alternative Flash3D thing we've been working for one > project right now. A prim editing test with WebGL would certainly be a fun > experiment, and I think is easiest to develop on that anyhow (can just move > vertices from javascript) .. even as a prototype for native Tundra too if > someone want's it there. Simple 3d modellers made with WebGL seem to work > pretty nicely (3dtin and then that one Finnish one, Tinkercad). > > The reason why I've wondered if those browser based things might be > interesting for Opensim folks is that they bring something new, for example > a simple scene viewer to show worlds on websites. As it seemed that on the > native app side people are content with the slviewer base. But if that is > changing now and there's interest for a normal open source viewer project, > I think Tundra is certainly worth considering. Has matured well now for the > basics and is nice to build on. > > With the browser based engines I'm curious about the performance. If they > do clever batching, might render prim style builds fast more easily than > with Ogre .. though I'd guess Ogre is still easily faster for heavy scenes. > Am talking about prims as discussed them with Ilan, about how they can be > useful for quick easy builds .. I think he's right that they can be a > competitive advantage. > > ~Toni > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org > -- http://groups.google.com/group/realxtend http://www.realxtend.org
