AIPath + RVO simulation FPS jerky movement on low fps

[caleidon]

It seems that on low fps (20-30ish), my character’s movement seems to stutter and bounce all over the place. I can quickly achieve such low FPS by turning on the gizmos since it’s a 400x400 map and takes a lot just to render the gizmos.

Here’s an example of what it looks like:

In the beginning, it works fine (the game is constantly on maximum speed).

As soon as gizmos are turned on, dropping the FPS, the stuttering begins.

I use AIPath with RVO Controller. The RVO Desired simulation FPS was set to 40. While stuttering, I tried to put the desired FPS to 1, which exaggerated the stuttering problem. Then, I set the desired FPS to 300, and it seemed completely fine.

So clearly, the problem is in the simulation speed.

What’s a good way to deal with this? I could have the simFPS on 60 on 1x speed, 120 on 2x speed, and 300 on 5x speed, but that seems like it’d be hard-coding and there’s no guarantee some bad stuff like this might happen on different FPS variations and scenarios.

[aron_granberg]

Hi

I can unfortunately not watch the video. Neither Chrome nor Firefox seem to be able to play it.
The A* gizmos shouldn’t be that slow. Make sure you use the A* Inspector → Settings → Graph Coloring Mode = Solid Color since that’s the fastest one.

The rvo simulation will never run faster than your game’s fps in any case. So if your game is getting laggy, then the rvo simulation may behave badly regardless of your settings.

[caleidon]

Hey. Sorry for being unable to watch the video. I’ve reuploaded it and I guarantee its availability here:

https://vimeo.com/manage/videos/592737682

The gizmos indeed are that slow. I have a 400x400 map, and even with the solid color one, it wrecks my FPS. It doesn’t matter too much since release builds aren’t suffering from that issue, but still.

Considering RVO simulation never runs faster than the game’s FPS, would it be feasible to set the desired simulation speed to something like 300? If my game is running at 300 FPS, then it might make sense for the simulation to be more precise as well. If my game drops to 30 FPS, then the simulation will follow, and still, produce good enough results.

Is this a good approach, or should I consider other factors when considering RVO simulation FPS?

[aron_granberg]

@caleidon

Considering RVO simulation never runs faster than the game’s FPS, would it be feasible to set the desired simulation speed to something like 300? If my game is running at 300 FPS, then it might make sense for the simulation to be more precise as well. If my game drops to 30 FPS, then the simulation will follow, and still, produce good enough results.

Sure. Settin the desired simulation fps to 300 essentially just says “run it as fast as you can, every frame”. Which is completely reasonable.

[caleidon]

Necroing this old post to emphasize that this is still an issue.

New video where issue is present:
RVO jerky movement on high timeScale - YouTube

Here’s what’s happening in the video: I am pushing the RVO system to its limits with 300+ units at one time (which will likely not be needed for my game but it’s not impossible that it happens).

• at some points in the video, I change from 1x speed to 3x or 5x (changing Time.timeScale)
• I also purposely lower my FPS to 15-20 because that’s when the simulation starts suffering

It seems like even at 17 FPS (but at 1x speed) the simulation looks just fine and units are following their paths, but when I put it on 5x speed (note that the framerate is still similar) every agent goes crazy and starts overshooting their paths. It’s almost like the simulation has 5x less time to calculate but the FPS is the same.

What I’m suggesting:
Is there some way to get around this, or could you implement a feature where we can force the RVO simulation to complete whatever it needs to do just to make sure it’s accurate (even at the cost of FPS)? I’m not sure if this is the intended behavior or a bug, but either way we should have some ability to get around this because speeding up time is the core mechanic in my game and it might suffer because of this issue. I’d be glad to provide more information if needed.

[Max_Nielsen1]

I second this issue, the wobble at a high timescale is a big issue. Especially when FPS drops.

[aron_granberg]

Hi

Yeah, this is an issue at the moment.
What would be required is that when the RVOSimulator detects that a higher time scale is used, it will run multiple simulation iterations per frame. Sadly, this is not very easy to implement right now because it also requires the movement scripts to run interleaved with the RVOSimulator multiple times per frame. I am working on some re-architecturing of the package to make this possible and work as expected out of the box, but right now it’s a bit hard.

You might be able to get away with just running the movement scripts at a higher number of iterations per frame. This can be done relatively easily using a separate script. See this post: RichAI + Recast Graph falls though terrain - #9 by aron_granberg

[caleidon]

Hi! Thanks for acknowledging this issue. The workaround you suggest does seem a bit hacky. This issue isn’t very concerning to me right now, but I do hope that you can prioritize fixing it in the next couple of beta releases so it just works “out of the box”!

[aron_granberg]

@caleidon

The workaround you suggest does seem a bit hacky.

It’s not really that hacky. Except for also tying it in to the RVO system, that would essentially be what my out of the box solution for this would be.

[caleidon]

What I meant is that I’d rather wait for you to implement this and use it as-is than using the workaround right now and forgetting about it later, especially since you said it seems simple enough to implement.

[slippyfrog]

Hello, I’m also running into some issues using RVO and Greater-Than-1 timescales.

@caleidon did you eventually get to implementing the recommend solution?

@Aaron is there a road map for this feature making it into code?

Anyways thanks for maintains the middleware and for you ongoing support on this forum!

[caleidon]

@aron_granberg tagging you because it seems @slippyfrog missed the username.

No, I still didn’t implement the workaround because I thought this was a core feature and should be handled by Aron.

Is this issue still present?

[aron_granberg]

Hi

Yes. There is a roadmap for this. I am currently working on making a lot of things ecs-compatible. As part of this, I’m rewriting the movement scripts. The new movement script supports any timescale out of the box. It will automatically run the simulation at a higher fps if necessary.
It may be a little while before this gets to the beta, though. But I am working on it as fast as I can.