RVONavmesh / RVOGridGraph crashes

Ahoy there,

I’m having some issues with the Pro version of A*, I purchased it for use of the RVO functions however i cant get it to work.

AFAIK everything is set up as required, however if i scan the navmesh on awake while RVONavmesh is active the editor just hangs. ( Well actually I left it running and went out several hours later it did eventually work but that’s no good for me)

If i cache the navmesh it doesn’t build graph obstacles.

i have tried a Gridgraph and RVOGridGraph from the forums and the same thing happens.

The only way i have actually managed to get some kind of result is to disable “scan on awake”, pause the scene, hit scan.
This is the only way i have managed to get RVONavmesh (or RVOGridGraph) to actually build the obstacles.

i am also get this error which may relate to this.

Caught exception while deserializing data.
Ionic.Zip.BadReadException: bad read of entry graph0_conns.binary from compressed archive.
at Ionic.Zip.ZipEntry._CheckRead (Int32 nbytes) [0x00000] in :0
at Ionic.Zip.ZipEntry.ExtractOne (System.IO.Stream output) [0x00000] in :0
at Ionic.Zip.ZipEntry.InternalExtract (System.String baseDir, System.IO.Stream outstream, System.String password) [0x00000] in :0
UnityEngine.Debug:LogWarning(Object)
Pathfinding.AstarData:DeserializeGraphs(Byte[]) (at Assets/AstarPathfindingProject/Core/AstarData.cs:316)
Pathfinding.AstarData:LoadFromCache() (at Assets/AstarPathfindingProject/Core/AstarData.cs:232)
Pathfinding.AstarData:Awake() (at Assets/AstarPathfindingProject/Core/AstarData.cs:131)
AstarPath:Initialize() (at Assets/AstarPathfindingProject/Core/AstarPath.cs:1213)
AstarPath:Awake() (at Assets/AstarPathfindingProject/Core/AstarPath.cs:1075)

If anyone can shed some light on this i would be most grateful.

I’m pulling my hair out over this over the last few days as I had this working a few months ago, albeit on a smaller scale but I assumed it would still work. If it is the case that the level is just too big (doubtful) is there any way to cache the RVO obstacles rather than generate them every time?

Thanks

Craig

Also,

I get this while the scene is playing:

every time.

First off~ Im not sure why you been both a RVONavmesh and a Normal Navmesh… Seems kinda overkill…

I best bet is a threading problem, try setting A* to first scan the Normal Navmesh then the RVONavmesh~ Or cash the navmesh before you start the scene

Am i right in thinking that RVONavmesh uses the Navmesh defined in the AStar Path editor.

so yeah i do need the navmesh for the RVONavmesh.

Caching the Navmesh doesn’t work. it tells me 0 obstacles built.

any other sugggestions?

After reading over the errors again~ This looks like a problem for Aaron…

Still, it would be nice if you could not have 2 navmesh’s taking up ram and runtime. So could you tell me more on what your trying to do? Maybe we can come up with a better way!!

Yes, the RVONavmesh uses the navmesh specified in the recast/navmesh graph.

It’s weird, because RVONavmesh has absolutely nothing to do with serialization. I don’t even think anything uses it when not playing.

graph0_conns
Hm… so that stores all connections for the first graph… Just thinking out loud here, but it might be that if no connections were deserialized, then the RVONavmesh will try to put obstacle walls everywhere and therefore take a really long time… though hours is very long…

Are you using the navmesh graph or the recast graph?
Also, try to place debug statements at the start and end of the RVONavmesh’s calculation method, just to make sure that it is actually freezing there.

Due to frustration and boredom i did actually sit and wait for the obstacles to generate in all it actually took around 25mins using 40% of my CPU (i5).

I used my own navmesh but i have tried with both recast and gridgraph.
the same issue.

It seems the issue is that the graph doesn’t scan (or load from cache) if the RVONavmesh script is enabled. However pausing the scene and scanning in editor works no problem.

Maybe it gets stuck in a loop or something.
I have tried setting the RVONavmesh to execute after AStarPath but to no avail. I assume because RVONavmesh doesnt fire off until scan is complete.

I have also tried running AstarPath.active.Scan () on level load and after a 5s delay.

and of course i have tried with a clean project with just the asset store version of A*.

Thanks for your time

Craig

I have also tried running AstarPath.active.Scan () on level load and after a 5s delay.

So this is probably because when opening the A* Inspector, it will deserialize settings, possibly those will be loaded correctly, while the ones loaded at start were corrupt.

So are you using loading from cache?

PS: Have tried, but I still cannot replicate it. And I still cannot see any reason RVONavmesh would affect serialization.

Would it be possible for you to send me an example project showing the bug?

Here you go,

https://docs.google.com/file/d/0B__mqE-6tbElV1lnMjNzeUZ4dFk/edit?usp=sharing

knock yourself out

Hi CraigO,

I’m the developer of RVOGridGraph from the forums. I’ve requested an access to your example through Google Drive. I won’t promise, but I can try and take a look at this issue too.

What version of A* Pro are you using ?

PS: don’t worry to give me access to the A* Pro included in your project, I’m already a A*Pro owner.

Ok Pat,
I’ve given you access.
If you can help me at all i would be most grateful.
The version in using is the latest asset store version. 3.5.1 i think. Sorry i am actually away from keyboard right now so i can’t check.

The navmesh i am using in the project may be a little large and complex but i think that something else is causing this issue. As using a recast or grid graph causes the same issue.

Thanks in advance.

Craig

I’ve looked at your files (Main.unity scene), and computing the RVONavmesh take big time for me too (I don’t know how, I’ve closed Unity before the end).

