Growing support for OpenSim compatible viewer.

[Lord]

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. 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. 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.

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. 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/ ) .

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.

[Toni Alatalo]

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

[Jonne Nauha]

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

--
http://groups.google.com/group/realxtend
http://www.realxtend.org

[Ilan Tochner]

Hi Jonne,

 

We all want to see realXtend succeed and I’ve been working to help realXtend become a viable solution for several years now, ever since my involvement with Alon Zakai (the creator of Emscripten) on Syntensity.

 

RealXtend’s long-term success as an open-source project depends on dev-community growth and wide-scale adoption of realXtend-based solutions. While Kitely currently doesn’t have the manpower or the financial resources to do actual realXtend-related development, I have been openly campaigning for realXtend adoption by the OpenSim developer community for almost a year. I’ve done so in private talks with key OpenSim devs and in public recorded presentations and interviews I gave inSL (Toni and others can attest to this fact). One recent result of these direct conversations is that David Daeschler from InWorldz (which is currently the biggest OpenSim-derived grid in active user numbers) is willing to allocate development resources to help make realXtend a viable viewer for OpenSim-based worlds.

 

As for realXtend-based solution adoption, Kitely is a high-profile player in the OpenSim community. Our open support and adoption of realXtend has real PR value for the project. For realXtend to get consumer traction and become a viable alternative to OpenSim, it needs to have high profile OpenSim providers, such as Kitely and InWorldz, publicly adopt it. Doing so will attract OpenSim (and TPV) developers to work on realXtend. It will also create more business opportunities for all the companies currently developing realXtend.

 

Finally, I’ve recently started campaigning to get realXtend additional funding from third-parties. I’ve encountered some good initial reactions from people but it’s way too soon to know if any of this will result in donations to the foundation.

 

As for your comments about the technical aspects of how to go about implementing this, I tend to agree. realXtend needs to be able to support manipulating prims and SL-type avatars to help migration of SL/OpenSim content into realXtend but ,even if there is an interim period during which OpenSim is used as the backend, in the long run realXtend can offer a better engineered solution without using the OpenSim backend. However, for people to be able to move over to 100% realXtend solution, that solution needs to maintain the prim capabilities and the SL-type avatars. It shouldn’t be as a hardcoded part of realXtend but these capabilities should be supported independently of OpenSim and its inefficient protocols. A scripted UI and a protocol translation layer that can be moved from the viewer to the server and eventually eliminated can help shorten this transition period.

 

Cheers,

 

Ilan Tochner
Co-Founder and CEO
Kitely Ltd.

[Antti Ilomäki]

As an old OpenSim fanboi I welcome this development with open arms,
unfortunately that doesn't account for much, since it's best for
everyone I don't write code and I don't have much resources available.
The ideology behind realXtend has always been openness and it would be
great to co-operate with OpenSim developers and I would be happy if
they could utilize realXtend for their purposes.

I'm sure we can come up with ways to co-operate and please, if you
have questions or general interest in anything realXtend please ask
and we will do our best to reply.

[ATupper]

To me it would seem that the optimal solution would be a project
loosely coupled with both of the development teams for ReX and
Opensim. This breed of Tundra-based Opensim viewer does show a
substantial amount of promise, but it would really need a dedicated
team to dig in and suss out all of the inevitable roadblocks without
diverting resources away from either of the core teams. This might be
the place for a for-profit venture to step in to take up the flag of
doing the heavy grunt work to get a implementation cranked out and
released into the wild. Such a venture would have to develop the
viewer with its' release as open-source as a given and build a
business model around leveraging services around it.

While we're tossing around blue-sky concepts for a hybrid, I'd like to
point out a big advantage of not hard-coding the viewer UI is the
ability to experiment with radically different layouts (Ilan touched
on this tangentially). One of my longest running soapbox rants is
that for new adopters of Opensim/SL, the viewer is too complicated and
loaded with functionality that they don't want or need. It's much
like giving an industrial-grade smelter to someone who just wants an
EZ-Bake oven. There are of course plenty of people who do want and
need the advanced functionality, but those people are very rarely the
ones who are trying out the platform for the first time. By not
hardcoding the UI, there's a lot more freedom to experiment with a
simplified experience that will help draw in new users. Theoretically,
if we can make it easier for new users to have positive experiences
with both Opensim and ReX, it will lead to a positive feedback loop.

[Lord]

Sorry Alan, I just saw your post.  I do agree with most of what you said, but I was thinking along the lines of a Kickstarter or Crowdfunder type of scenario to pay one of the current OpenSim or Tundra TPV's to make the hybrid viewer ?   Another thing I have been thinking about was that it seemed that Ogre would be incompatible with OpenSim and wondering why it wasn't a module instead of part of the core, so that it could be more easily switched in or out as needed and to keep everything as small and fast as possible ?

[Toni Alatalo]

On Jun 6, 2012, at 7:03 AM, Lord wrote:

to make the hybrid viewer ?   Another thing I have been thinking about was that it seemed that Ogre would be incompatible with OpenSim and wondering why it wasn't a module instead of part of the core, so that it could be more easily switched in or out as needed and to keep everything as small and fast as possible ?

Ogre isn't really incompatible with OpenSim -- Naali (~old version of Tundra) itself demonstrates that, for example this screenshot from osgrid shows a primboard in Naali 0.1, https://www.dropbox.com/gallery/1002746/1/naali?h=d9f90e#gallery:12

It is just that it doesn't do batching automagically, so for efficient rendering of large prim builds (say a house with staircases etc resulting in 2000 prims) the prim support with Ogre would need to be implemented so that nearby prims using the same materials are combined to single objects etc. Lasse (the dev from Ludocraft who wrote Naali's (and hence Tundra's) rendering module made a plan for that back then, was iirc 1-3 man months work. The same technique would work also for user created content made with meshes, is not specific to prims only. I guess an alternative would be to implement prim rendering with some kind of special prim rendering code.

And the rendering with Ogre is in a module, just that for simplicity the Ogre types are used also in scene core currently. That may change depending on how well Ogre suits all the needs in the future, for example how it runs on current mobile devices etc. Ogre itself is quite small and very modular (the main dll is some 300kb iirc? then scene managers, directx/opengl etc renderers and for example particles are optional plugins) so it is often not a problem.

~Toni