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 _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
