Panda PhysX

[rdb]

How about if we included this awesome library into the Panda3D source code?

[enn0x]

Thank you, but here are a few concerns:

(1) The PhysX integration is not as stable as it should be for adding it. For example it doesn't work with 1.6.0 I reckon it has to do with multithreading support, but I don't know yet.

(2) Panda is an open source engine, and to my perception movement has been towards a pure open source engine, e.g. replacing closed source audio third party modules with open source audio modules. Having a pure open source "core" Panda3D is a good thing. If someone wants to use closed source third party modules then he/she still has the possibility by using "add on" modules (like PandaPhysX).

When I started working with PhysX it has been the only royalty-free library which offered features like stable out-of-the-box character controllers, cloth, soft-body, hardware acceleration and so on. But now the Bullet library has been catching up - they have a a character controller now, they can do soft-bodies, they have started to use CUDA, and Bullet is open source. The only disadvantage: Bullet API is a patchwork. Anyway, it seems like a serious alternative by now.

enn0x

[rdb]

(1) 1.6.0 is not multithreaded (by accident).
(2) Well, we have FMOD and Miles too Anyways, that's also why we have a "contrib" tree in the panda source now.

I've just been looking at the physx code and it looks like you've did an awesome job. It even follows Panda's coding conventions. Integrating it would be as easy as copying.

[Executor]

Hi enn0x,
Is there some way to control the PhysController's jump abilities, except for just saying how fast? For instance the jump's height.

Also, there seems to be something wrong with the controller's collision while jumping. When jumping into something it falls straight to the floor.

Maybe I'm overlooking a setting?

[enn0x]

@pro-rsoft

Ok, no objections from my side. Downside: at least on windows PandaPhysX seems to be broken for some reason, and I don't have time right now to investigate deeper. But I will make a note and come back to you once I have more time again. I have seen the mindstormss has published a script for compiling single modules, which looks interesting as replacement for PandaPhysX build system.

@Executor

When jumping into something it falls straight to the floor.

What I wanted to implement is that if the controller bumpy into something on it's bottom side then the jump should be stopped, if it bumps into something on the side or top the jump is not stopped. This is from the source code:

Code: Select all

  ptr()->move( d, mask, _minDist, collision_flags, _sharpness );
  if ( collision_flags && NXCC_COLLISION_DOWN ) stop_jump();


The two other flags, NXCC_COLLISION_SIDES and NXCC_COLLISION_UP won't stop the jump. At least in theory. Never tested this.

For instance the jump's height

The jump height is related to the initial upwards speed, like in real life. Right now I don't have a way to customize the jump formulas, but you could have a look at the source code and tell me how you would like it to be.

enn0x

[BMCha]

Would it be possible for you to add a z parameter to a physController's setGlobalSpeed/setLocalSpeed. Or possibly make duplicate functions that include a z parameter. I just looked at the code, and this modification seems to be easy, as the update function of a controller has a 0.00f as the third parameter in the speed line.

[enn0x]

This should be easy. I have put it on my todo list, but please bear with me - I first have to get it going with 1.6.0 again.

enn0x

[coppertop]

First of all - hi everyone, since this is my first post here .

