Joint rotate error when using setHpr

When I use self.node.setHpr the joints lose normal connection (as shown in the image below).
But the documentation says that the joints only rotate, not move the position.
I would like to ask if this is a bug of the program or panda3d or fbx file?
Or how can I make his arm rotate properly?

class Env(ShowBase):
    def __init__(self):
        self.accept('escape', sys.exit)
        self.src = "../src/"

        self.pandaActor = Actor(self.src + 'human_model/human.fbx')
        self.pandaActor.setScale(0.5, 0.5, 0.5)
        self.pandaActor.setPos(0, 150, -50)

        tex = Loader.loadTexture(self, self.src + "texture/world_people_colors.png")
        self.pandaActor.setTexture(tex, 1)
        self.node = self.pandaActor.controlJoint(None, "modelRoot", "bip L UpperArm")

        self.node.setHpr(self.node, 90, 90, 90)

Hmm… I decided to try some quick tests on my own end, using the code given above (with minor modifications, primarily due to my not having the model in question).

In my case, I found that the model generally did not show the issue that you’ve been seeing.

However, I was able to get an odd-looking result–if not as extreme as yours–by using a model in which the bones of the skeleton were separate from each other. That is, not merely parented-but-disconnected, but not parented to each other at all.

And this makes some sense: without a parent, the bones can move freely, and will presumably each and all rotate around the origin of the armature, rather than around the end of their parent as per usual (as they have no parent).

So, perhaps this is the problem in your case: that your model’s skeleton has its bones separate, rather than parented to each other.

Hi, thanks for your reply and sorry for the late reply.
After many days of cross-examination, I found that other models can control each joint smoothly. And these models can also be used and manipulated smoothly in the unity engine. This strange cross-comparison result confuses me, can I upload my model for you to test?

Well, have you examined the model’s joints in your modelling program, to see whether they’re separate (i.e. not parented in a hierarchy)? That remains my best guess as to why you’re seeing this problem.

I print out the model’s joint hierarchical. I think there are parented in a hierarchy?

     bip Pelvis  hpr -89.9999 -7.94578e-05 -90
       bip Spine  hpr 10.6494 -0.000252381 -6.77647e-05 trans 3.58123 -0.296534 1.88452e-06
         bip Spine1  hpr -23.1244 -2.08459e-05 8.29348e-05 trans 16.1523 -0.0181789 0
           bip Neck  hpr 32.6511 -2.51132e-05 -8.57384e-05 trans 30.668 1.59581 3.72104e-06
             bip Head  hpr -20.0612 0.151491 0.00268375 trans 6.48566 0 0
           bip L Clavicle  hpr 179.954 -15.492 -110.141 trans 24.4231 -0.0399628 4.4588
             bip L UpperArm  hpr -16.4839 11.715 18.3537 trans 11.4898 1.90735e-06 0
               bip L Forearm  hpr -15.3854 -1.28066e-06 0 trans 23.3041 -1.90735e-06 0
                 bip L Hand  hpr 81.7244 -75.552 89.4184 trans 24.452 0 0
                   bip L Finger0  hpr -41.5423 71.2031 55.998 trans 3.57914 1.31586 -3.51341
                     bip L Finger01  hpr 1.84858 -1.70755e-06 1.70755e-06 trans 4.19407 1.90735e-06 1.52588e-05
                   bip L Finger1  hpr 7.16966 3.05608 -3.97276 trans 7.97181 -0.251648 0.415482
                     bip L Finger11  hpr 13.3974 0 0 trans 3.64034 0 3.8147e-06
           bip R Clavicle  hpr 179.954 15.4917 110.141 trans 24.4231 -0.039938 -4.4588
             bip R UpperArm  hpr -16.4839 -11.7149 -18.3536 trans 11.4898 1.90735e-06 0
               bip R Forearm  hpr -15.3854 0 0 trans 23.3041 0 1.52588e-05
                 bip R Hand  hpr 81.7244 75.552 -89.4184 trans 24.452 1.90735e-06 0
                   bip R Finger0  hpr -41.5423 -71.2031 -55.998 trans 3.57914 1.31586 3.51341
                     bip R Finger01  hpr 1.84858 0 0 trans 4.19406 -3.8147e-06 0
                   bip R Finger1  hpr 7.16966 -3.05608 3.97276 trans 7.97181 -0.251633 -0.415478
                     bip R Finger11  hpr 13.3974 0 0 trans 3.64035 -1.52588e-05 0
       bip L Thigh  hpr -2.55751 8.26551 -175.201 trans -1.52588e-05 1.78814e-05 10.0098
         bip L Calf  hpr -10.0808 1.12058e-06 0 trans 38.7999 0 0
           bip L Foot  hpr 7.87252 4.25782 -4.43891 trans 40.9685 -1.43051e-06 0
             bip L Toe0  hpr 97.3105 0 0 trans 8.56524 12.3979 -0.145709
       bip R Thigh  hpr -2.55753 -8.26566 175.201 trans 1.52588e-05 -1.00136e-05 -10.0098
         bip R Calf  hpr -10.0808 0 1.28066e-06 trans 38.7999 0 0
           bip R Foot  hpr 7.87252 -4.25782 4.43892 trans 40.9685 0 1.90735e-06
             bip R Toe0  hpr 97.3105 0 0 trans 8.56524 12.3979 0.14571

Hmm… I haven’t worked with that output, so I’m not confident in saying this, but it does look like there’s a hierarchy in place there, indeed.

I don’t know then, I’m afraid. Perhaps indeed it might be worth posting the model to see whether I or someone else manages to find a problem within it, as long as you’re comfortable with having the model be public.

(An alternative might be to try to create a simple testing-model that exhibits the same problem.)

The model cound found at here~
I choose to load fbx file, because other file types would throw out error.

Ah, I’m afraid that I don’t have a TurboSquid account. Perhaps someone else here has one!

I have account, here is the model XD

I… Don’t think that the license for the model allows one to legally just make it public like that… ^^;

But it’s for free on the website QQ

But that doesn’t mean that it’s free to give to whoever, however. It’s free to get from them, under specific conditions.

Got it…
Thanks for your reminder!
Let me figure out how to equate it to other problems.

1 Like


All right, I don’t know whether this will help, but for testing purposes I’ve constructed a simple model that–I hope!–more or less matches your joint-hierarchy. It’s by no means a particularly good model, let me say–but it’s not meant to be: it’s meant only to be a means to testing.

I would be interested to know whether you see the same problem with this model that you see with the one that you’ve been using.

You should find it at the link below. (Once you’ve downloaded it I’ll likely delete it from that location.)

Thanks for your model and helping!
After some testing, there is no problems in testChar.egg(all joint could rotate correct way~)

Hmm–that’s interesting! That suggests that either there’s a problem with the original model, or that there’s something in it that Panda is tripping over (perhaps an unsupported feature, or a problem with the joints, or something else besides)…

Wow… That’s a bad news.
So do you have any recommended way to get the human model?
I found that many human models will be judged not to be character models by panda…

1 Like

Unfortunately not, I’m afraid–I don’t generally search for third-party models, myself.

As to the models that Panda won’t load, have you looked for a format-converter that might turn them into formats that Panda will load?

And just to check–are these models also not supported by Assimp? (See this manual page, if you haven’t already.)

(In fact, if I may ask, what formats are you commonly seeing for human models that Panda won’t load?)