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.
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.
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?
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.
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.
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”!
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.
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.
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.
Oh awesome Thanks for the update! I appreciate it. I’m looking forward to this but there is no rush as It’s easy for me to work around it (I just don’t use RVO for my agents and things walk though each other). its mostly a cosmetic thing.
Is there any news regarding these scripts that run smoothly regardless of framerate? I am still encountering very jerky movement at high timescales, lower framerates, or worst of all both of them combined. Agents completely overshoot their positions and end up in walls or other game-breaking areas.
I’m having a hard time designing and testing my game because of this. I was wondering how the progress has come along on the new movement scripts you suggested so we can start using them in the beta. If they’re not fully ready yet, I’d really appreciate some sort of alpha at least so I can keep developing my game, because this is game-breaking for me, as precise movements in my game at high timescales are of utmost importance.
Yes! I have released a new beta just a few days ago which includes a new movement script called FollowerEntity. It is designed to be much more robust at higher time-scales. It’s very new, though, so things might be a bit rough.
Before I upgrade, do you have any tips or warnings I should be aware of? Until now I was using a slightly customized movement script tightly based on AIPath with Seeker and RVO, very close to vanilla. Should I now inherit from FollowerPath, or how does the new workflow work? And does it support RVO?
EDIT: Oh crap, I just saw it says " Does not support movement on the grid and point graphs at the moment.". I am using a grid graph atm. Does this mean I cannot use it at all? Maybe some workarounds? If so, when can I expect support for grid graphs to be added?
Yeah, sorry. Right now I have only implemented support for navmesh-based graphs. I’m going to work on adding grid graph support next.
Do not inherit from FollowerPath, use a separate script and access its properties. Or if you want to do non-vanilla stuff you can write a custom ECS system.
It does support RVO out of the box.
I’m glad to hear you’re working on grid graph support next, I’ll wait for that update to test it out immediately when it comes out. I’d appreciate if you could tag me here when it does.
