[Opensim-dev] client API bindings?

[Toni Alatalo]

On Sep 3, 2009, at 5:55 PM, Maróy Ákos wrote:

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

Hm, trying to get what you are saying exactly .. are you saying this is 
something that applies to both the server and clients?

Where do you create the shared python objects? On either end, and then 
those are sent across and deserialized? I know how pickles work and how 
those can be used for sharing state, but am actually very surprised to 
hear that x-plane would use them in the protocol. I don't know 
basically anything about x-plane before.

As you say 'without native libraries linked', perhaps ironpython and 
cpython are compatible, or can be made so, on that level .. am not sure 
exactly but we can find that out, if that indeed is the need .. i'm not 
sure I understood this correctly. Sounds that it may be really cool 
(pickles can be arbitary data and code .. which is also why they are 
often not used for security reasons, you must know what you are doing 
if you use them .. that might be a reason why linking to native libs is 
not allowed, dunno :o)

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

Well I thought that if you write an x-plane protocol implementation as 
an OpenSim plugin, a XplaneClientView or something, it would support 
any client that talks that protocol. Like the SL, MXP and IRC 
ClientViews do support any compatible clients.

>> One problem is that due to the Second Life compatibility origins, the
>> OpenSim worlds are partitioned in 256x256m regions, which run as
> 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.

For that it may not actually be much of a problem. As you can see in 
the viewers now, the horizon can span far. In ones that talk sl 
protocol the viewers can know about several regions at a time, so they 
can draw the neighbouring ones too, and they draw sky and sea etc. 
however they want of course.

And there needs to be LOD (level of detail) systems for all usages, in 
many ways (for movement update detail amount, for 3d data resolution 
etc.).

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

Again, I thought that this was about a server implementation, as 
OpenSim is a server platform / SDK, and that you'd use existing Xplane 
clients. Or do you mean that the server also communicates expected 
trajectories, so the client can draw based on the 'future' info too? 
Should be doable, if it's done elsewhere too..

Client side movement interpolation is implemented in the current 
viewers, even in our Realxtend Naal which in very early stages still 
(0.0.1 dev preview was published in June after 4 months of dev work, 
0.0.2 is targeted in october or so and something like 0.1 perhaps by 
the end of the year). So I don't know how much of that you need on the 
server with xplane, but certainly sounds like something that flight 
servers could do .. and again very cool if they do.

>> 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
> hm, but what is the position precision then? is it precise enough?

May be, could be tested .. I think they are floats, at least in our 
viewer, and floats are IIRC accurate near 1.0 .. hmhm well we can see, 
or someone wiser can tell, am too tired to do any math right now here.

>> 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
> this sounds a better approach - but one still needs to treat 'near' and
> 'far' objects differently (see above)

Yes, both server and client need to be smart about that. Server to know 
what to send I guess, and client for what to draw (or what to request 
from server, when server can be dummier? Dunno, but there probably are 
solutions to this in places).

> Akos

~Toni