GetRefBonePose returning current animation transforms?

Hey everyone,

I need to change the skeletal mesh on an actor, and some of my skeletal meshes belong to different skeletons.

When doing so, i need the reference pose of the mesh skeleton to compute various things.

I use this code when changing the mesh (Skeletal3DMesh being the new mesh):

Skeletal3DMeshComponent->SetSkeletalMesh(Skeletal3DMesh);
const FReferenceSkeleton & ThisReferenceSkeleton = Skeletal3DMesh->RefSkeleton;
const TArray< FTransform > & ThisTransformArray = ThisReferenceSkeleton.GetRefBonePose();

When the new skeletal mesh belongs to a different skeleton, GetRefBonePose() correctly returns the transforms of the reference pose (which is a TPose here).

But when the new skeletal mesh belongs to the same skeleton, then GetRefBonePose() return the transforms of the currently playing animation (which can be anything and hence is useless as a reference).

Isn’t GetRefBonePose() supposed to return the default pose of the mesh (TPose here) all the time ?

Thanks

Cedric

Hello ,

I believe that GetRefBonePose needs to be called on the USkeleton asset itself rather than the FReferenceSkeleton asset. Could you give that a try instead and see if the same results occur?

Hey ,

The only function i could find that sounded like GetRefBonePose on a USkeleton was GetRefLocalPose, so i tried it:

//const TArray< FTransform > & ThisTransformArray = Skeletal3DMesh->RefSkeleton.GetRefBonePose();
const TArray< FTransform > & ThisTransformArray = Skeletal3DMesh->Skeleton->GetRefLocalPoses();

And i got exactly the same result: when the the new skeletal mesh belongs to a new skeleton, the transforms are ok (computed from a TPose) but when the new skeletal mesh belongs to the same skeleton, the transforms are those of the current pose.

In case it helps you see what i mean, here are two screenshots where i draw a blue debug line in the computed direction of the palm of the left hand.

On the first, i am going from the mannequin to the cop (the skeleton is different) and you can see that the line remains correctly oriented.

On the second, i go from the guy to the cop (same skeleton) and you can see that in this case, the line orientation is wrong.

In both cases the cop’s skeletal mesh is exactly the same and the code is exactly the same, so the nature of the previous mesh matters, and it shouldn’t.

Thanks

Cedric

Hello ,

I’m working on reproducing myself with not much to show in the form of results. In the meantime, I have been messing with GetRefPosePosition as well which seems to be working correctly, however since I’ve yet to repro the original issue, I haven’t been able to confirm it. Unfortunately animation in C++ isn’t my strong suit. If that function doesn’t work for you, would it be possible for you to upload a copy of a project that this happens in? If you wish for it to remain private, you can send the link to me on our forums. Here is a link to my [profile][1].

Hey ,

Perfectly understandable, as this problem is quite complicated to explain, not to mention to reproduce !

So i made you a small toy project that reproduces it on my computer, you can download it here:

http://yagame.fr/wp-content/uploads/YagCurrentVersion/ReproRefPoses.

I also made you a video to show you the problem and how to use this toy project to reproduce it:

http://yagame.fr/wp-content/uploads/YagCurrentVersion/RefPoseProblem.flv

I found two possible origins of the problem:

  • GetRefbonePose() returns the current animation transforms instead of the reference pose ones (normal or not ?)

  • When changing the skeletal mesh with the same skeleton, the animation is not reset (the current animation remains in place, again, normal or not ?)

I hope this will help you to decide wheter it is a bug or just me misusing the functions.

Please let me know if you need any further info.

Cheers

Cedric

Thank you for providing that project, being able to reproduce the issue helps a lot. As I believe this is how it should work, I’ve placed a bug report in for the issue. For your reference, the bug number is UE-20975. I’ll be sure to let you know if there are any updates on it.