Mutable destroys cloth simulation mesh on LOD2

Development Asset Creation
, ,
1

For some pieces of clothing, mutable seems to remove too much of the simulation mesh on LOD2, which completely destroy the simulation.

On the wiki, I found this quote, but I’m not quite sure what to make of it:

"Simulation mesh face removal edge cases.

As we’ve seen the removal of the simulation mesh parts is done using the association between the render mesh and the simulation mesh. If parts of the original simulation are not associated with any part of the render mesh, these will be removed even with no remove operations is performed."

https://github.com/anticto/Mutable\-Documentation/wiki/Physics\-And\-Clothing\#simulation\-mesh\-face\-removal\-edge\-cases

It only happens for some assets, not all. How can we make sure that doesn’t happen, especially on LODs which are auto generated? Is something wrong with the "association between the render mesh and the simulation mesh"?

In the pictures you can see the simulation mesh made visible both in the skeletal mesh and in mutable.

Thanks in advance,

Matthias

[Attachment Removed]

2

Apologies for the delay, we’ve just arrived back from our holiday break.

Looking at your screenshot, it looks like you have a simproxy mesh that is being reduced and that is the one that shouldn’t be. Do you have a couple screenshots of your graph?

Dustin

[Attachment Removed]

3

Unfortunately, there isn’t anything here that indicates what might be failing.

Is this the only piece of cloth that has this happen? Is there anything special happening between LOD1 and LOD2 with the mesh or proxy mesh? Does it still break if you create a simple cloth asset without the proxy?

Would you be able to share the asset with the cloth and a very simple setup that shows the issue?

Dustin

[Attachment Removed]

4

Hey there,

Thanks for the repro, just wanted to let you know that we’re still working it out on our side.

Dustin

[Attachment Removed]

5

We’re still working through this. The Mutable and Rigging team has been busy, so debugging the issue has gone slowly. Is there any changes or other approaches you’ve taken since the last update?

Dustin

[Attachment Removed]

6

Alrighty,

I’ve got some good news and some bad news. The good news! We’ve fixed the issue. The bad news is that the changes are pretty extensive and would be pretty hard to backport. If you like, I can get you some CLs that you could try, but it might be “easier” to wait till 5.8. The core of the change happened with this change https://github.com/EpicGames/UnrealEngine/commit/3d22bd6f8218d718f16147e2deff190401713085

And there are some subsequent fixes as well.

Dustin

[Attachment Removed]

7

After chatting with the dev team, we recommend waiting for 5.8 because it’s extensive. That said, the relevant CLs will be:

https://github.com/EpicGames/UnrealEngine/commit/c4eb109b379885f09b6855eb7a0e42a6c8ab9e9a

https://github.com/EpicGames/UnrealEngine/commit/382a4037d9d7dc60e752031f7f6189d94120bdda

https://github.com/EpicGames/UnrealEngine/commit/41d0136041cf1e137b21e0c2e9c16a450d97376e

https://github.com/EpicGames/UnrealEngine/commit/c9fc0aecd262f8efa2f9169dacf7c70dd9c30e29

https://github.com/EpicGames/UnrealEngine/commit/2957d5e8ef447cfe37552233aee0f53ca64f613f

Another option is to take the latest plugin from Main and try to just replace the 5.7 version. Mutable is pretty independent of the engine.

Dustin

[Attachment Removed]

8

sure thing, here are screenshots from the attached object and main object:

[Image Removed]

[Attachment Removed]

9

to answer your questions:

  • it happens on some pieces of clothing, they have been very high poly originally and were reduced (means the topology is kinda random)
  • there doesn’t seem to be anything specific happening between LOD1 and LOD2
  • it only breaks with proxy meshes, not simple cloth assets

another weird thing is that it works sometimes until you restart the editor, then it breaks again.

here is a repro: https://drive.google.com/file/d/12cfaPwPSXIgLqRsEkDkegjFbmaIrf4lq/view?usp\=sharing

[Attachment Removed]

10

Thank you!

Alrighty, I’ve found the issue, and I’ll need to verify if there is a bug with Mutable, but there is potentially some bad data present in the mesh.

There are some skinning and bone-inclusion differences: some parent bones of child bones are included in the skinning data that the cloth interacts with between LOD1 and 2. In LOD 2, there was data skinned to thigh_fwd_l, but not in LOD 1, for example. This is pretty innocuous, but once it goes through Mutable, that’s where the pieces become mangled.

To address this, I regenerated the LODs and cloth data to clean up the existing data and attached the mesh file here so you can see. The idea is that your LODs don’t contain anything the parent doesn’t. If the lower LOD has a bone influence, the parent should too. If a bone was removed in the parent LOD, the child should have that same bone removed. What is interesting is that skeletal meshes can handle that data, but once it’s processed through Mutable, that bad data can manifest into something like what you saw.

