Thanks a lot for this updated version. Much appreciated.
Nice to see the moveGlobal* methods supported now - I’ve been meaning to ask you about them, but those performance troubles in my application throw everything else into disarray… Also, pstats collectors are awesome! Thanks again.
Unfortunately, there is no speedup - at least in my particular case. In fact, it’s actually slightly slower than iterating over joints in Python and calling setGlobalMat() methods on corresponding PhysActor objects.
Just to see if it was going to make any difference, I’ve experimented a bit with your latest source: in particular, tried using setGlobalPose() instead of moveGlobalPose() in PhysActor::update_inverse() method. Interestingly, while the moveGlobal* methods themselves are slightly faster than setGlobal* ones, they seem to put additional computational burden on doPhysics. Which makes sense somewhat, if we take this quote from PhysX SDK documentation as a hint: “Instead, it becomes mobile when the user sets a slightly different position with the moveGlobal*() functions. NOTE: Do not use the setGlobal*() functions to make the actor mobile; it will disable many of the advantages that kinematic objects provide, such as having the appearance of infinite mass and the ability to push regular dynamic actors out of the way.”
here are pstats from my experiment, if you’re curious (all milliseconds):
| setGlobalPose | moveGlobalPose | -------------------------------------------------- PhysX (total) | 8.5 - 9.8 | 14 - 15 | doPhysics | 3.2 - 3.3 | 9.3 - 10 | updateKinematic | 5.3 - 5.4 | 4.3 - 4.6 |
Sadly, either way it’s not fast enough for the sort of frame-rate that i’m aiming for. Of course, that’s by no means the fault of PandaPhysX or PhysX or Panda3D engine. It’s the way i’m using these systems that is suspect. Perhaps, i need to re-think the whole setup of joints/actors. (Maybe there needs to be some sort of clever hierarchy to aid in collision detection optimizations, or maybe these actors shouldn’t be kinematic after all…)