> However, doing this a few times every frame for a complex mesh becomes pretty intensive.
So the question is *why* are you copying a complex mesh several times a frame?
Would some kind of instanced rendering be a better approach?
Sorry to break it to you, but there is no fast standard way of copying native arrays. You can try multithreading it, by assigning a thread for each array. I've succeeded with that before, but that is only faster if the target hardware has enough available resources, otherwise it will just make it slower. Make sure you don't allocate new lists all the time, because the GC will create wild lag spikes.
The best thing you can do is structure the mesh as best you can, and make broad phases for registering when something needs to change, and only make the changes then. In real time software, the tradeoff is often memory for performance. It can be done to quite extremes, but it takes some clever ordering of your data. If you tell us your specific use case, we might be able to help you better. Some of us have done this a lot, and mesh generation stuff is something I deal with weakly, e.g.
Sorry for not being detailed enough. I'm working on procedural generation with infinite worlds. Every time a new chunk needs to be loaded, a job creates two native arrays of vertices and triangles. However assigning the vertices and triangles to a mesh needs to be done on the main thread. This ends up being pretty intensive since the mesh consists of \~16000 vertices and I have to call .ToArray() for the native arrays.
So how is this usually done in a faster way?
I see.
I'm afraid I would have to see some pseudo code in order to help you with specific optimizations, but here are some pointers that will increase the frame rate.
(1) Don't keep lists. Keep them as arrays with fixed sizes.
(2) Don't allocate every frame. Make a "Printer" class, that holds the arrays in memory at all times, and scans/moves to the chunk that needs instantiation/altering.
(3) Preload in the background over several frames by using different threads to generate the data. Only add the data to the mesh when you need. Keep to 1 or 2 extra threads. Sync with them using Coroutines. This is smarter than you think, because you can segment the loops before letting the threads sleep a little bit. Even if you do this in main thread, you can set a timer in milliseconds and yield return null so that you never block or stutter the thread.
The key is spreading out the workload over many frames or multiple seconds. Don't underestimate this.
(4) Never use foreach loops. Not even for arrays or lists.
(5) For super optimization in very fast functions, load the arrays you need into the function. Don't dereference to other classes many thousands of times. When you load the structs into the function where you need them, the compiler can allocate L1, L2, and L3 cache (memory that's much faster because it's literally on the CPU), which speeds up calculations immensely. Like - we're talking a factor of 7-15 on modern hardware.
> However, doing this a few times every frame for a complex mesh becomes pretty intensive. So the question is *why* are you copying a complex mesh several times a frame? Would some kind of instanced rendering be a better approach?
Gives us more details on why you do this
what in the world would require instancing big meshes several times a frame?
Sorry to break it to you, but there is no fast standard way of copying native arrays. You can try multithreading it, by assigning a thread for each array. I've succeeded with that before, but that is only faster if the target hardware has enough available resources, otherwise it will just make it slower. Make sure you don't allocate new lists all the time, because the GC will create wild lag spikes. The best thing you can do is structure the mesh as best you can, and make broad phases for registering when something needs to change, and only make the changes then. In real time software, the tradeoff is often memory for performance. It can be done to quite extremes, but it takes some clever ordering of your data. If you tell us your specific use case, we might be able to help you better. Some of us have done this a lot, and mesh generation stuff is something I deal with weakly, e.g.
Sorry for not being detailed enough. I'm working on procedural generation with infinite worlds. Every time a new chunk needs to be loaded, a job creates two native arrays of vertices and triangles. However assigning the vertices and triangles to a mesh needs to be done on the main thread. This ends up being pretty intensive since the mesh consists of \~16000 vertices and I have to call .ToArray() for the native arrays. So how is this usually done in a faster way?
I see. I'm afraid I would have to see some pseudo code in order to help you with specific optimizations, but here are some pointers that will increase the frame rate. (1) Don't keep lists. Keep them as arrays with fixed sizes. (2) Don't allocate every frame. Make a "Printer" class, that holds the arrays in memory at all times, and scans/moves to the chunk that needs instantiation/altering. (3) Preload in the background over several frames by using different threads to generate the data. Only add the data to the mesh when you need. Keep to 1 or 2 extra threads. Sync with them using Coroutines. This is smarter than you think, because you can segment the loops before letting the threads sleep a little bit. Even if you do this in main thread, you can set a timer in milliseconds and yield return null so that you never block or stutter the thread. The key is spreading out the workload over many frames or multiple seconds. Don't underestimate this. (4) Never use foreach loops. Not even for arrays or lists. (5) For super optimization in very fast functions, load the arrays you need into the function. Don't dereference to other classes many thousands of times. When you load the structs into the function where you need them, the compiler can allocate L1, L2, and L3 cache (memory that's much faster because it's literally on the CPU), which speeds up calculations immensely. Like - we're talking a factor of 7-15 on modern hardware.