Sorry, I don’t have a ragdoll example at hand. As far as I know there is not much support from PhysX considering ragdolls, and you have to assemble the ragdoll from collision shapes and joints yourself.
Please let me know if you have any success, or if you need further methods/attributes with joints.
enn0x
If you look at the PhysX training videos for Unreal3, I assume we can reproduce the same affects in Panda.
Im not much of a C++ coder (Im an artist), otherwise I would try and help.
developer.nvidia.com/object/ue3_physx.html is the training video website for reference.
In an ideal world I would like a boned character to have collision boxes around his limbs so that I can perfectly detect each collision upon him. The ragdoll in my game would be a better solution to simulate tackles and falling to the ground.
Ok, I got something basic to work. I had trouble with using an Actor’s controlJoint(), realized that just reparenting the controlJoint’s nodepath to a PhysActor’s nodepath does not work, so I had to add some lines to the update task.
Please give some comments and suggestions. Can anyone think of a better way of doing it?
I have an idea of how to make the whole ragdoll creation process automatic, the creation of joints, and their positions, and loading of nxb’s for collision, after loading the ragdoll Actor.
Very Impressive 
You can eliminate self.rightboxNP and self.leftboxNP, by setting the NodePaths self.rightctrl and self.leftctrl as NodePath to update by the actors. Then you have no additional lines in the updateWorld method:
...
def updateWorld( self, task ):
dt = globalClock.getDt( )
self.scene.doPhysics( dt )
return task.cont
...
def setup( self ):
...
# Right
#
self.rightctrl = self.boxdoll.controlJoint(None,'modelRoot','Bone01')
shapeDesc = PhysBoxShapeDesc( )
shapeDesc.setDimensions( Vec3( 0.5, 1, 1 ) )
shapeDesc.setMaterial( m1 )
bodyDesc = PhysBodyDesc( )
bodyDesc.setMass( 10.0 )
actorDesc = PhysActorDesc( )
actorDesc.setBody( bodyDesc )
actorDesc.setName( 'Right' )
actorDesc.addShape( shapeDesc )
actorDesc.setGlobalMat( self.rightctrl.getMat( render ) )
self.rightboxActor = self.scene.createActor( actorDesc )
self.rightboxActor.attachNodePath( self.rightctrl )
...I think it could be possible to extract the bones from a Panda3D Actor and setup the PhysActors and PhysJoints in a generic way. Hmm… one problem would be to compute how “thick” the PhysActor for a specific bone should be (the length could be computed I guess).
For the joints it might be good to set limits for how far they can rotate. I have to check if such methods are already wrapped by PandaPhysX.
enn0x
Thanks Executor this is very helpful, although this only makes them dead correct? We can not apply animations to this?
A slightly differing topic, in my football/soccer game, I made a ball of which is sphereShape object (not using proper names here, you know what i am talking about). When the ball moves at a fast pace it seems to stutter and cause a blur effect (double vision effect), but the framerate is not suffering and my characters move smoothly.
I have tried increasing the refresh rate of the scene, but to no avail.
Any ideas?
I’m not an expert on ragdolls, but in my understanding you can either control a player|monster|whatever by a animation, or you by physics. It is not possible to have both control the bones at the same time.
but you can chane between both modes. So for example while the character is alive he is controlled by animations, and when he ‘dies’ control is given to physics (aka ragdoll).
Sounds strange. At first I was afraid that it is time to implement CCD, but this seems not to be the cause. Your ball would pass right through obstacles.
Are you using fixed or variable timestep? What values for maxTimestep/maxIter do you use?
enn0x
Combined ragdoll/animation control has been done before, although I’m not sure if there are papers describing how it happens. I think the easiest one you can see for yourself is Blurst’s Minotaur Chinashop. It combines ragdoll and animations to allow the player to interact with the other physics objects while retaining somewhat full control over the character.
Thanks Zerobyte for the confirmation of what I was trying to explain. I was asking if this PhysX Panda integration can achieve the same results.
Ah! I have not set these within my code yet, can you give me an example of how these can be adjusted? or a sample of what would be a more suitable solution for a faster paced movement simulation.
Ill keep digging until you reply with your great wisdom.
I think we have been talking about different things. I try to explain in my words: what I see is a character controlled purely by animation. But it is not a simple collision shape link in the samples. Each ‘bone’ has assigned a separate solid collision shape.
Basically it should be possible to do this with every physics engine. Each frame read the animation state (aka joint/bone transforms), and set them to the collision objects. In PhysX you should create a KINEMATIC actor for each bone, and link them with joints. The KINEMATIC is important to tell PhysX that it is you who controls the actors transform, and not PhysX.
For one or two characters it should be fast enough to do it in Python.
Have a look at sample 13 (controller), around line 171.
No clue here. I don’t know if timesteps is your problem - the description is too vague. Just play around with the values and see if things get better.
enn0x
After messing with Timesteps from I understand they just adjust the pace of the simulation, for example I increased scene.useFixedTimesteps to( 1.0/24000.0, 8 ) and all that did is make it slow right down, so I increased the force being applied to the ball and then the double-vision jittering effect came back.
Heres a video of what I am experiencing, maybe that will help (please ignore the FPS thats Fraps Video Capturing causing it, trust me when I say it runs at 60 FPS normally)
youtube.com/watch?v=A281FmSsBxw
See that double vision effect? especially toward the end of the video, theres the issue. I am not sure why the ball is going through the floor, I must have commented something out by accident.
With fixed timestep maxIter is the maximum number of simulation sub-steps PhysX will per call of doPhysics, and maxTimestep is the maximum timestep per sub-step. So using 1/24000 and 8 makes 0.000333 seconds that get simulated per frame. You would need to have a framerate of 3000! Resonable values would be around 1/60 for maxTimestep and 8 for maxIter. Sometimes it is better to use variable timesteps, with a maximium of 1/20 or 1/10 or 1/20.
Sorry, but the video doesn’t help much especially since it runs at a different framerate that the game. All of your scene seems to jitter, so maybe it is a camera problem.
enn0x
I just said to you the scene jumps because the Video Capture slows the entire program down, it does this in all my games.
You dont see that “double vision” of the ball after it has reappeared at the end of the video, where it is jumping back and forth?!
The camera follows BallNP which is attached the physX code so if the ball jitters, so does the camera! The camera code worked perfectly fine when using ODE, but i wanted to implement PhysX as its much more powerful.
Thanks for the information on TimeSteps, I will get back to you on progress.
paulv2k4,
this could be due to the order of tasks in your program. If your camera following the ball is a separate task from the one the does the doPhysics() call, then try combining them into the same task, and make sure physics is done first:
def updateWorld(self, task):
dt = globalClock.getDt()
# ... do whatever you need here: process input, etc.
self.scene.doPhysics(dt)
self.moveCamera()
return task.contenn0x,
have a question for you regarding torque.
For some reason, i cannot get an object to spin really fast. For example, taking a sphere object and adding a certain amount of torque to it makes it spin, however at some point it doesn’t matter how big of a torque you add - the object rotation speed does not increase.
I tried modifying your 03_Forces.py sample to add bigger torque, and also tried a setAngularVelocity() method, but neither was able to increase the speed of rotation after at reached a certain level. Is there some sort of internal cap…? Or am i not doing this right?
Thanks!
found it: PhysActor.setMaxAngularVelocity method regulates that.
I should’ve studied the documentation a little bit better
btw, Panda PhysX really rocks! This is seriously cool stuff and an awesome addition to Panda3D.
About issues with hardware acceleraton:
i believe i’ve ran into the same problem as BMCha described earlier in this thread. If i had “PhysX GPU acceleration” enabled in my NVidia control panel, then my application wouldn’t start. It would open the main window, but then nothing happened, so i had to kill the task. If i disabled hardware acceleration, then all worked nicely.
After some digging, turns out it’s the NxCreatePhysicsSDK() call inside PhysEngine::initialize() method that hangs, never returning. This appears to be a timing issue: it seems to happen because the call is made during loading of the libpandaphysx dynamic library. To verify, i created a pair of a simple EXE client and a DLL that the client links to, and the DLL has a call to NxCreatePhysicsSDK() in its DllMain function. And sure enough, it hangs the same way. So good news: it’s a bug not in PandaPhysx itself, but in the PhysX system software or the SDK maybe.
As an experiment, i moved the PhysEngine::initialize() call out of the init_libphysx function and into the PhysSceneDesc constructor. Since you probably almost always need a PhysSceneDesc object at the very beginning, i thought it’d be a reasonable place for the call. Rebuilt Panda Physx, and now hardware acceleration works for me! Of course, this is somewhat of a hack, and maybe there are other hidden problems that i’m not aware of, but it appears to do the job.
In case this thing is videocard/system-specific, here’s my info:
XPS M1530 with Windows Vista 32-bit SP1
GeForce 8600M GT 256MB
Hello juce, and thank you for the perfect analysis. You are right, in some cases the DLL initialization causes PhysX setup to hang. So moving the initialization code out of the module init is the right solution.
I placed the SDK creation in the module’s init code because I wanted to make using PandaPhysX as easy as possible: the use should not worry about setting up the engine.
Problem: There are many places throughout the PandaPhysX library where I need a pointer to the NxPhysicsSDK. Usually I get this pointer by calling NxGetPhysicsSDK and assuming it has been created before. This is fine if I create it in the modules init code.
Solution: Now I replaced all calls the NxGetPhysicsSDK with a module-level funtion “get_sdk()” which uses PhysEngine::initialize if the sdk has not yet been created, otherwise just returns it. So here is a new release:
http://enn0x.p3dp.com/libpandaphysx_0.4.7.zip
Maintenance release:
Built for Panda3D-1.6.2
enn0x
enn0x,
thanks a lot man! the latest version works very well for me.
(Ironically, on my machine, a hardware accelerated cloth is about 2 times slower than the software cloth but this could be due to several factors, including the fact that my application is at the very early stages of developement, and right now the scene graph isn’t really optimized, so i think my GPU’s already pretty busy just rendering it, and the extra task of calculating physics is not what it needs at the moment. My GPU is also fairly average, so that also contributes to its not-so-awesome performance)
Glad it works now. I had this problem myself, on my Desktop where I have an old Ageia PhysX card installed together with the graphics card. It has been about time to solve this problem.
About the performance: You graphics card with 256M is the minimum required for hardware acceleration, while the CPU is pretty strong. On my laptop (XPS 1330 with 8400M/128M) I can’t use hardware acceleration at all. Also, my cloth wrappers are far from being optimized. I hope to get better with time.
enn0x
Definitely looking forward to any performance improvements for cloth!
that would be fantastic if you are able to do it…
I’m using PandaPhysX for my toy-project soccer game. The nets and corner flags are made using cloth meshes. Flags have a small number of vertices each, so they are not a problem, even 4 of them. But the nets have many more (each one has 1146 vertices - as returned by getNumParticles). I’m using triggers to change sleep velocity for the nets, as the ball moves closer or away from them, so that kinda works ok - i’m able to get a decent frame rate. But i’m a bit worried of not having much time per frame to add things like more players, AI logic, and so for.
Here are some screenshots if anyone’s curious…
