Reproduction Steps
It seems like yesterday’s fix for this constraint issue ultimately broke our rig Constraints ignore second level bones
Video:
Skinned mesh issue from 501 update
Relevant timestamps
Expected Behavior
0:28 - Correct behavior with version 500
Actual Behavior
21:30 - Incorrect behavior with version 501
Issue Area: Engine
Issue Type: Other
Impact: High
Frequency: Constantly
Date First Experienced: 2021-10-27 00:10:00 (-07:00)
Thank you! we are investigating the issue
Can you send us a repro place privately, or take another video with Constraint Details and Draw On Top enabled at runtime?
A big part of that change that went out yesterday was that Constraints can now attach to nested bones and also follow the animated positions of bones where they previously only used the reference position of the bones. This fixes a known issue with the initial release of Bones, and the new behavior is what we originally intended. It just took us a while to implement, and we know is a potentially breaking change at this point. If your rig uses Constraints attached to Bones this difference maybe be causing what you’re seeing.
I’m still worried about possibility of a rendering bug caused by our change. If for some reason the rendering of the meshes is not lining up with the actual positions of the Bones in world, we may have a rendering bug and might have to disable our change until we can fix that. Constraint Details with Drawn On Top should be enough to tell if this is happening.
https://gyazo.com/3084ec0bb2d614592107e544afe434ba
Here’s a clip with Constraint details, if this isn’t enough I can get a repo together no problem. My follow up question would be if this isn’t a rendering issue, would it be possible to get an fflag to use the old behavior? This would potentially require a substantial rewrite / redo of work. Thanks
Still a little hard for me to tell… The bones in the hand do seem to be in the correct places matching the rendering tough.
Does your rig involve any Constraint subclass instances at all? Like AlignPosition or AlignOrientation instances? If it does you may be affected. If not you should not. You should be able to replace the Bones used for those Constraints with Attachments matching the reference position of that bone on its part. If Constraints are causing the issue you’ll want to make sure none of your constraints are attached to bones that can animate.
The flag in question is FFlagSimConstraintsWorkWithBones3 if you want to try disabling it locally to compare.
Either way, if you can or can’t deduce what’s going on yourself let us know! If you can’t fix it yourself we will probably need you to send us a repro place file for us to see what’s going on.
If it turns out this change is not working as described earlier we’ll disable it.
Disabling the flag does resolve the problem, I’ll pass off my place in this discussion to my dev partner who is more knowledgeable of our system @Plutonem
The rig isn’t using any constraints at all, it is strictly working with the CFrame and Transform of the bones. It seems to happen because we set the Transform property.
The rendering of the geometry is fine according to the CFrame and Transform of the bones.
I’m not sure if this is a problem of the new math behind the Transform property or the other APIs we use to build that CFrame (TransformedWorldCFrame, WorldCFrame), or simply how the rig is set up is now incompatible.
I have a repro file available, let me know how you want me to send it to you.
Please DM the repro file to me here on the devforum!