In order to generate terrain at runtime using the recast graph without requiring read/write permissions for the mesh, I am currently using a method where I save the vertices and triangles used by the mesh in a binary file beforehand in the editor. Then, during terrain generation, I deserialize the data from this file as a workaround to bypass enabling mesh read/write permissions. I have tried it and it seems to work, but I would like to know if there are any potential issues with this approach.
If you do that, why not enable read/write permissions? I’m not sure what using a custom serialization approach would gain you over just enabling read/write permissions in unity.
To reduce memory usage, enabling read/write permissions at runtime would increase native memory. I tested my game scene and found that enabling read/write permissions adds about 13MB of memory.
Your custom representation will also use about that much memory.
If you are only scanning the graph when the game starts you could discard the mesh data once the graph has been generated using Unity - Scripting API: Mesh.UploadMeshData.
Alternatively, if your world is static you could generate a graph cache. See Saving and Loading Graphs - A* Pathfinding Project
I haven’t tested yet how much memory using a custom representation would add. I indeed need to compare which of the two solutions has a higher memory usage. Since our game requires supporting player-customizable terrain editing, caching methods would not be feasible.
You could alternatively configure the recast graph to rasterize colliders instead of meshes. Then the meshes would not need to be readable either.
However, our models are quite irregular, and box colliders can’t solve all problems. I’ve tested that once mesh colliders are used, they also require mesh read/write permissions. But, based on my testing results, the memory increase from enabling read/write permissions was much smaller than I expected.
By the way, our project hopes to run A* Pathfinding independently from Unity on a server to prevent players from cheating with position manipulation. I want to confirm its feasibility and am currently attempting it. Additionally, we may have more customized requirements or source code modifications in the future, and I’d like to inquire if there is a more efficient method of contact for quick communication with you.
It’s possible. Though there is specific netcode in this package.
If the agents are simulated on the server and then synced to the clients, it will work fine.
Other users have successfully transferred path data to clients so that the movement simulations can happen locally, but this is a bit more involved.
I prefer communicating via the forum primarily, unless it becomes a problem.