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

Reply via email to