[Opensim-dev] client API bindings?

[Maróy Ákos]

Toni,

> Cool idea.

:)

> In OpenSim they are called ClientViews.They implement a protocol which 
> clients can use to connect to the server. The prominent one is for the 
> SL(tm) viewer, but there is an experimental one for another new VW 
> protocol called MXP, and at least an IRC one as well. Also for the 
> Realxtend project there is a modified ClientView where the SL protocol 
> is extended to support Ogre meshes etc.

hm, interesting

> OpenSim is a .NET project, written in C#, so you can use any language 
> that has a .net implementation for writing your thing. IronPython is a 
> pretty cool and mature implementation, I wrote an experimental .py 
> region module loader for OpenSim once and probably you could use it to 
> write a ClientView too if you prefer that to C#. But C# is also nice, 
> kind of a mix of C++ and Python -- if those are what you know from 
> before, should be easy to learn. The API is the same for any .net language.

actually it's not that simple. for example, X-Plane has a plugin 
architecture, that accepts plugins written in C++, or in Python. thust 
the best is if there's a client implementation in any of these 
languages, as one has to create a shared object a python files (without 
native libraries linked) to integrate to X-Plane. (oh, and the native 
ones in three platforms, Linux, MacOS and Windows)

other platforms would behave similarly.

also, if one wants a proliferation of clients, one has to allow for a 
wide range of client implementations.

> It should be feasible in principle, and I think a quite interesting 
> challenge for the platform.

hm hm..

> One problem is that due to the Second Life compatibility origins, the 
> OpenSim worlds are partitioned in 256x256m regions, which run as 
> separate instances. When you cross a region border, there is a handover 
> procedure etc. So the default architecture is not at all suitable for 
> flying 300m/s 'cause you'd need so many regions and it'd be doing the 
> crossing procedure all the time.

yes, this is a problem indeed. moreover, in a flight simulator, the 
horizon spans quite far. also, you actually need different update levels 
- for objects that are close, one needs fast and accurate update, while 
for objects far but still visible, one doesn't need that frequent updates.

moreover, movement prediction is also important - the client needs to be 
able to predict the trajectory of the objects for smooth drawing, and 
graceful handling of network connection issues.

> I think there's an on-going experiment with different sized / large 
> regions, just today Teravus touched this thing it seems, that might 
> serve you and I guess he can tell more - 
> /OpenSim/Region/CoreModules/World/Land/RegionCombinerModule.cs

hm I'll take a look..

> A trick I've been thinking for supporting fast large movements is to 
> change the scale: make your planes 1/100 the size, so the default region 
> size is then 25,6km for the lilliput pilot in the plane :) A 10x10 
> region grid or something would already give quite nice amount of space, 
> and grids can be much larger too. Then you could fly past the giant 
> avatars there and they'd have fun seeing small model planes fly :o

hm, but what is the position precision then? is it precise enough?

> For example in MXP you don't have this kind of region stuff in the 
> protocol at all - there you just have a thing called a bubble, which 
> AFAIK is the sphere of perception for the viewer, and the server always 
> tells the client about the things close to it. The client nor the 
> protocol don't know anything about how the space is partitioned on the 
> server(s). So in the MXP ClientView you can perhaps see an example how 
> to adapt the OpenSim internal scene things to a different protocol.

this sounds a better approach - but one still needs to treat 'near' and 
'far' objects differently (see above)

thanks for the input..


Akos