Add RVO collision avoidance

[nathanmerrill]

No description provided.

[nathanmerrill]

PLEASE DO NOT MERGE YET. I'm confident there are memory leaks and a gazillion things wrong with this.

[Mika571]

Nice, I was considering doing this exact thing!

[realkotob]

This sounds really cool but what does it do exactly (I did see any additions to the docs in the commits).

[volzhs]

@asheraryam
https://www.youtube.com/watch?v=1Fn3Mz6f5xA

[realkotob]

That looks great, there's even a 3d version that seems useful as well.

[nathanmerrill]

Fixes #1887

[nathanmerrill]

@asheraryam the 3D version is much less useful than the 2D version for two reasons:

1. Actors typically move in 2 dimensions, even in a 3D world. A RTS with 3D terrain still wants to use 2D collision avoidance, as units are bound to the ground. 3D collision avoidance is primarily for stuff like spaceships avoiding collisions in 3D space.
2. The 3D version of the library doesn't support obstacles.

[realkotob]

@nathanmerrill Sure I wasn't actually suggesting the 3D version be added to the engine, it's not useful for most people.

(It's just useful for me personally since I'm currently working on a project with 3D navigation for dozen agents concurrently, but I use a custom 3d boids flocking code with the extra behaviours I want and that does good enough.)

[realkotob]

I'm looking at the docs, is it possible to use this as-is with the current Navigation node to adjust an agent's path?

For example pass the resulting path array from Navigation to the RVO module and have it return an adjusted path that avoids the other actors?

Almost no navigation happens on straight ground with no walls or gaps, so RVO on its own wouldn't help in any real scenario unless it can interface with Navigation.

Edit2: From what I see the "navigate()" method in this PR directly changes the object's velocity, so it would not immediately work with common cases of how Navigation is usually used where the path array is used to iterate every frame and move() to the next point in the list.

However, since RVO has an add_obstacles method, then it should be possible to link a Nav mesh to the RVO node and have it use the baked obstacles for its own RVO obstacles or vice versa.

But I guess that could be out of the scope of this PR so it can wait :D

Also great work looking forward to trying it out!

Edit: Related issues #3130 #3821 #17885

[nathanmerrill]

I'm looking at the docs, is it possible to use this as-is with the current Navigation node to adjust an agent's path?

Potentially, yes. I like the idea of having this as a separate module, but a tighter integration can definitely work.

For example pass the resulting path array from Navigation to the RVO module and have it return an adjusted path that avoids the other actors?

The library I'm using doesn't handle multi-step path adjustments. The input to the algorithm is (1) All actor's current positions and velocity, and (2) the current actor's preferred velocity. It will then return an adjusted preferred velocity. If you are able to predict all of the actors' future position and velocity, then you could do this, but such an algorithm sounds difficult and makes a lot of assumptions.

I have gotten this to work with Navigation2D. The key is that you using Navigation to generate the overall path, and then use collision avoidance to navigate actors each tick. A small issue with this is that actors likely won't hit each point of the path exactly, but the fix is to check if the actor is within a certain radius of their destination.

[realkotob]

I have gotten this to work with Navigation2D. The key is that you using Navigation to generate the overall path, and then use collision avoidance to navigate actors each tick.

That's not a bad way to go about it, it should work for Navigation in 3D as well 😄

A small issue with this is that actors likely won't hit each point of the path exactly, but the fix is to check if the actor is within a certain radius of their destination.

Not sure if measuring distance from destination is a good fix, it could be a better idea to just demand a new simple_path() after navigating each frame.

The idea is that we usually navigate the simple_path by iterating over each point, if the agents go off the path then it's basically void and needs to be recalculated again.

[vini-guerrero]

@nathanmerrill Can this be used to build custom behaviours? And change between then? E.g. is it handled in physics? Trying to understand how to use it properly for npcs in (wander / seek)... Are there any dependencies for compiling it on current stable version 3.1.1?

[nathanmerrill]

@vini-guerrero there aren't any external dependencies.

This is not handled by the physics engine at all. The core of the entire behavior lies in the navigate() function: It takes a desired velocity, and returns an adjusted velocity (adjusted to avoid obstacles). The velocity you pass in (perhaps to imitate wandering) is totally up to you, and you can choose to ignore the velocity returned.

[vini-guerrero]

