Does it support Line Obstacle?

[sunsvip]

Hello, thank you for freely sharing such a great project. Compared to the regular multithreaded RVO2, the Job System has significantly improved. However, the original RVO2 supports adding a line obstacle using two points, which the ORCA implementation cannot achieve. Is there a bug in the ObstacleOrientationJob.cs script? How can this be fixed? Thank you!

[Nebukam]

Hey there @sunsvip ! Short answer: YES.

ORCA obstacles are edge-based (or segment-based if you will). Any obstacle is really just a polygon, and it can be an open one, so a RVO2 LineObstacle is really just a single-edge polygon with ORCA.

You can test it for yourself with the provided Setup example, by changing the Min/Max obstacle edge with a value of 2, which effectively generates a single edge:

Roughly the syntax to add an edge would look like this:

ObstacleGroup obstacles = new ObstacleGroup(); //Obstacle group used with the simulation

float3 pointA, pointB;
float3[] edge = { pointA, pointB }; //An edge made of two points

obstacles.Add(edge);

Hope this helps!

[sunsvip]

Thank you for your reply. Yes, I've tried these approaches and they all failed. I seem to have found some clues: for polygonal obstacles, the vertex order must be counterclockwise. For the bounding box, the vertex order must be clockwise. However, there still exists a problem, as shown in the screenshot below: obs 0 and obs 1 are two identical Edge Obstacles. Obs 0 does not contain any other obstacles inside, so it can successfully block the agent within its range. However, obs 1 contains an obstacle inside, which seems to prevent it from effectively blocking the agent completely.

[sunsvip]

When I remove the obstacles inside Edge Obstacle, the agent no longer overflows the boundaries.

[Nebukam]

Hmmm I'll be looking into this, I've been able to reproduce the issue on my end.
I suspect the maths and the way I'm building the KD tree for obstacles fails to recognize the edges as an obstacles if the vertices are too far apart if there are smaller obstacles to check.

I'll see if I can find a quick fix, althought I suspect a workaround would be to split long edges into smaller ones, i.e turning this
x-----------------x into this x-----x-----x-----x.

If it turns out it solves the issue I'll add a some code to automate the splitting on ORCA's side and push an update, I'll keep you posted!

[Nebukam]

Ok so it's fixed. I pushed an update to the repo and bumped the version, so please update the package to 1.1.7 from the package manager and let me know how it works for you :)
(Also just in case, make sure you have Burst compile enabled in that wasn't the case before)

The problem:

when obstacles segments are too far apart, the agent is "blind" to these segments, leading to inconsistent behavior depending on that agent' position toward the obstacle and its vertices.

The fix:

Admittedly not the most elegant fix, but it works 100% of the time:
Subdivide obstacles edges to smaller segments.
I added methods & parameters to that effect so you can keep obstacle admin simple (i.e, a square is still 4 vertices when added)
I also updated the ORCA Setup example to account for the update.

float3[] squarePoints = new float3[] {
    float3(min.x, min.y, 0f) * 1.2f,
    float3(min.x, max.y, 0f)* 1.2f,
    float3(max.x, max.y, 0f)* 1.2f,
    float3(max.x, min.y, 0f)* 1.2f,
};

obstacles.Add(squarePoints, false, 10.0f);

The last parameter of the Add method is the "maximum segment length in a edge". The smaller the value the more you are guaranteed for the obstacle to be picked up by the agents. 10.0f seems to work fine most of the time with zero hit on performance.

Alternatively if you create standalone Obstacle objects (i.e without the shorthand on ObsctacleGroup) you can call Obstacle.Subvidide(10.0f) to achieve the same functionality.

Result:

Highlighted in magenta here are the final vertices pushed to the simulation:

[sunsvip]

Thank you very much, it works perfectly!

[Nebukam]

Thank you for taking the time to report it and be willing to try things! <3