When mesh is attached to skeletalmesh by socket, mesh is wrongly updated when any of physics asset bodies has simulated flag on.
Repro:
1.Attach mesh (as component or actor) to socket (eg box to head)
2. In physical asset set any body to simulated
3.Play animation on skeletal mesh
4.Attached mesh is incorrectly updated
images :
ok (no physics body is simulated ) - board is sticked to head
wrong - some physic body is simulated - board is wrongly updated
I’m sorry it’s been a few days, but we’ve been investigating the issue.
The error you are seeing has to do with how fast the animation is moving, combined with how we update the object. Basically, the socket is moved and then a frame later the attached object is updated. If the animation is moving really fast, you will sometimes see the attached object ‘wobble’ (especially looking at it frame by frame).
I’m working on a simple reproducible case that I can attach to a report. Once I do that, our developers will be investigating the issue further. I’ll update back here as soon as I have something.
I created JIRA UE-14673 in our tracking software for this issue. Our developers will be investigating it further and we will post back here with updates.
I made a skeletal rope-mesh and use the physics-asset in the environment → When I attach a mesh to a socket on the rope and add force to the rope, the sockets move slower than the mesh.
As soon as I am activating slow motion I see the rope snapping back to the socket location. So the socket locations seem to show the right locations, but the mesh is a little bit ahead of its time.
Is this the same issue? If not → is this a known problem?
We have seen this issue as well. The reason is fairly simple from my understanding. When physics is blended in, the space bases transforms are flipped later, after physics has blended in in USkeletalMeshComponent::PreClothTick(…). However, it is flipped too late. PreClothTick calls USkeletalMeshComponent::BlendInPhysics() which blends the physics and updates the children before flipping the space bases. What happens is that we update the correct space bases when blending the physics but when we update the children, we query the space bases of the previous frame before flipping the matrices when the function returns. In essence, UpdateChildTransforms() uses stale data from the previous frame.
My fix is fairly simple, I wrapped the matrix flip in PreClothTick inside an else to only perform this if we are not registered and I let BlendInPhysics perform the flipping in the 3 places where it makes sense: the top early out if there is no skeletal mesh (probably not required), when there are no bones to blend in (added an else clause) and after BlendPhysicsBones(…) but before UpdateChildTransforms().
The issue is obvious with almost any animation that moves a bone by more than a few mm/cm in a single frame where a child socket has an attachment on it. In our case, the child was a skeletal mesh component as well but the issue could very well be present as well with a static mesh attachment.
As far as I know, you cannot fix this via blueprint. Unless you are willing to do terrible things… Because the issue is stale data, you could in theory fix this by having 2 skeletons overlapped, one invisible and one visible. The invisible skeleton would have the attachment and play the same animation 1 frame ahead… Good luck!
mmmmm, that sounds bad, hahaha. But is an option I guess, lol.
Ok, maybe I will make a new topic on this? Or PM the guy i was talking to at Epic and see what he says. I wonder if this is on their radar yet?
It’s not horrible on my car now, but you can pretty clearly see the doors shifting as i drive around when physics are on. But, I do need to currently set it up so that the door closes/disables sim and not keep running like it can now. So that might hide the issue alot more.