In my last forum question （ UE5: How to spawn Dynamic Mesh Component Actor Dynamically?） ,
I solved the spawning issue with the DynamicMeshActor.
And I’ve implemented the ability to “dig a hole” to BP_DiggableItem with Boolean subtraction operations on dynamic meshes, and the problem is when the number of holes is getting bigger (or duing to the dynamic meshes are more complexly modified?) the program runs more laggy.
I want to know how to optimize performance for dynamic mesh modifications？
The function I want to do can refer to the Steam game DiggingAHole
I made a “Sway” feature for the weapon to make the weapon have a swing effect when rotating the field of view. It can also be seen that the weapon has a noticeable laggy in the back of the video
You should check whether the problem is in the complexity of the final mesh, or in the cost of adding a new cutout if there are many of them (for example, ISM/HISM has a similar “problem”).
If the first, then most likely you will have to combine a large cluster of small cutouts into one large one (and figure out how to do this unnoticeably for the player)
If the second, then the model itself should initially consist of smaller parts, so that it is impossible to create too many cutouts in one part.
One idea I have is that whenever a BP_DiggableItem is subtracted 100 times (for example), I convert the dynamic mesh to a Static Mesh with the same Mesh, and then convert it to a dynamic mesh again, which is equivalent to resetting the mesh’s modify history. I don’t know if that’s reasonable
Will the cutouts of the Dynamic Mesh be automatically removed after they are completely subtracted? Or that I need to do extra logic to determine if it’s completely subtracted – > and then, I need to manually destory them
The problem with the boolean operation is that it is applied to a mesh with a large vertex count, which eventually leads to the lag you were seeing at the end. The basic way to fix this, as suggested here, is to make the boolean only apply to small parts of the “Diggable” object, potentially splitting it into smaller parts (chunks). But I think doing this yourself is a lot of work. This task itself could be a small project.
The developers of the Steam game you mentioned most likely used the idea of Voxel. I haven’t used it myself, but I believe it was designed for this kind of thing. It allows you to automatically create chunks, so it will do what I mentioned to you. Then it should work as you wanted, eliminating the lags that were appearing later, so I highly recommend doing some research in this area, maybe try using Voxel Plugin and see if that works for you. I think it’s free, but I’m not sure.
The chunks way is too hard for me to know how to do it.
However, I think it is important to identify the “hole faces” created by Boolean subtraction, and optimize the vertices for those faces (to use any of the nodes provided by the official) without changing the rest of the DiggableItem.
An acceptable indication is that these “hole faces” are simplified and changed shape due to performance-optimized operation
Here are some nodes I’m testing to get those “hole faces” ……
I mean, you can convert these structures to arrays, you can just drag a pin from “structure” and type “convert” and use the function that pops up.
But again, no matter how you optimize the algorithm, you’re still generally going to be creating at least a few new vertices every time you apply the boolean. If you have a game like you showed, with a fairly large “Diggable” object, you’ll eventually reach a point where the most optimized object still has too many vertices for the boolean to work fast enough, causing significant lag. This is a limitation of the boolean algorithm, it wasn’t designed to work at runtime on objects with many vertices. I don’t think there’s much you can do for a single object to ensure that there are no lags in the long run.
Voxel splitting is the only good option designed to solve these kinds of problems. It’s a complex topic, but it’s the only good solution I can suggest here.
