Multithreaded mesh editing?

When will we get a proper mesh for ECS? One that isn't a odd clone of the built in mesh - one we can update in jobs, which is a true component?

 

CC @Joachim_Ante - jobs have some serious use cases for procedural land/world generation, however, this is a big big holdback. To expand more, I know you can pass NativeArray<Vector3> back and forth from job -> main thread, but it's not really optimal and kinda kills ecs workflow. It would be nice to have some sort of mesh component that I can access in a simple IJobForEach<MeshComponent>.

 

While it'd definitely be nice, the performance benefits would probably not be what you expect. The big cost of manipulating meshes is pushing the cpu copy to the graphics api.

What I wish they had is Async methods for this as it locks the main thread for far too long.

Also I don't really get how this is a roadblock for you. I demonstrated procedural generation a year ago way before a lot of the modern features we have now.

 

In my experience, assigning the visual mesh does not take that long (usually 0.10-0.20 ms for a 32^3 marching cube volume). However, I have always experienced massive slowdowns for assigning mesh colliders from these marching cubes volumes. This usually takes 3-5 ms which is way too long if you target 60 fps or even higher, and there is no way around it. Although this is probably a problem of the PhysX engine rather than the mesh API.

That said, I would still love expansion of the mesh API such that it supports the Native containers and the rest of the DOTS workflow.

 

Mesh colliders updates are really slow but there isn't much you can do about it. It's why I stopped using them and wrote my own physicsless raycast system for that project (this was before Unity Physics was released).

 

@tertle the problem is the fact you cannot update a mesh inside an ecs job system - and it's really annoying for workflow when using ECS.

 

Yeah, right now you can certainly jobify + burst-compile code manipulating vertices/normals/triangles using dynamic buffers, then assemble whole mesh data on the mainthread (tertle's old demonstration). Definitely a bottleneck, but this is probably the fastest way the current API allows.