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
Hi Dreedoo,
I just attempted to reproduce this in 4.7.6 but I couldn’t get your results.
Which version are you using?
Also, how exactly are you attaching the actor/component to the socket? Here is what I am doing:
I use 4.7.5
I can repro this eg with Trooper from MatineeFightScene.
I have attached mesh (emissive SM_Hallway_Pipe_Small_90) to head bone of Trooper SkeletalMeshActor placed in scene.
Attachment was done by actor context menu - so it is component attachment.
Then I have set single hand_r physic body to simulated
Than using animtoplay I have set Troop_1 animation.
Then playing in pie I see that cylinder is swimming inside head.
Easy to see when paused and frame skipping
It is more bold when animation is faster or head is swinging to sides.
It seems like half frame update delay or sth.
Hope it helps
Cheers
…and it happens with or without setting All bodies Below Simulate Physics!
…start.jpg shows how attachment looks in editor and “start wrong 2.jpg” how it looks after few secs of animation. Pie was paused to grab screenshot.
Hi Dreedoo,
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.
Hi
It is quite noticeable when one have helmet or mask attached to head or gun attached to hand.
I hope you will find solution soon.
Thanks a lot
I’m really looking forward to your fix.
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.
Cheers,
TJ
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?
Hi dj_joey,
I believe so. It does sound like you are experiencing the exact same issue. I updated the JIRA to reflect that you also reported this error.
Awesome. Thanks for answering. I guess this could take a while to be fixed. Is there a way for us to see the status of certain tickets?
Not yet. This is something that we are hoping to implement at some point in the furture.
As for the status, the JIRA is listed quite high in priority. Just keep in mind that crash bugs and showstoppers always come first.
Ok cool. Looking forward to that.
Thanks for telling. And I will keep that in mind 
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.
seems to be working… thanx
Can this be done via the blueprint or only c++?
I am seeing a delay in a socket position when driving my vehicle.
It slowly drifts from its default position, but only when simulating physics.
I really want to be able to simulate on parts and keep them locked down. Like a car door swinging freely open, ect.
Any info would be great! I’m on the latest version now. Not 4.10 preview though. 4.9
Thank you!
Bump. Anyone else having this issue/ got a workaround with blue prints? Or does it have to be done in c++? Thanks!
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.
