Now that rvonavmesh and rvo colliders are a thing of the past, how are we supposed to inform the rvo about our environment?
Also, is there a place in your documentation that explains the concept of using RVO with PATHS in the context of a custom movement script and also how to deal with moving objects? (props with rigidbodies)
Thank you.
Hi
The built-in movement scripts will inform the RVOController about any collisions with the edges of the graph.
Ideally, the RVO should also know about obstacles as you say. However, at least in my experiments I’ve found that this hasn’t been worth it, and actually often reduces the naturalness of the motion. Primarily the reason is just that I have rewritten the RVO several times now, and I haven’t had time to add obstacles in this latest iteration, and due to the above observations, it hasn’t been a high priority.
Ok, I’ll wait and see what you come up with in the future for collisions. I will have to use a spatial partitioning anyway, so I may try using that.
Regarding RVOController, isn’t it a “character controller”? I hope it’s not the only way, because I can’t use that with an entity system processing thousands of units. Also, since paths are a series of waypoints, how do you get one to a “far enough” distance to feed to the RVO system? Do you just use the next waypoint, regardless of how far it is? I’m doing this right now and not having great results.
Also, in the “LightweightRVO” example, is there a reason you are using IJob instead of IJobParallelFor? IJob runs the code outside the main thread, but still does it in a single one. You could get a major boosts with the 16 to 32 threads we have now.
Also, If you haven’t seen this already, look into vectorization.
https://docs.unity3d.com/Packages/com.unity.burst@1.4/manual/docs/OptimizationGuidelines.html
Basically, you stuff your operations inside Float4s and the CPU manages to do it 10 to 100x faster depending on the operation. It requires a bit of rethinking your code, but it’s worth it.
After further tests, modifying Lightweight RVO with IJobParallelFor my test (32766 agents @ 3fps + double buffering) went from 250fps to 320 fps. But the largest gain was obtained by reordering the scheduling and completion of the jobs allowing to reach 420fps.
Unfortunatly this reordering requires setting a job dependency when scheduling your QuadTreeJob in RVOCoreSimulatorBurst.cs (I think that’s the file).
It would really help if you could add an official way to set dependencies and get a hold of the job handles in A*. Running so many ai requires rethinking how we do everything, and not being able to control or know the exact moment data becomes accessible is a HUGE problem. Those of us using jobs and an entity systems most likely all modify your code, but that’s a PITA at every update.
Onto another subject, the entity example in lightweight is indeed “lightweight”, a lot of important features are missing, so much so that it’s kind of useless (no offence meant). So unless you have other entity oriented scripts or RVOController implementations somewhere, I think I’ll have to take apart RVOExampleAgent(or RichAI) and RVOController to get anything done.
If you have anything, even unfinished, I’ll take it and If it helps I don’t mind sending the code back once I get it working.
BTW I made an implementation of Lightweight RVO that would be much easier to use with entities.
I split it in 2 scripts, one handles RVO, the other is a manager.
CollisionAvoidanceProvider.cs.txt (8.1 KB)
EntityManagerRVOExample.cs.txt (8.6 KB)
This approach would make A* much easier to implement for anyone not using the old AI scripts.
(FYI those scripts are still a bit raw and extra work could be done to stabilize the latency. Also, they do not include the modifications I did to reorder scheduling.)
Another edit:
The quad tree you use in the RVO system, what is it for? Could I query it for collision checking? While we’re at it, why not make it an Octree and add an OnCollision(entityID) event + a raycast implementation? Makes sense if you already maintain a tree.
No particular reason. I don’t think those jobs are a major performance drain, though. But yeah, I should change them to parallel jobs.
Yeah, that script is primarily intended as a starting point for someone wanting to use local avoidance from the job system and without the overhead of GameObjects. It is definitely light on features.
You probably could use it for collision checking. It’s not optimized for that purpose, it might be tricky to extract the relevant information from it.
I don’t want to add a lot of code to the package for very niche use cases, especially to the high performance parts. So I’ll probably skip on the raycast implementation. Collision might be something to consider though.