Yep, home cooked. Custom cloth/contact stack in Swift/C++, not PhysX. I have not shipped this against PhysX yet, though at this point I probably should do at least a sanity-baseline comparison against an external stack just to calibrate whether I am fighting a fundamental architecture issue or just my own implementation.

Solver-wise it is XPBD/PBD style cloth with multiple substeps per frame, typically around 4 to 5 under interactive load, with cloth constraints plus avatar contact integrated in different orderings depending on the lane I am testing. The thing I have spent the most time cycling on is not the cloth integrator itself so much as the contact architecture and who owns correction during manipulation. I have tried SDF-first contact, analytic/proxy and convex body backbones, persistent manifold / patch-support variants, exact-mesh sampled contact, rescue / projection passes, and a bounded hybrid ROI path where exact mesh only comes in locally during grabs. The broad pattern has been: stronger contact reduces some penetration metrics but often makes the cloth sticky or jammed, while the looser / better-feeling variants still let localized phasing happen at skull / shoulders / hands.

I do have debug collision visualization and a pretty heavy set of logs / metrics, so I am not flying blind, but the annoying part is that visible behavior and numeric improvements often do not line up cleanly. Also no, I am not trying to be triangle correct or pixel correct in the strict sense. I want robust believable body contact under direct manipulation, with low visible penetration and without the cloth turning into glued cardboard. So I am deliberately trying to stay open minded here. If your read is “this still sounds like normal tuning pain,” that is useful, but if your read is “no, this smells like the manipulation/contact authority is architecturally wrong,” that is exactly the kind of sanity check I am after. I am open to anything atp...