Crash in Chaos::Softs::FPBDBendingConstraintsBase::GetScalingFactor due to empty IsBuckled array

Development Character & Animation
, ,
1

We’ve encountered a crash that happens on chaos cloth - specifically the version that’s not using chaos cloth assets, but rather the cloth features built-in to skeletal meshes. It seems that while changing the rendered LOD of the cloth the array IsBuckled is empty when attempting to calculate the stiffness value in FPBDBendingConstraintsBase::GetScalingFactor - even though it seems to be being initialized and filled in FPBDBendingConstraintsBase::Init.

The exact line this triggers on is the following:

const FSolverReal StiffnessValue = IsBuckled[i] ? ExpBucklingValue : ExpStiffnessValue;

While looking through the source for answers i had stumbled upon a comment in ChaosClothVisualization.cpp in the method DrawBendingElementBuckleStatus, which pertains to FPBDBendingConstraints specifically, and states:

// IsBuckled is empty if the simulation is paused.

Is this a missing check in the constraint code - both cpp and ispc - or is there some other root cause for this issue? How could we get rid of this issue?

Any tips in a more consistent reproduction of the issue would be helpful as well

2

Steps to Reproduce

This issue has a very inconsistent reproduction rate. The best we’ve been able to find is disabling Ispc for Chaos Cloth with the command `p.ChaosCloth.Ispc 0`, and then forcing semi-rapid changes in displayed LOD’s of skeletal meshes with cloth actors, though please note the crash occurs regardless of the state of ispc (enabling it won’t prevent the crash - it just seems to make it less frequent)

3

We’ve temporarily worked around this issue by forcing a bending constraint init during Apply of FPBDBendingConstraints:

void FPBDBendingConstraints::Apply(SolverParticlesOrRange& Particles, const FSolverReal Dt) const { [...] if (IsBuckled.IsEmpty() && !Constraints.IsEmpty()) { FPBDBendingConstraints* This = const_cast<FPBDBendingConstraints*>(this); This->Init(Particles); }However i’d still like to know if there’s a proper fix and/or solution for this crash

4

Hi Maksymilian,

I am not familiar with this bit of the codebase, so I’ll reach out to our Dev team to find out if this is on their radar.

Out of interest, are you able to replicate this situation on a vanilla version of the engine?

Best

Geoff Stacey

EPIC Games

5

Hi Maksymilian,

We think this is something which was fixed in 5.6 already, but we can check into more next week.

All the best

Geoff

6

Hi Maksymilian,

I have a CL you can try for this if you have perforce access?

CL 39158892 sounds like it was the fix we spoke about if you’d care to try it.

All the best

Geoff

7

Apologies Maksymilian,

Glad you found the main one, let us know if this doesn’t work, but I’ll assume this fixes it unless we hear otherwise.

All the best

Geoff

8

We haven’t had the chance to replicate it on vanilla since we’ve found the workaround that prevented the crash. We don’t have any engine modifications in or around the areas of cloth and physics (other than said workaround) though, so I suspect that it would happen in vanilla as well.

9

Please do, and if you verify that this is indeed fixed - could you point me to the changes that fixed this issue, so we can cherry-pick them into our engine?

10

Thanks! That exact CL is restriced, we don’t have access to it, but we’ve figured that 39158925 has the same content - we’ve integrated the fix, seems to hold for now. We’ll see if it’s enough.