Awesome work on that @nathanmerrill! I'm working on a project that depends on this but it's currently on 3.1.1, since this adds a new lib shouldn't break compatibility with older versions right? Right now, I'm handling everything inside physics and Area2D, could achieve a better performance specially for mobile...

[nathanmerrill]

@vini-guerrero As far as Godot-dependencies, I depend on these types: Rect2, PoolVector2Array, Vector2, Vector, Node2D, and the parts that help expose my module. I don't know when those were added, but if they are missing/different in 3.1.1, then this won't work.

[Calinou]

@nathanmerrill These are all available in Godot 3.0 and later, it should be fine.

[vini-guerrero]

Is this related to the module itself or my something wrong with my compile process?
Note: I was able to compile 3.1 without this module with no issues

scons platform=osx
scons: Reading SConscript files ...
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
scons: warning: Ignoring missing SConscript 'modules/orca/SCsub'
File "/Users/vinny-guerrero/Desktop/Godot/godot/modules/SCsub", line 17, in
YASM is necessary for WebM SIMD optimizations.
WebM SIMD optimizations are disabled. Check if your CPU architecture, CPU bits or platform are supported!
Checking for C header file mntent.h... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
[Initial build] Linking Program ==> bin/godot.osx.tools.64
Undefined symbols for architecture x86_64:
"register_orca_types()", referenced from:
register_module_types() in libmodules.osx.tools.64.a(register_module_types.gen.osx.tools.64.o)
"unregister_orca_types()", referenced from:
unregister_module_types() in libmodules.osx.tools.64.a(register_module_types.gen.osx.tools.64.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
scons: *** [bin/godot.osx.tools.64] Error 1
scons: building terminated because of errors.

[nathanmerrill]

@vini-guerrero I'm suspecting the warning at the start is the real problem:

scons: warning: Ignoring missing SConscript 'modules/orca/SCsub'

I'm not sure why you are getting that warning, as it appears in the commit.

[HeadClot]

Hey can we merge this into 3.2 I know we are in feature freeze but this is a mission critical feature for 3D Godot games. Collision avoidance is non existent because detour is not integrated into Godot.

Here is some videos and a Issue to prove my point.

#3130

https://www.youtube.com/watch?v=hR7FTA6iAYY

https://www.youtube.com/watch?v=DUMs5B1Ffc8

[Duroxxigar]

I agree with @HeadClot - even with 4.0 "reworking everything", that's still quite a long ways away. This could serve as a holdover until then.

[HeadClot]

What @Duroxxigar said. If that is not possible put it into a patch version like Godot 3.2.1 or whatever.

[Calinou]

@HeadClot This could be considered for a point release like 3.2.1, but not for 3.2 as it's already in feature freeze.

Edit: @reduz said it won't be suitable for a merge in 3.2.x due to heavy changes coming to navigation in 4.0. Sorry 🙁

[HeadClot]

Thank you @Calinou :)

[fire]

What version of RVO is this? Is there a git hash or a version number?

[nathanmerrill]

Version 2.0.2. This is listed in thirdparty/README.md

[AndreaCatania]

Hey @nathanmerrill I'm working on top of this PR in order to use it for 3D objects too.

I'm implementing it in a different way in order to "automatically" add the physics object in the RVO engine, and use the server code for both 2D and 3D.

I would like to push my changes directly on this PR, so we can both contribute on this feature. Would you like that?

[nathanmerrill]

@AndreaCatania I'm not sure what you mean.

Are you talking about reusing CollisionObject as obstacles, and some other node as the actors?

I don't think that is a good idea, as users may want to separate collision logic from collision avoidance.

Regardless, I'm totally fine with you contributing a 3D version of this code.

[AndreaCatania]

@nathanmerrill I've created a new PR, since in this way I'm faster: #34485
Despite this I'll add you as co-author once I'll finish it. In the meanwhile you are welcome to suggest changes or contribute on my code if you wish.

Thanks.

[Calinou]

@nathanmerrill By the way, we're discussing the upcoming navigation system in Godot 4.0 on IRC (#godotengine-devel @ irc.freenode.net). Feel free to join if you'd like.

[Calinou]

What's the status on this now that #34776 was merged?

[akien-mga]

This was superseded by #34776 indeed. Thanks for the contribution nevertheless, which I think was used as a base for #34776.