RichAI, only simulate, manually follow

General Recast graph
#1

I have to admit, I have been having an absolute devil of a time getting this package integrated into my game.

A wrinkle is I’m pathfinding vehicles, but I keep it really simple, by merely reducing the speed when not facing the right direction. This tactic worked well enough with Unity’s pathfinding system, and worked fine with RichAI in my example project, so I don’t think this is the source of my numerous problems.

Besides that, I just need to align the units to the ground, and that’s proving to be an unbelievable hassle.

I am using RichAI, but I have disabled movePosition and moveRotation, instead opting to follow it via rotating and translating based on the steeringDirection, thinking that’ll give me the freedom I need to control the speed and rotation for my needs.

Velocity seems to only represent actual movement in the last frame, so that’s unreliable. I have no clue what desiredVelocity is feeding me, because the units will just drive off into the sunset, down the +X axis. I used those equivalents in Unity’s pathfinding, and they were useful, but here, I steeringDirection is the only variable I seem to be able to trust.

If I were to summarize my troubles, the pathfinding system seems deathly afraid of hills, or anything where the normal isn’t straight up.

I made a little test “hill” with a very shallow sphere.
image

Getting the nearest position seems to avoid hills, jumping to the closest flat area next to the hill.

Paths seem to avoid the smallest hills, as if they’re huge obstacles.

Any time my unit is on ANY hill, the unit will “jitter.” Its speed will be erratic. If it’s totally flat, it’ll work normally.

Does the steering direction account for hills at all? I can’t tell so far.

Any ideas how to proceed?

I’m just fiddling endlessly, and I don’t feel like I’m making progress. Honestly, I didn’t think I’d be spending days and days on this, considering I had it working with Unity’s janky pathfinding.

#2

Hi

Do you mean updatePosition and updateRotation? There are no fields called movePosition nor moveRotation. If so, that could explain a lot. When updatePosition is false the agent will no longer tie its position to the Transform it is attached to, so the agent may be at a completely different position than the position of the Transform. (see its documentation for more details).

If you want to override the internal movement logic of the agent I would recommend that you use ai.MovementUpdate, you can find an example here: https://arongranberg.com/astar/docs/iastarai.html#MovementUpdate

Recast graphs can have trouble with large open areas that only have elevation changes. There are not enough triangles there to be able to pathfind accurately. See also the bottom of this page: https://arongranberg.com/astar/docs/getstarted2.html#navmeshnotes
Unity’s pathfinding algorithm and navmesh have some tweaks to make this easier for them though.
If your world is not too large I would recommend a grid graph in those cases instead since they are much more predictable.

#3

Apologies, I meant updatePosition and updateRotation. Sorry, getting confused with all these changes I’ve made the last few days.

In an ideal world, I’d like to just slap the RichAI (or an equivalent) on the root of my unit game object, and let it “drive.” But I was having so many troubles, I started experimenting with letting it merely simulate its movement, and having my unit follow the simulation. That’s broadly my poorly stated question here.

Of course, without making much progress on that front, I gave up on that a while ago, and split the RichAI onto its own game object, and having my unit follow the invisible RichAI game object, that way I can control the position and rotation without interfering or rewriting RichAI.

Regarding the graph to choose, my units are of radically different sizes. Does the grid graph know how to handle units of widely varying radii? My gut said no.

Thanks for the insight.

#4

Ah, I see.

It does not, but neither does the recast graph.
You can follow the same technique as in this tutorial for grid graphs: https://arongranberg.com/astar/docs/multipleagenttypes.html

Note that if you want full control over all the movement parts, you can write your own movement script. This is a bit more work, but if you want a type of movement that the included scripts do not provide, it can be an easier option than trying to shoe-horn those to fit. Take a look at this tutorial in which you will learn how to write a (very basic) movement script: https://arongranberg.com/astar/docs/custom_movement_script.html

#5

Good news is, I have already implemented the multiple graphs based on different radii, as that was effectively the same strategy I used when using Unity’s navigation system. As you informed me earlier, I missed targeting the agent to use that particular graph, but that has been remedied for a few days now.

The RVO will still have those agents on different graphs bump into each other, right? I haven’t actually gotten to testing multiple agents of different sizes yet, since I have had so much troubles just getting them to do basic things like climb hills.

Thanks for the continued insight.

#6

RVO is completely separate from pathfinding. Pathfinding doesn’t know about RVO and RVO doesn’t know about pathfinding or the graphs in any way. So it works with any graph that you use.

#7

Excellent.

Thank you for all the advice in getting this going. It’s starting to come together, finally!

1 Like