Skinned Meshes (Mesh Deform) sometimes "Explode" their geometry

With my gun engine, I am creating a game prototype with an HD rig that I uploaded about 3 years ago. In this prototype I developed a system to have the HD rigs “ragdoll” when they die. This works by updating bone transforms to match a physics-backed assembly (The ragdoll assembly). While this issue does not happen all the time, in fact it is quite rare. When it does happen during a session, it tends to happen multiple times while playing.

I have noticed this on my mobile phone, and on my desktop. A few friends have commented the same.

I believe this is due to updating the bone CFrames because it is only when a player “dies” and their character “ragdolls” that I switch over to modifying the bone transforms. When the character is alive, the bone CFrames are not touched, and instead the ragdoll assembly is CFramed to match the bones CFrame–The problem never happens when players are alive.

Here is a video showcasing the problem:

For some additional context, we use a lot of model pooling in our game. The character models, when no longer in use, are moved to (0, 1e9, 0)

It is difficult to create a nice reproduction place. It never seems to happen in isolated tests.

A private message is associated with this bug report

2 Likes

I was able to get a reproducible example. Open the roblox project and play test. It does not happen every test, so it would seem there is some conditional deep in the engine level causing this to occur.

I took an export of our Characters folder when this issue was happening. Initially I did not think to play test. It never seems to happen while in edit mode, and 9 times out of 10 it does not happen during a play test.

ExplodedMesh.rbxl (81.3 KB)

With this finding, this is my theory (Turned out to be wrong):

It appears as though we may be in a bad state with our character model. The mesh part visuals are anchored, and are put in to the cache position (1,000,000,000 units away from origin). However the root part holding the bones are not at that cache position (close to origin). This causes the renderer to (sometimes) explode the mesh.

A potential solution on my end is to not anchor the visual mesh parts of the character model. This will force the physics system to keep the parts positioned relative to the primary part. I will do more testing and report any new findings.

[Update]
In my project I tried unanchoring the visual MeshParts of the character, except the primary part. This issue is still occuring, so I believe my theory from before is not correct. Something is still causing the mesh exploding to happen

Another odd finding. It appears this issue affects any skinned mesh in the game, so long as some skinned mesh exists in our cache position (1e9 units away from origin). I reduced the position to 1e6 units away and found that sometimes my FPV model (which is never cached) also has its mesh exploding:

I moved my cache to be at 1e4 units away, and since, the issue has never happened. This is not ideal, as now our cached models are always within render distance. If this is the case, it builds a stronger case for this feature request raised in the past (In which we were told to use cache positions far away from origin):

[Update] After days of testing, this issue is definitely improved. However it still does happen occasionally. Maybe 1 out of every 50 tests. It really does seem that the farther away from origin my skinned meshes are stored, the bigger they explode, and the more often they explode.

We are looking into this. In the mean time, would you be able to test something out? If you can add a Humanoid to your models, does the issue still happen? This would be a temporary workaround and perhaps just for testing. This could increase memory or affect performance if you apply the addition of Humanoid to all your models.

Hi orange451,

The fix for this should be enabled since release 709. Please update your Studio and check to see if this bug still happens

I haven’t recieved confirmation that this bug is still happening so I’m gonna close this out. Please open a new ticket if it happens again as it’s likely a new regression

1 Like