[Cloth conversion] HKX loads, but doesn't get applied to the visual sim

[frigid rune]

Context:
I'm converting Dark Souls 2 map objects into Elden Ring Nightreign assets (AEG) with an automated pipeline that i'm developing (targeted at all souls games in the future). Each converted cloth asset is a geombnd containing: the FLVER, an anibnd (skeleton only), the cloth _c.hkx, and a .clm2. The cloth HKX is donor-patched from a native NR cloth asset — I keep its Havok 2018 type section and runtime graph, and swap in the DS2-derived simulation data.

The problem:
I have several converted cloth assets that are siblings from the same DS2 map (majula), built by the exact same pipeline. Some simulate near perfectly in-game. Others render fine but the cloth mesh is completely static — it shows the FLVER bind pose and never moves.

The cloth _c.hkx is loaded and executed by the engine: corrupting it crashes the game on load. But on the broken assets the simulation output never reaches the mesh.
Tested with an ablation — I forced all constraints (standard/stretch/bend/local-range) to count=0 in every asset's cloth HKX:

• Working assets: cloth visibly free-falls to infinity (gravity wins) → the sim runs and its output is applied to the mesh.
• Broken assets: no movement at all → the sim output is not applied to the mesh.

My main question:
For NR/ER object cloth — what does the engine actually use to bind a cloth simulation's output buffer to a rendered FLVER mesh? Is there a registration step, naming convention, flag, or asset-config (in the geombnd, FLVER, MSB AssetPart, or elsewhere) that decides whether an asset's cloth output gets applied to its mesh? Anything that explains the engine running the sim but not feeding it to the mesh would be a huge help. Happy to share files.

What I've ruled out (already tested):

• Cloth HKX graph: tested both a full bone-cloth graph (Skin + MoveParticles + Simulate + Gather + Update + Convert, with a transform set) and a stripped simple-cloth graph (Simulate + Gather + Convert, no transform set, no Skin). Broken either way.
• skeleton.hkx: byte-identical between a working and a broken asset except for asset-number digits.
• anibnd: identical structure across all assets.
• FLVER: the cloth mesh's bone weighting, dynamic flag, default bone, vertex layout, and bone names are identical between working and broken assets.
• Matbin: swapping a broken asset's cloth matbin for a working one's changed the texture but not the static behavior; renaming the FLVER cloth material had no effect.
• Naming: the cloth display buffer, FLVER cloth bone, and skeleton bone are all consistently named <AssetName>_cloth on every asset.
• Removing the skeleton makes all assets static (including working ones) — even when using a simple cloth runtime graph, which in theory shouldn't need a skeleton as far as i'm aware.

[wary mirage]

there are general 3 possible causes for normals issue:
fixed particles - yes it effects how shadows applied,
deformation type - ds2 mostly using simple cloth simulation yes, but better solution would be separating display and simulated part as simulated part will be having simulation based on normals such as normal distance on distance constraints,
mesh reimport - it is known that mesh exporters are not perfect so mesh gets effected and its even more visible with physics applied

other issue is fromsoftware put total mass on cloth at exactly 1 while nr/er using much higher and veried values like 10-30

there rly many possible causes for different issues so ig if you will have problems after my exams are over prob ping me again(little less than a month later)

.clm2 is sorta memory bounds from what i remember, 12thAvenger had more idea but nobody cared to figure it out properly

hkx is basically physics data

and usually mesh has some sort of flag or naming convention but mostly those are not effect anything

also since you convert it from 2014/2012, havok had some changes between versions and havok has to upgrade it regardless if its good idea or not

skeleton tho, it is used for mesh position so 12thAvenger fbx importer adds em for each mesh you add

there is chance for it to work without but very unlikely

[frigid rune]

Hey, thank you for answering the post!

I was able to solve it, and each thing was a different issue indeed

For the static assets the problem was about params in the end, trying to look into the cloth data was a wild goose chase at the end

And for the shadows, just like you said, it was totally fixed particles related

Currently all cloth assets are properly working : D

I had some problems later regarding multi-mesh cloth assets, but that was solved when i tried to replicate the DS2-style simple cloth object with one island for each mesh (none of them sharing operators)

[wary mirage]

Happy to hear that dude, you might as well check total mass gravity and damping per second data in those as ds2 def had most changes in havok world from what ik(unless you managed to put location data on it perfectly)

Afaik ds2 tend to put lower damping which has quicker responde but not as smooth as fromsoftware do in newer titles, total mass is def lower in ds2 so you def noticed how your movement or wind makes it go banana

And gravity since it might need to either be rather stuck or move more freely like

[frigid rune]

Yeah you're 100% on-spot here, i basically inverted the damping because DS2 really sets it very very low indeed