I’m not familiar with navmesh using external mesh and I don’t know if “19659 verts, 18840 tris, 2 submeshes uv” is considered a too big mesh for navigation. Your navmesh is a maze of roads, I’m not sure, but I think a recast mesh could probably generate a heavily simplified navigation mesh

Your scene has no camera and no RVO agents, but it’s probably only for the example, I mean it is supposed to start and generate the RVONavmesh.

I don’t understand what are these blue lines, they are visible when I select the AStar Path object in the scene, custom links ?

I’ve loaded your mesh into Blender 3D and saved only a little piece for a test. It take the same long time, and the blue lines where always here. Then I’ve deleted the AStar Path object and recreated it, now no more blue lines, and it works, even with RVONavmesh (I’ve added my own OnDrawGizmos available on the forum for better see).

But I’m surprised by the result, what do you really want to do with pathfinding and RVO on this navmesh, why each single roads are separated in multiples subways ?

Finally, deleting the AStar Path object and recreating it to remove the blue lines was the trick, now it works, even with your entire road mesh.

But it take a long time to compute the RVONavmesh, I’m not sure, but more than a minute on my Core i7.

You may also take a look at the messages at the bottom of the screen :

One or more triangles are identical to other triangles, this is not a good thing to have in a navmesh Increasing the scale of the mesh might help Number of triangles with error: 2

6 small areas were detected (fewer than 10 nodes),these might have the same IDs as other areas, but it shouldn’t affect pathfinding in any significant way (you might get All Nodes Searched as a reason for path failure).
Which areas are defined as ‘small’ is controlled by the ‘Min Area Size’ variable, it can be changed in the A* inspector–>Settings–>Min Area Size
The small areas will use the area id 254

Scanning - Process took 13379 ms to complete
UnityEngine.Debug:Log(Object)

I did figure using the road mesh as a navmesh wouldn’t work too well however, i get the same issue when using a gridgraph or recast mesh. Is it just too big?

The main problem of your scene is related to the custom links (blue lines). They seem to highly increase the computation time of RVONavmesh (there is also a bunch of them).

I’m not very familiar with custom links, and I think it is actually difficult to edit them (this could be improved in the future, I’ve read Aron talk about that). Are these links really needed for your project or are they here because you have not removed them?

Even after removing the custom links, RVONavmesh is very long to compute on your scene, but take a comparison, the Example11_RVO scene by Aron has a graph with 302 nodes, yours is 18840 !!!

And if I remember well, the RVOObstacle are allocated and stored in a way that take an exponential time according to the number of obstacles.

So you are stuck, you need another approach for your project. You should probably only use pathfinding to choose the better road and another method to place your agents on the road (walking left, right, in the middle of the road …).

For me, your path mesh graph should looks like the image below.

You only need to have smaller faces if there are obstacles on the road.

OK,

I’m looking at it now.

I’ve Exported a recast of the road mesh as an OBJ and then set that to be a navmesh in the A* editor. No links.

2031 nodes (much less than 18k).

Now the RVONavmesh script isnt generating obstacles at all. Infact it isnt even telling me that it ran in the console.

Next option.

Grid Graph.

Generate a grid graph from the road mesh with a collider.

512*512 with each node having a size of 3

works ok… Generated in a reasonable time.

Edges are outside of the road by a decent amount.

so not so good.

1024*1024 size 1.5

still takes WAAAAAAAY to long.

Obviously too big still.

Right now i’m not worried about the links i assume i can add hugging the left hand side of the road to the AI behavior.

But what is my best option here?.. obviously disregarding links and the insane laned road mesh.

Would simplifying the roadmesh not get me the same result at using the recasted mesh?

Anyway thanks for your time. You have been most helpful thus far.

Craig

Here is what I’ve obtained after a few tweaks with a recast graph:

You can see the graph parameters to the right (1072 nodes)

The RVONavmesh seems OK to me:

Anyway thanks for your time. You have been most helpful thus far.
No problem, helping others is a good way to learn :wink:

CU

Pat

Ooh i didnt realise that you could use RVONavmesh with recast.

Hmm it still doesn’t seem to generate obstacles…

am i doing something wrong here?

Also I cant find your script that put arrows on edges anymore could you also possibly link that for me?

I cant find your script that put arrows on edges anymore

Add this code in the RVONavmesh class:
` /** Draws Gizmos */
public void OnDrawGizmosSelected() {
OnDrawGizmosExtended(true);
}

public void OnDrawGizmos()
{
    OnDrawGizmosExtended(false);
}


/** Draws Gizmos */
public void OnDrawGizmosExtended(bool selected) {
    Gizmos.color = new Color(0.615f, 1, 0.06f, selected ? 1.0f : 0.7f);

    foreach (ObstacleVertex ov in obstacles) {
        ObstacleVertex start = ov;
        ObstacleVertex c = start;
        do {
            if (c.next == null)
                throw new System.InvalidOperationException("obstacles[...].next == null");

            Gizmos.DrawLine(c.position, c.next.position);

            if (selected) {
                // Draw the little arrow to show the direction of the obstacle
                Vector3 a = c.position;
                Vector3 b = c.next.position;

                Vector3 avg = (a + b) * 0.5f;
                Vector3 tang = (b - a).normalized;
                if (tang != Vector3.zero) {
                    Vector3 normal = Vector3.Cross(Vector3.up, tang);

                    Gizmos.DrawLine(avg, avg + normal);
                    Gizmos.DrawLine(avg + normal, avg + normal * 0.5f + tang * 0.5f);
                    Gizmos.DrawLine(avg + normal, avg + normal * 0.5f - tang * 0.5f);
                }
            }
            c = c.next;
        }
        while (c != start);
    }
}

`