it appears that UNfractured Meshes render their fractured state even if it is visualized differently by the engine.
To test this you can slice a simple Mesh one time into 100 Pices in depth 2 (actually depth doesnt matter) and one time into 1000 pieces. While both these Meshes will be exactly the same, even in wireframe mode etc. the GPU will have a much higher load for the 1000 pieces mesh as its calculating millions of vertices for the fractured state.
This is a huge Issue and there shouldn’t be any reason why it’s necessary to render all vertices in the unfractured state.
A workaround is to add the staticmesh of your Destructible mesh to the Actors Component and have the Destructible invisible by default. Then add a Event “On Hit”, disable your staticmesh and make the destructible visible before you apply Damage to it.
With Destructibles, you shouldn’t be seeing any hit when it’s not fractured, and this is what I’m seeing when I’m looking at my scene when I create several different ones (0, 25, 250, and 1000 chunks) and add them to the scene.
Everything is looking as I would expect. The biggest hit I get is when I simulate for one and have it fracture the rest that are placed because then all the chunks are there and being dynamically rendered. You have to keep in mind as well that APEX Destruction and Cloth (Nvidia tech) is all handled on the CPU and not the GPU. Most the hit likely from your GPU is coming from lighting and the draw calls from so many chunks.
If you’ve not already I would suggest starting with the documentation on GPU/CPU profiling for a more in-depth breakdown of what’s happening in your scene:
Once you have a better breakdown feel free to post back here where the hang up is happening, but with destructibles, I would expect to see what I’m seeing in my scene which is Depth 1 is low cost because it’s simple geometry (I’m using the Template_Floor.uasset btw), and when it fractures, whether the entire mesh breaks apart or not, Depth 2 replaced Depth 1 and is always rendered. Whether the mesh is broken apart full or not, these chunks are being dynamically lit and rendered as part of drawcalls for your scene. If the DM has a lot of chunks this will add up.
So at the moment, from what I have put together I’m seeing behavior I would expect.
We are talking about Unfractured simple meshes as seen at closeup wireframe view loading the gpu with 11 million vertices.! I do not expect this and if this is by design then it should be improved regardless!
Looking at your stats these are what I would expect. The Skel Verts GPU Skin is showing the number of verts for the DMs in the scene (ie. your destructible), along with your Tris.
With the Skel Mesh Draw Calls I get 2 for my single cube DM that has 100 chunks set up. One Skel Mesh Draw Calls for each Depth Layer since it’s just swapping these out when they fracture.
You can easily test this by using the Editor Cube from the Engine Content folder to create a destructible. Before adding any fractures add it to the scene and you’ll see that it’s only got one draw call for the single depth. Add the fractures and now you have two draw calls, despite what the number of fractures is set to. If something odd is happening with your specific mesh please include an FBX here that can be used for creating the destructible that reproduces the issue.
When testing something like this it would also be good to only have this be the only object in the scene instead of with other geometry/actors that can skew some numbers potentially.
You expect that the same Destructible in Depth 1 uses
1MS on the GPU with 10 slices,
but 10MS with 1000 slices?
Didn’t you say the exact opposite in your first post?
“you shouldn’t see any hit when
itsnot fractured”
“Depth 1 is low cost because it’s
simple geometry”
etc.
So my FPS drop from 87 to 49 for the exact same mesh in depth 1. That’s low cost?
I don’t care if I get 2 more drawcalls by a unfractured destructible mesh.
I care if whatever destructible mesh I create (I tested it with cubes aswell…) adds heavy load on the gpu while still unfractured in depth 1. Depth 1 should have the same (exclusive your additional drawcall) Cost for the GPU independently on the number of slices. But this is not the Case! The GPU is actually loaded all the time with weight of Depth2.
If this is really expected, then please add a feature Request, to only load depth 1 on the GPU while the mesh is completely unfractured, else Destructibles are completely unusable in bigger Worlds.
Destruction in UE4 could use some improvement and it’s on the trello board to be gotten to in the future, but it’s currently backlogged. It’s something that we want to work on at some point, it’s just not a priority at the moment.
From what I see there isn’t anything here that indicates this is a “bug” over the current way it’s implemented in the engine. Sorry it’s not the answer you’re likely looking for but the system hasn’t changed significantly in a number of releases.
Well, thank you for your time. I really would expect that it only renders Depth 1 when there’s nothing fractured and your posts looked like you are expecting the same, so I’m rather confused now but maybe I’m wrong.
I (and everybody else who want to use some more destructibles) will have to manually add a Static mesh copy to the Destructible Actors so that a 110.000 vert mesh uses just the 110k it’s visually showing to the user and not 11.000.000 for depth 2 that has no relevancy at that point at all. That solution is not that bad I suppose, I just really would expect the engine to do this by default.
I found this through google and have the same problem at the moment. With 450 basic, 8 verts DMs on screen at once, my framerate tanks down from 250 to 60 FPS. I tried reducing the fracture count from 100 to 10 but noticed absolutely no difference for the unfractured status.
At this point I suppose I’ll try OP’s workaround, although I’m not sure about the cost of having 1000s of damage events at once.
I agree that it should be in by default, unfractured meshes are extremely expensive in high volume regardless of their complexity.
I am on 4.16 and I think I am experiencing the same problem.
After I had repliaed the static mesh walls in my scene with about 50 destructible walls (3 depth levels, cutout fracturing with fracture map + voronoi on top, admittedly a bit of an overkill…) the toll on the GPU skyrocketed even BEFORE having anything fractured.
I have not seen anything on Trello regarding destructibles coming up, right? In this case, I would try the workaround too.
This essentially means that the destructible has to be replaced by a blueprint actor right? Or how else could one add logic to event “on hit”?
Yeah. Each BP had a Static Mesh listen for hit and when hit replace with the DM. I spawned 1000 instances in view and the performance was day VS night. Ideally I wouldn’t recommend having just a on hit, you may want to have a damage threshold before you replace the SM with the DM - depends on what you’re trying to make.
Then again I’m not exactly sure having 1000’s of checks every frame for the health status of each BP is a good idea but I’m no expert, I just wish this was addressed, no reason to add GPU stress on non-fractured meshes.
At this point it’s extremely unlikely, that we will see any effort on Destructibles from Epics side. If, they will introduce a completely new System, that will have it’s own flaws.
Yes, for my suggested workaround I use an Actor, if you are concerned about an actors overhead you could potentially also have the hit detection logic on your characters, or projectile and just test the hit result against your specific static mesh which you then spawn in your DM. If you want to store it’s Hitpoints, you might could do so inside the components tag, without the need for actor variables. But you would really have to test on your own if that’s better for your needs.
Thaetik, why do you have the need to check the health status every frame? It doesn’t sound like a good idea, and there’s probably a better solution.
This is an old thread but I believe it should be updated.
So I have reason to believe that this has been fixed as of 4.26. The mesh renders as static and only as destructible when fractured. Even hits that can’t break the mesh don’t trigger the destructible. So yay…?.
