Really appreciate the detailed responses!
I've read that a lot of work was put into jobs/burst to allow for the most out of parallelization compared to native C# threading.
On top of this, there is also an API to generate meshes in parallel.
My idea is to batch all meshes into a IJobParallel and modify and build out the vertices using that above (or similar) method.
The current largest bottle neck is me calling DistanceToTF(), InterpolateAndGetTangentFast(), along with a few others below.
![[Image: Ntfm440.png]](https://i.imgur.com/Ntfm440.png)
I've already noted that it'd prob be a good idea to pre-sort / cache information regarding the sourceMesh vertices to deform faster.
Instead of calculating the GetVertexZDistance for every vertex, I pre-cache all possible unique Z values based on the vertex, and or sort the vertices similar to you by z. Whichever ends up running faster when parallelized.
I've read the code for DeformMesh and noticed you had ways to use versions of the API that were thread safe and thus could be ran in parallel.
If I could understand how you did this and what I could possibly do for my own implementation that'd be great.
Getting the DistanceToTF and Interpolate working for jobs is a different matter I still need to work out.
I'll start by testing deforming meshes with jobs, and then deforming them with Mesh.ApplyAndDisposeWritableMeshData to see how good the benefits are. If I can get that working its just a matter of making those functions above to work with it.
As a quick follow up, if in the end caching specific rotations is the best option, how can I go about limiting the angles the spline can create? I noticed it in the curvy generator but haven't yet figured out where it does this.
A) Would you suggest pre-caching all possible rotations offline and storing them as assets?
B) Pre-caching them at game start
C) Caching when generated on use using a mix of parallization + caching
The walls also need to support destruction which I've yet to figure out what method Ill use. They'll likely have pre-cached destruction data needed to deform as well.
The plan is to have 3 different wall types, but to allow upgrading them which can change the visuals. They also need to support adding multiple sub meshes for other upgrades to the walls.
I've read that a lot of work was put into jobs/burst to allow for the most out of parallelization compared to native C# threading.
On top of this, there is also an API to generate meshes in parallel.
Code:
Mesh.ApplyAndDisposeWritableMeshData(meshDataArray, mesh);My idea is to batch all meshes into a IJobParallel and modify and build out the vertices using that above (or similar) method.
The current largest bottle neck is me calling DistanceToTF(), InterpolateAndGetTangentFast(), along with a few others below.
I've already noted that it'd prob be a good idea to pre-sort / cache information regarding the sourceMesh vertices to deform faster.
Instead of calculating the GetVertexZDistance for every vertex, I pre-cache all possible unique Z values based on the vertex, and or sort the vertices similar to you by z. Whichever ends up running faster when parallelized.
I've read the code for DeformMesh and noticed you had ways to use versions of the API that were thread safe and thus could be ran in parallel.
If I could understand how you did this and what I could possibly do for my own implementation that'd be great.
Getting the DistanceToTF and Interpolate working for jobs is a different matter I still need to work out.
I'll start by testing deforming meshes with jobs, and then deforming them with Mesh.ApplyAndDisposeWritableMeshData to see how good the benefits are. If I can get that working its just a matter of making those functions above to work with it.
As a quick follow up, if in the end caching specific rotations is the best option, how can I go about limiting the angles the spline can create? I noticed it in the curvy generator but haven't yet figured out where it does this.
A) Would you suggest pre-caching all possible rotations offline and storing them as assets?
B) Pre-caching them at game start
C) Caching when generated on use using a mix of parallization + caching
The walls also need to support destruction which I've yet to figure out what method Ill use. They'll likely have pre-cached destruction data needed to deform as well.
The plan is to have 3 different wall types, but to allow upgrading them which can change the visuals. They also need to support adding multiple sub meshes for other upgrades to the walls.