Now to the point, I just wanted to inform, that PandaPhysX works fine here (I've run all the samples with no problems at all) with Panda 1.6.0 under Ubuntu 8.04 x86.

[enn0x]

Right, Linux seems to work normal on my box too (also Ubuntu 8.04LTS). I guess I am simply too stupid to compile on Windows. I also get lots of warnings when compiling Panda3D itself, about problems with the vector templates. Well, I will dig into it (and probably ask for help soon :-)

enn0x

[enn0x]

http://enn0x.p3dp.com/libpandaphysx_0.4.5.zip

After almost giving up I finally managed to compile against Panda3D 1.6.1. A few changes to the interrogate and compiler calls had to be done. The reason why I had this problem is that I am using my own build system, and I didn't notice Panda3D has made changes to compiler and interrogate flags with 1.6.1. Mindstormss's makelib would be a much smarter way of building. I will dig into it.

So here is another maintenance release. No great new features, just a few minor enhancements.

* Modified scons-scripts for Panda3D 1.6.x releases
* PhysController.setGlobal/LocalSpeed now supports setting z-speed
* Adds MAKE_SEQ support wherever possible, e.g. PhysScene.getActors()

(see included file doc/RELEASE-NOTES.txt)

The included binaries are built for Panda3D-1.6.1.

ennox

[jwatte]

Another option is to just wrap PhysX using SWIG, and poke at it using regular Python wrapper classes. I did this a year or so ago, and it still works (I just re-opened it to add C# support in addition to Python). The nice part about this is that it's trivially simple to update to new versions, it requires no changes to the (copyrighted) NVIDIA headers, and it exposes pretty much the entire C++ API.

You can try the library I built a while back at http://www.enchantedage.com/python-physx

[rdb]

But then he would need to re-code the actual PhysX<>Panda integration in Python.

[jwatte]

Why? What's wrong with just using the wrapped objects?

Maybe I just have a different approach to design. I don't think there needs to be a PhysX <-> Panda integration. I write an application that uses PhysX for simulation, and Panda for rendering. The "integrating layer" is my application entity component model. Entities may get physics services from PhysX, and may get rendering services from Panda, but Panda doesn't know about PhysX, or vice versa.

[rdb]

It's not as easy as that. Anyone can make python wrappers for a library. Pandaphysx is not just a wrapper around the library, it provides integration with the engine, meaning that it provides a way to join panda and physx.
Have you seen the pandaphysx source code? The integration of panda<>physicsengine is a whole different layer - and it's not just converting physx vectors to panda vectors, but it actually hooks into Panda3D's structures. For example, the casual user doesn't want to write his own code to convert a Panda geom into PhysX collision geometry. It's much easier for someone to tell the layer to take a panda model and make a physics object out of it than to let the user update positions every frame, convert all the geometry, and whatnot.

[enn0x]

I have done so before, too, for example Newton physics engine and JSBSim flight engine. I'm good at writing native Python wrapper for C/C++ libraries, and I know how to use wrapper generators like SWIG or Py++ (based on boost, used for python-ogre, and in my opinion way better than SWIG).

You points are right, using automated wrappers is much less work than writing wrapper by hand. But there are limitations of automated wrappers too. It's difficult to combine two C/C++ libraries this way. You alway have to go C(lib 1) -> Python -> C(lib 2), which is not very fast. One solution would be to write code on the C layer that "combines" both libraries on C, and automatically wrap the "combination layer" for Python. This is exactly what I do. I write pure C++ code which interfaces between Panda3D and PhysX, and then automatically create wrappers for Python.

Have a look at this: the physics engine computes a new pos and rotation for a simulated object, in C++, and every frame. Now you get every frame each of the 16 matrix elements, which is 16 times C --> Python (even if it is just one call, internally you have to create PyObjects for each matrix element!). In Python you re-transform the matrix so that is matches Panda3D's matrix layout. and finally you set the NodePath transform from Python --> C (16 times parsing a PyObject argument in C). Now you have update the position/orientation of one(!) object. This might be good for a dozen objects, but what about 200 boxes? What I do is: every frame I collect the physics engine result in C++, and set directly in C++ the Panda3D NodePath transform.

Now let's make it a bit more complex: you want to simulate cloth with PhysX. That's up to several hundred vertex positions (each 3 components). Each frame you have to read all the vertices from C++ to Python, and set it from Python to the Panda3D mesh geom.

Still, your arguments are right. Any hand-written code needs to be maintained, which is a lot of work. I don't know how long I can do this, and I can't promise that I will be able to upgrade to every new Panda3D version or PhysX version within reasonable time.

By the way: looking at Ogre they do the same as I do. python-ogre doesn't offer Python wrapper for PhysX, but they offer Python wrapper for NxOgre (by betajaen) which is an integration layer between PhysX and Ogre.

enn0x

[jwatte]

As I said, I think we have different approaches to software integration. I totally see what value the hand-written integration gives a user who wants to use an "integrated" Panda-like approach to adding a physics component. Don't let me stop you or discourage you at all -- all I'm doing is providing an alternative, should you (or someone else reading the thread) wish for one.

The main contribution of my wrapper is the approach of creating a few big meta-headers to get SWIG to magically export pretty much all of the libraries, which I feel is terser and simpler than many other parser/wrapper/SWIG-based approaches. YMMV, of course.

[enn0x]

http://enn0x.p3dp.com/libpandaphysx_0.4.6.zip

This release fixes a serious bug reported by Executor some time ago (controller did fall to the ground whenever it hit something on the side or top). I'm sorry, but I forgot about this bug for quite some time.

The main new faeture is basic support for soft body objects. Sadly this features is, like cloth, still not available on Linux. NVIDIA anounced to fix this almost a year ago.

* Fixed a bug in controller stop-jump determination
* Adds simulation of soft bodies
* Adds better detection of user errors
* Adds methods to set 128-bit collision masks on cloth and soft body.

Built for Panda3D-1.6.2

ennox

[Executor]

Only notice this now, thanks enn0x.

[paulv2k4]

Any chance of supplying a character ragdoll sample in the next version?

This stuff is very good.

[Executor]

I was planning on addaing some ragdolls to my game. Unless enn0x already has a sample lying around, I'll look into creating one over the weekend.

[enn0x]

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

[paulv2k4]

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.

http://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.

[Executor]

Basic Ragdoll Sample

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.

[enn0x]

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:

Code: Select all

   ...
   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

[paulv2k4]

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?

[enn0x]

Thanks Executor this is very helpful, although this only makes them dead correct? We can not apply animations to this?

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).

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.

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

[ZeroByte]

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.

[paulv2k4]

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.

Are you using fixed or variable timestep? What values for maxTimestep/maxIter do you use?

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.

[enn0x]

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.

Ah! I have not set these within my code yet, can you give me an example of how these can be adjusted?

Have a look at sample 13 (controller), around line 171.

or a sample of what would be a more suitable solution for a faster paced movement simulation.

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

[paulv2k4]

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)

http://www.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.