Some destructible meshes appear to be “vibrating”
It seems to be inconsistent. If I place several of the same DM. usually only half of them will behave this way.
But not always.
If I destroy the mesh… sometimes… but not always it will cause significant lag. But only once after the editor is loaded. And not always the first time a mesh is destroyed.
It happens in both PIE and packaged.
I’ll keep testing to see if I can get any more details on what might be causing it.
I’ve discovered that this stops if collision is turned off.
Hi -
There isn’t nearly enough information in this post to look into this. Can you post any comparisons you had before upgrading to 4.11 with your 4.10 version? Can you also include anything special about your DMs that you’ve setup.
From everything described this seems like normal behavior for destructible mehes. Especially the vibrating is when the chunks have no been put to sleep and typically happens more when DMs are no using Async scene rather than the default scene. The lag being the same as well. DMs are handled on the CPU and depending on your machine specs, the number of chunks in a single DM, the number of physics simulations going, and the number of DMs simulating physics in the scene that are fractured.
-Tim
Nothing changed between 4.10 and 4.11 and my DM only has 20 chunks… And my CPU is more than sufficient to handle it…
Nonetheless, After some trial and error it seems that turning off multi body overlap has solved the issue. The mesh is no longer vibrating, and there is no longer any lag on destruction. Not really sure why I had Multi Body Overlap set to true anyway.
Thanks!
I guess I spoke too soon… It seems to be doing it again after not doing it for a while.
If this helps… Here is my DXDiag
I noticed that my DM blueprints have multiple fracture effects where previously it was 0 (I dont use fracture effects.) Making a new blueprint and a new DM correctly shows 0… But does not seem to solve the problem.
Ok and one more update… I discovered the source of the lag and can reproduce it in a fresh project.
If debris is enabled, debris depth 0, with the debris timeout flag.
The first time the DM is destroyed there is lag. But after the lag happens, it won’t do it again unless you close the editor or the packaged project and restart.
Have not yet been able to reproduce the vibrating mesh issue in a fresh project.
Ok so far migrating all my content to a blank project seems to have solved the vibrating problem, as well as another reported bug about sound cues not playing in the content editor.
But the lag issue with debris timeout enabled still exists.
Debris Timeout:
I was able to see this short lag in 4.11 which didn’t happen in 4.10.4. When I tested this with our internal build of 4.12 it was working like 4.10.4 with no lag that I could see. I didn’t see a ticket where this was submitted any fix for this, so at the moment it looks like this will be an issue resolved once 4.12 comes out.
Fracture Effects:
I’ve tried to see if I could reproduce this in any way, but no luck so far. I’m assuming you’re creating your Destrucitbles in the editor and only have a single depth of destruction. There should only be two levels in that case, one for Depth 0 and one for Depth 1. This shouldn’t affect anything if you’re not assigning any particle systems to them though.
I’m getting a strange vibration as well when falling, but before it actually fractures. Using default DM settings, and a BSP turned static mesh.
I tried importing my mesh from blender, the material bugs out oddly when it fractures. DMs are a headache.
Turning off cast shadow seems to have stopped the vibrating and material buggyness.
Edit: Nevermind. It’s back.
Thought i’d drop this video here to show the material problem i’m having… I don’t know if this is the problem you were having, but it’s almost like the material is changing, or at least the reflectionj is changing drastically.
@artoculon
This is caused by your indirect lighting cache and using only static lighting in the scene. This isn’t too hard to replicate, but it’s not a bug. What you’re seeing here is the destructible meshes chunks being lit by the indirect lighting cache samples (you can visualize this for static lighting by going to Show > Visualize > Volume Lighting Samples). Destructibles are similar to skeletal meshes in that when they fracture they have a root bone and the chunks all become part of the hierarchy in the structure.
You can get around this issue by either using dynamic lighting or inside your area where it’s nice and dark that lighting was built you can place a low-intensity point light (1000-5000) so that it doesn’t let those lighting samples be completely black, and this will help offset the transition.
Here is an example with before and after:
Before:
After:
Yesss! I’ve been researching this for the better part of 8 hours hehe. Finally got to this conclusion. Added a dynamic light like you said, to ‘offset’ the transition.
However, I’ve been doing something reading about lowering the Volume Light Placement Scale in World Settings? As well as adding a LightmassCharacterIndirectDetail Volume to the troubled area? Are these recommended? Or is your solution of using an extra dynamic light like above the recommended one?
This is for a VR project, so performance is certainly a consideration. Thanks again Tim, so good to see you replicating my exact scenario 
EDIT: Also for what it’s worth, I played with the ILCQ settings in my destructible mesh. It was on ILCQ Point. Volume gave me a poorer result, and STRANGELY ILCQ Off gave me the best result (ie no transition) can you verify and explain?
@artoculon
To clarify this entire scene I had was using only static lighting and I placed a static light at the bottom of the darkened area to help provide a brighter set of light samples to keep it properly lit.
World Settings > Volume Light Samples
Using a lower value will give you a more densely packed area for sample placement where higher values will space them out more meaning fewer samples are placed.
When lighting is built there are samples placed where surfaces are for static objects. These will be placed at two heights. the first off a surface at 50 units and the other at 250 units. This essentially means that only the area about a surface is being indirectly lit for dynamic objects up to about 300cm.
You can change this in the BaseLightmass.ini file in the Engine folder by adjusting the number of samples that are placed (default is 2), and you can change the height values if you wish as well. These are not exposed to the editor because for most these settings work and should really only be adjusted if you absolutely need to for your game.
ILCQ - Indirect Lighting Cache Quality
This page here will cover some of the interpolation and general information about the ILC. Indirect Lighting Cache in Unreal Engine | Unreal Engine 5.1 Documentation
