I am meeting some resistance with the idea of storing the source mesh in resources. We use asset bundling to bundle all of our levels and the desire is to keep everything related to a bundle inside the bundle. If I move a mesh into resources temporarily to edit the Graph Cache and then move it out again will I break features like NavMesh cutting at run time? I want to know if this could be an acceptable workflow.
I understand that. It’s not the optimal workflow. The only reason it has to be in the Resources folder is because that’s the only location that my scripts can reliably find a mesh in both in the editor and in a standalone game. I cannot use Unity serialization since graphs may be saved to files and loaded during runtime.
However if you use the graph cache, everything that is needed at runtime is already stored, so I think it should be safe to ignore that warning when you create the cache (you don’t even need to move it temporarily to that folder), the source mesh field will obviously not be deserialized correctly and it might log a warning about that, but I think all the pathfinding related things should work just fine.
Navmesh cutting for navmesh (not recast) graphs is only available in the beta version (I think it is available there anyway… it can be done in my dev version, but I cannot remember if those changes are in the beta as well), but using navmesh cutting after it has been loaded from a file should be no problem.
We are currently running 3.8.1 on Unity 4.7. I really like being able to take a recast graph to Blender and tailor it a bit more. Can I only bring the modified mesh back in again using NavMeshGraph? Can you recommend an alternative workflow that allows both the automation of the recast + the flexibility of editing specific areas? Are there any backwards compatibility issues in your mind regarding upgrading our current project to your latest beta?
In the current version you can only bring the mesh back, no navmesh cutting.
Even in the beta you can only bring the mesh back (but with navmesh cutting) if you do not use tiles (well, you can use tiles in the recast graph I guess, but you won’t get any of the nice benefits such as navmesh cutting only being done per tile and thus improving performance).
There are some compatibility issues with regards to the RVO system, otherwise it should be pretty straight forward. Some things have been moved to the Pathfinding namespace which may require some minor changes to your code. You can see the list of upgrade notes here: http://arongranberg.com/astar/docs_rvo_fix/changelog.php
Oh. And the beta is not compatible with Unity 4.7. It is only compatible with Unity 5.2 and up.
Just want to add that it is a great product. Thanks.