Destructible mesh spawning in "broken" in packaged build; won't respond to damage or simulate

[SavvyIndoorsman]

Hey everybody. This is a weird one, and I had trouble picking out how to put a title on this question.

Our playful sports game uses destructible meshes for our goals — think of “breaking the backboard” and you’ll get the idea of what we’re doing when goals are scored. Over the past week, we’ve been running into this severe and strange destructible mesh bug that is ruining our goals, even though we’ve only been working on other systems during that time — that is, we haven’t touched the way the goals function since our last playtest 9 days ago, and everything was working fine then.

In short, the issue is, in packaged builds, the goal’s destructible mesh spawns in looking like it’s already shattered — or, in more technical terms, it spawns in displaying depth 1 along with depth 0. Even so, the depth 1 chunks are not simulating as they would be if the mesh were actually shattered. Rather, the chunks remain in place, just oddly occupying the same space as the depth 0 mesh (which is hard to see as a result). In this state, any attempt to apply damage to the destructible mesh and cause it to actually shatter/simulate fails silently, meaning the chunks won’t fall or respond to physics interactions — they just hang there, ugly and useless. Worse, any attempt to “reset” the destructible mesh by calling Set Destructible Mesh (which is how we’ve been resetting the goal after each score for a long time now) will, in this invalid state, crash the game.

Complicating matters, as this question’s title implies, the issue only appears in packaged builds. Play-in-Editor does not express the problem, which makes this one particularly annoying to troubleshoot. (Lots of experimental packaging.)

We had such trouble with this issue by mid-last week, that we opted to roll the project back several days just to get rid of it. The rollback solved the problem for a time, but it has since reappeared. Again, the work we’ve done over that time has not involved the goal’s destructible mesh, or even the goal BP itself — we’ve been working on art and UI assets for the most part.

I tried upgrading engine versions to the latest, 4.24.1, and that did not solve the issue.

Here’s what the issue looks like in PIE versus in the packaged-build:

(The apparent “reflection” in the second image is due to the shattered pieces using a refractive material.)

Again, prior to this past week, we had never seen this issue before. So far, I’ve tried using different destructible meshes, including re-importing and re-creating the desired DM from scratch — this did not solve the issue. I’ve searched the internet high and low for similar issues without any real luck. I’m stumped!

I suspect the issue must have something to do with our project, because migrating the busted DM to a new fresh project seems to work fine. But it also seems to be very temperamental, coming and going at different times and affecting different DMs all throughout my troubleshooting attempts last week. (Hence why we gave up and rolled back the entire project once already.)

Any suggestions for what to try next, or tips of any sort would be appreciated. We’ve got an event coming up very soon and we’d love to feel confident that everything will work as it should during the show!

Thanks for any help!

[SavvyIndoorsman]

Finally figured out what was going on. Some new ways of searching the web yielded the clues I needed.

The problem turned out to be related to this question and this question, where the original posters figured out that, in packaged builds, the Apex Destruction module is sometimes loaded after the destructible asset is loaded during engine startup. This, in a sense, causes the loaded asset to be improperly initialized, preventing it from being able to be shattered and simulate during gameplay.

One of the previous posters found a solution by modifying the engine code (rebuilding from source) to force the Apex Destruction module to load before any Apex assets are loaded during engine startup. The other poster found a workaround by eliminating all “normal” references to the troublesome destructible asset throughout the project and instead loading the asset later during runtime by feeding the engine with a string to the asset’s path.

Thankfully I found an easier way to work around the problem, by replacing all references to the destructible mesh asset in my project (there was actually only one anyway) with soft object references. This ensured that the destructible mesh asset wasn’t loaded in at the same time its “owning” asset (the goal actor, in my case) was during engine startup. This allows for the Apex Destruction module to load first while the game boots up, and the soft reference allows me to choose when the destructible mesh asset gets loaded (when it’s needed — when the goal asset runs its BeginPlay).

So to sum up: use soft object references if you’re experiencing strange issues with Apex destructibles!

[anonymous_user_9941500e1 (anonymous_user_9941500e)]

Could you please explain how have you done this? In my reference tree I have only Hard References to my DM materials.
I’ve created a BP that has Destructible and made a new variable as a soft reference to the DM, then on beginplay it loads the DM and appears, but still it has no collision or physics.
I’m developing for Oculus Quest.

[SavvyIndoorsman]

I took some screenshots of our BP setup that I hope will answer some questions.

The first and main thing to do, in our case, was to leave the Destructible Component’s Destructible Mesh asset null:

Leaving that null removes the default hard reference to the destructible mesh asset, which in our case was the reference that was being loaded prior to the Apex module being ready.

Next, we created a soft reference variable (of type ‘Destructible Mesh’), which we use to choose the destructible asset we want to load in during runtime:

We tie the soft object reference variable to the destructible component in the BP graph, loading and assigning the desired destructible mesh at runtime (at BeginPlay in our case, but you can choose to make the call to Load Asset whenever you like):

Finally, we assign the proper materials to the destructible component neatly calling a custom BP function, which looks like this:

Hope this clears some things up, but if not, let me know and I’ll try again to help!

[anonymous_user_9941500e1 (anonymous_user_9941500e)]

Thank you so much for your reply, I’ve been struggling with this for almost 1 whole week.
My BP looked a lot like yours but I set the materials in the StaticMesh that is converted to DM.
Sadly I couldn’t get it working, but I just realized that if I package it for Windows there is no problem and my cube spawns, falls and breaks as normal. I even made a fresh W10 install and still no luck.
I tried also as you mentioned, other user solution to try to load ApexD before the DM, but from 4.18 to 4.25 ApexD files have been changed and I’m lost with that much code.

My steps are: I drop a cube, convert it to SM then convert it to DM, create a BP that will contain the component Destructible and follow your steps. I drop the BP in the level (it’s “blank” beacuse it hasn’t loaded) in the editor everything goes fine (physics and collision) but when I have it in my Oculus Quest it does not work.

My only conclusion is that something is not right with my setup, I’ve seen in youtube many people showing how ApexD works on Oculus Quest with ease.
EDIT: ApexDestruction does not work on Oculus Quest I always thought it could be done, but I’ve been mistaken.
Thank you so much for your time.

[uw19]

ApexDestruction does not work on the Quest? That’s too bad. Perhaps there will be improvements here for the Quest 2. If anyone has any info, please share!

[Slamyr]

Thank you so much man this worked out perfectly ! Happy new year