Hopefully, this helps you move forward, and thanks for raising this type of case. I’ll get it in front of the team.

Dustin

[Attachment Removed]

11

hello Dustin, thanks for looking into this!

since we’re using auto generated LODs, I’m still not sure how this even happens and how we can prevent it;

do we need to author the LODs in a DCC and reimport them as non-auto generated, or is maybe something wrong with our LOD Data Asset? how/where did you fix it?

[Attachment Removed]

12

It’s a good question, as these LODS in the example were also autogenerated in the engine. More than likely, a specific LOD was regenerated later after bone removal options were modified but it is unlikely that a generated LOD would lack weighting data on a bone, or uninclude a bone that a lower LOD has data for.

The workflow I used was to delete all LODs, regenerate them, and then reset the cloth.

Dustin

[Attachment Removed]

13

Hi Dustin, thank you again for digging into this so thoroughly, and for sharing the concrete workflow and repro asset — that was genuinely helpful on our side.

We followed your workflow (delete all LODs → regenerate → reset/redo the cloth), and it does resolve the mangling on our side.

However, there are two major issues that make this hard to use in production right now:

  1. We have to always do this workflow twice per asset asset to get a “clean” result. Doing this manually for every affected asset is a big problem for us, so it would be great if you could investigate whether this points to a bug in Mutable (or the Mutable + cloth path) that can be fixed upstream.
  2. It also seems to be necessary for mutable that the proxy mesh has a very straight, rectangular grid pattern to avoid breakage. Even with a clean grid, we still sometimes see a few isolated vertices going missing after processing (even after redoing the process), which suggests there may still be an edge case in how the data is being interpreted/rewritten.

So: your workaround works, but the need to redo it repeatedly per asset, plus the remaining occasional single-vertex loss, makes us think something is still wrong in the Mutable pipeline. If you’d like, we can provide a couple of representative assets where the first pass still fails and only the second pass “sticks,” along with the proxy mesh variants that show the grid sensitivity.

Best regards.

Matthias

[Image Removed]

[Image Removed]

[Attachment Removed]

14

Doing this manually for every affected asset is a big problem for us, so it would be great if you could investigate whether this points to a bug in Mutable (or the Mutable + cloth path) that can be fixed upstream.

This isn’t a Mutable bug, I would consider this a workflow/LOD generation issue for the moment. For some of the new objects you’ve posted here, the first time you’ve ever generated the LOD, do you see discontinuities in the skinning and bone usage? Some things to look for, in the image below I highlight a couple of examples, from top to bottom:

  1. In the red box, in LOD1 there are bones available in the skeleton, but don’t have any skinning data associated with them. In LOD2 those bones are skinned. Like I mentioned before, ideally these at least match.
  2. The green box represents what I would call a “good” thing, which is bones available in LOD1 but are not skinned, but are cut in LOD2 completely. You can see that denoted with the dot instead of the empty bone icon.
  3. The final error is an example where the bone is not skinned in LOD1 but is in in LOD2. But what matter specifically is that this is a leaf bone, and if a bone were to be added to it, then you would have a broken hierarchy of skinning an bone usage as well.

[Image Removed]A clean example would be the green box throughout the whole hierarchy.

This leads to a question that I would have. What does your LOD generation process specifically look like? Are you touching up LODS or doing wholesale generation, and then being done? When you do a generation, does it create artifacts like the above?

We have to always do this workflow twice per asset asset to get a “clean” result.

The questions I have above are meant to tackle this statement. I have a concern that we may need to be looking at our LOD generation tools.

It also seems to be necessary for mutable that the proxy mesh has a very straight, rectangular grid pattern to avoid breakage.

Generally speaking, this is a recommendation for cloth meshes, as they produce the best-looking simulation, but I want to make sure that, when breakage occurs, the above LOD generation is working properly.

Another thing to note: for the proxy mesh in the example I sent back, I did not generate lower LODs; I left that alone. I did that by disabling that mesh section during LOD generation, then reenabled it.

Dustin

[Attachment Removed]

15

Hi Dustin,

thank you for the detailed explanation. The breakdown of the bone usage and LOD consistency issues is very helpful and clarifies what you are looking for on your side.

To answer your questions, here is our current workflow in more detail, including where we suspect things may already be going wrong:

Our current workflow

1. We export the garment from Blender as a Static Mesh, with

* no vertex groups assigned

* no armature attached

2. We import the mesh into UE5 and convert it into a Skeletal Mesh using our modified Manny skeleton (MH_Skeleton).

