Hey, Arcana! Any chance you've got a function laying around that returns a list of every pre-defined map coordinate in a given map file that's within X world-units of the "current position"? No? Well, it never hurts to ask, heh.
So, thinking out loud, and basing on the "beacon" situation (where I'm using "beacon" to mean any map entry at all that can be used as a reference point for a bot, rather than meaning the things inside the map file that are explicitly labeled as beacons) in a city map (Atlas Park) and a hybrid city/outdoor map (Croatoa) here's what I'm thinking I need to do:
Dump the scene graph into a SQL database of reference points. These would be the computed absolute positions of each point.
Label each reference point as a "beacon" or an "obstacle". For now, I'm not sutzing over the collision box of the obstacle but if the label of the obstacle is helpful enough to include a measurement in its name then I might save that data as well. Probably I'll want to label each reference point with a type that indicates the originally intended purpose of the reference point, to be used to "weight" actual Omni/NAV reference points higher than others.
Is it useful to know the facing (yaw) of obstacles? Maybe. Walls, certainly; not so much other kinds of obstacles. Hmmm... I think I might need to know the size of the collision boxes after all. How hard is it to pull that information out of the .geo files?
A tick of movement conceptually would go like this:
Compute a "movement unit vector" that is the unit vector of destination - current_position.
Compute a "tick vector" that is Ux,Uy,Uz + Vx,Vy,Vz
Select a list of all NAV points that lie along the "tick vector".
For each NAV point, compute a seek steering force that moves toward that NAV point. The result is a "tick vector" that lies between all nearby NAV points.
If there are no nearby NAV points (that is, map objects named "Omni/NAV") run the check again for non-NAV "beacons" - spawn points, mainly, but possibly other kinds of ref points as well.
Select a list of all obstacles that lie along the current "tick vector". These are primarily objects like bushes, trees, rocks, walls, fences, and buildings.
For each obstacle along the "tick vector", compute an avoidance steering force. This is where collision boxes might be necessary, to modify the magnitude of the steering force in order to clear the obstacle. The result should be a "tick vector" that follows an "optimal" path between all nearby reference points.
In an ideal world, this means that NAV points (or any point being utilized as a "movement beacon") are "pulling" Rover towards themselves while obstacles are "pushing" Rover away from themselves.
This still doesn't entirely solve the problem of sloping terrain but the ref points in the map files are mostly at ground level already and Rover can include some filters that drop ref points that are clearly set at a higher delta-Y than, say, the height of a small hill or a flight of stairs. I think we can pretty much ignore the idea of Rover ever navigating a nightmare like The Hollows.