[Opensim-dev] Server based navigation/pathfinding

[Toni Alatalo]

Teravus Ovares kirjoitti:
> stored on the simulator and there's a chance that if you start now, in
> a month or two, the module will be obsolite because the API changed
> significantly.     I would wait until about 2 weeks after 0.7 is
> tagged..     which should be sometime in January.
>   

That is a valid point, and perhaps good advice, but I still think that 
you don't necessarily need to wait to proceed with new things like this 
that use the scene data. I believe that if this was done now, it would 
be quite simple to port to the new system later. After all, very many 
things in opensim itself and other modules need to be ported, so the 
refactoring can't make all those obsolete, 'cause we'd end up with 
having no functionality at all. The same data remains there, just 
accessed in a different way which doesn't make much of a difference to 
an algorithm like A* .. It doesn't change basically anything about the 
actual work a module like this need to do (generate a waypoint graph, 
have a a* backed autopilot impl).

So if the original poster wants it quick, can just do it, and the work 
won't be wasted - just needs some porting later. If is not in a hurry 
and wants to save the trouble of learning the scene API twice, first the 
old and then the new, is a good idea to wait indeed.

> 2009/12/23 V.Rovensky <v.rovensky at lit.cz>:
>   
>> to find the route for my bot. I was thinking I could create an invisible
>> prim for every waypoint and reimplement the autopilot function so it suits
>> my needs a little more. To do this I suppose I need to do the following:
>>     

With these manual markers this seems quite simple. Before noticed this 
part, was thinking that the navigability of different kind of geoms 
might be very difficult to deduce from just the visible geometry or even 
collision data, especially if you'd need to support arbitrary kind of 
builds by users etc, query the physics code or something etc.

>>     1) Be able to access all the region's prims, their locations and shapes
>> to create and manage the graph of waypoints
>>     

How do you get the connections for the graph if you have the points 
only? And how do you know which of the scene entities are waypoint 
markers - use simply some naming convention perhaps?

>>     2) Be able to reimplement the autopilot function, so whenever the
>> client starts autopilot, my method gets called and sends the client along
>> the computed route.
>> Could this be done via RegionModules? I'm fairly new to OpenSim development,
>> so any tips that could point me the right way would be greatly appreciated.
>>     

Seems like a good fit for region modules to me, 'cause what they get 
from the sim is a reference to a scene object where you can get all the 
scene objects (i hate the term 'prim' for them which is just one way to 
define geometry :p) .. am not sure how you'd go about hooking this to 
the existing autopilot mechanism, but I'm sure it's possible somehow. 
And that part (if it relates to scriptengine etc) I guess won't be 
affected by the sceneobjectgroup/sceneobjectpart refactor (much) at all.

If/as you just need the positions of your custom scene objects to form 
the graph from those nodes, my guess actually is that the refactor may 
result in very little code changes to this tool (5-10 lines change 
perhaps, just the call how to get all entities (of a type?), and then 
how to read position data from them? is just an ignorant guess, not 
knowing much of the details of the current impl or the new plans .. i 
know how a* works in our games though and what the opensim primdata is).

A big idea behind the upcoming refactoring is that the core would 
support applications having arbitrary data about scenes - for example 
navigation graphs. In the new model I think a navigation graph like 
yours could be a component type, which you could register to the system 
from your module and the core could then store it etc. And perhaps 
support communicating it to the outside too - we have the same 
entity-component model in the Naali viewer, and the idea is that we'd 
then support having custom components both on the viewer and the server 
and networking to sync the data in between. So that you could just make 
the graph in the viewer with a custom editor for that, and it'd be 
synched to the server as well, and you could e.g. do a* on eiher or both 
depending on needs.

>> V.Rovensky
>>     

~Toni