* This skeleton was created some time ago from the original UE5 Manny and is included in the repro project.

* It is entirely possible that this skeleton already contains flaws or inconsistencies that contribute to the behavior we are seeing.

3. We transfer skin weights from a fitting skeletal mesh onto the garment.

* We have tested both transferring from another fitted SK mesh and directly from the original Manny SK, with comparable results.

4. We generate LODs with Proxy Mesh enabled, using our Data Asset–based LOD settings.

* We also tested your suggestion of disabling the proxy mesh during LOD generation and re-enabling it afterward; unfortunately, the proxy mesh still exhibited issues in those cases.

5. We then create and apply cloth simulation:

* Generate cloth data on the Proxy Mesh (for all LODs)

* Apply the cloth simulation to the simulation mesh (for all LODs)

6. We disable the Proxy Mesh on LOD0 and finalize the asset for use in Mutable.

Regarding your LOD concerns

To your question about whether we see discontinuities during LOD generation:

yes, when inspecting problematic assets, we do sometimes see the kind of inconsistencies you highlighted (bones present but unskinned in one LOD and skinned in another, or reappearing in deeper LODs). This aligns with your examples and reinforces your suspicion that something in the LOD generation step is not fully stable.

However, what still concerns us is that even when:

* all LODs are deleted,

* regenerated cleanly in one pass,

* and cloth is fully reset and rebuilt,

…the *first* pass often still produces broken cloth or isolated missing vertices, while repeating the **exact same process a second time** on the same asset “fixes” it. That repeatability is what makes this hard to attribute purely to a manual LOD authoring mistake.

Proxy mesh grid sensitivity

We understand the general recommendation for straight, rectangular grids on cloth meshes and are following that as closely as possible. Even with very clean grids, though, we still occasionally observe:

* single vertices disappearing, or

* subtle corruption that only resolves after a second rebuild.

That behavior is what led us to suspect an edge case in how data is being interpreted or rewritten somewhere along the Mutable + cloth + LOD path, even if it is ultimately triggered by LOD generation rather than Mutable itself.

If it helps, we would be very happy to:

* provide representative assets where the first rebuild fails and the second succeeds, and

* include proxy mesh variants that demonstrate the grid sensitivity.

Thanks again for digging into this!

Best regards,

Matthias

[Attachment Removed]

16

Sounds good, thanks for the details.

If it helps, we would be very happy to:

* provide representative assets where the first rebuild fails and the second succeeds, and

* include proxy mesh variants that demonstrate the grid sensitivity.

That would be good. One of each, with repro steps, would be best, thank you!

Dustin

[Attachment Removed]

17

We figured out that the problem is not reproducable in the repro project, unless you enable UseUnlimitedBoneInfluences in the project settings. However, disabling that setting (or even reverting all project settings) did not fix the problem in our project.

Anyway, the steps to reproduce our problem (broken mesh in mutable from LOD2) in the repro project are as follows:

  1. In Project Settings, enable Use Unlimited Bone Influences.
  2. Import the attached static mesh (SM_ShirtDesertVillager01_f.FBX)
  3. Create a Skeletal Mesh from this static mesh using our MH_Skeleton.
  4. Transfer weights from SK_Manny.
  5. Disable the Proxy Mesh.
  6. Generate LODs using our LODSettings (Cloth_LODSettings) with Number of LODs = 4.
  7. Re-enable the Proxy Mesh.
  8. Create and apply a Cloth Simulation from LOD0 to LOD2 (exclude LOD3).
  9. Disable the Proxy Mesh again.
  10. Set up the asset in Mutable.
  11. At this point, the cloth simulation appears correct on all LODs.
  12. Restart the engine.
  13. Recompile the asset.
  14. The mesh is now broken on LOD2.

Workaround / Fix (as recommended by you):

  1. Regenerate the LODs.
  2. Delete the existing cloth simulation.
  3. Create and apply a new cloth simulation.

After performing these steps, the cloth works correctly again, even after restarting the engine.

[Attachment Removed]

18

Hi Dustin,

thank you for the update and for investigating this issue.

We are very glad to hear that the fix is already in place for 5.8. That will be very helpful for us. Based on our current situation, we do not have an urgent need to get this working immediately in 5.7, and we will probably be moving to 5.8 when it’s released, if there aren’t too many other complications.

That said, we would still be interested in understanding what the process would look like on our end if you were to provide the relevant CLs. This would help us get a better sense of how much effort it would take to apply the changes on our side, in case that becomes relevant.

Thanks again for the clarification and for sharing the commit reference.

Best regards,

Matthias

[Attachment Removed]