Physx question

Last I heard, PhysX implementation is dead.  I'm quite interested in PhysX for the sole fact that it is now graphics card accelerated…at least if you own NVidia (  Apparently, NVidia is also trying to get it on the AMD cards…but of course that is going to be an uphill battle.  Anyway, my enthusiasm for PhysX is piqued.

I'm wondering what the state of the PhysX implementation is?  I looked in the PhysX library package and I was surprised.

This weekend I spent some time with SWIG trying to get a base 'JPhysX'.  I did this since I am running Ubuntu, and it looks to me like the JPhysX in the Physics package is windows only.  My results were pretty similar to what was in the JPhysX jar already, except of course for Linux.

I'm wondering if the person that ran SWIG against the PhysX package initially can give me some advice on how they did it.  Ideally, I would like to create a JPhysX library that automatically detects your platform (Linux, Win32, XBox360, Apple, or Cell)  and loads the appropriate library.  It shouldn't be too difficult but I'm getting stuck on Ubuntu with some of the SWIG stuff.  Since someone has done it before, I'm wondering if I can get some help from them.


I did some more researching the topic (through the forum and stuff) and found a couple of threads that went into great detail about the current physx implementation.  Seems the following:

  • It is Windows/Linux only

      - The Linux implementation is different from the Windows in that it can't handle fluids (
  • The SWIG interface file was never released (even though there was talk of it)
  • The license wasn't nailed down
  • PhysX has some limitations that ODE does not and vice versa
  • The last release of JPhysX was in February

    Is there still interest in having a PhysX implementation?  Is the swig interface file going to be released still (or has it already and I am looking in the wrong spot?)

    I have a very basic swig interface file that gets fairly far within the process…but I'm still fighting through some errors…  If anyone is interested in it, I can post it, but not sure if this would be the right place.


I'm interested… please read my next post below.

(This post has been edited, because I originally wrote something that I don't agree with.  (I do that surprisingly often, unless I proofread my posts once or twice a day after I've written them.))


Perhaps it should be mentioned here too that:

The core AGEIA PhysX files (PhysXCore.dll, NxCooking.dll and the firmware binaries) are no longer intended for distribution within a game installer. Instead, a dedicated installer for developers to execute as part of the install process is provided. The installer will install the software runtime files and, if necessary, the AGEIA PhysX hardware drivers.

as originally stated here:

Baune said:

This is what they say : [...]

I no longer think that matters much though, but first I wrote that "I was (very) interested in PhysX until I read that"
but now I've edited this post so that text is... gone, or what should I say.

(The above information is included in the FAQ included in the PhysX SDK documentation, at least in PhysX_2.8.1_SDK_CoreLinux_deb.)

I guess I'm curious as to why that is bad?  They provide an installer that will automatically update the hosts core libraries…  I don't see the harm in that, if they let you call it from your own installer.  Also, if the physx library (within java) takes care of that under the covers for you…why would you care how it gets installed.

Also, it definitely isn't just for Windows (like the post you linked to states).  My guess is that they are trying to open it up to as many platforms as possible.  A quick search through the header files show that they have implementations (at least for development) for Win32, Linux, X360, apple and cell.

On another note, I have a working SWIG file that is generating all of the Java classes along with the necessary c++ class.  Wondering if anyone here is interested.  Once I get it built into a Jar, I was thinking of taking a look at the current PhysX implementation and seeing if I can:

  • Get it to run on Linux
  • See how complete it is

thorst said:

I guess I'm curious as to why that is bad?

Yes, I suppose you should be. Actually, I returned to this forum now, just to edit my above post and state that I think it's fine that it is not a completely silent PhysX installation due to the EULA agreement that the end user must check.

Sorry for my last post; I was tired and, IIRC, I read lots of posts about PhysX and licensing issues and the EULA, and then I thought PhysX was bad, but now I've slept for 8 hours, and no longer agree with what I believed yesterday night.

Anyway, I'm interested in PhysX for jME. I'm writing a physics based game where ragdolls with swords attempt to kill each other, and my intention is that physics calculations be the game's bottleneck.

Thanks, Magnus

I have it generating the necessary Java files along with the shared object file.  It'll be really easy to get it into a state to test with shortly…I just won't have time until this weekend probably.  One thing I did notice is that my version has about 80 classes less than the existing Java PhysX implementation.  The core pieces seem to be there, just not sure what could be missing. 

I'm also looking to document this fairly heavily…I don't want to have to figure out this processes ever again.  :lol:

Anyway, I'll test soon (probably this weekend) and I will find out then.  If it works my next focus will be to get it to build on Windows (linux only now).  I can't imagine that would be tough.

What's wrong with JPhysX? What about taking and improving it? Uree will probably even help you. And he never said it was abandoned. Additionally the lack of mac/cell/etc. support is just a lack of time/reason to add it, imo.

The second part that would be nice to have is a complete integration into jME Physics. I started that, but I did not continue it (for reasons I posted elsewhere). But that does not mean anything for JPhysX. Plus, anyone can add to that jME Physics PhysX binding and/or give support for it!

I think JPhysX is a great start and wouldn't mind helping out with it.  That said, I think that there are some issues that have not yet been addressed.

It was stated:

But as JPhysX is not really open source (the input files for SWIG are closed source)...

So, I was looking to make a version that had an open source input file for SWIG.  Believe me, it's not fun, and if the SWIG files get open source, I'd rather use them. 

That said, being open source isn't the big issue for me.  I would personally like the following things:

  • Versions for at least Linux/Windows (there is currently a Linux version on JPhysX, but it does not support certain things.  I acknowledge that certain things won't work on linux...but I'm not sure why the choice was made to disable them...that's another discussion)

  • Automatically link in the shared object libraries at runtime.  This one is hard to explain, but easy with code.  Basically, there is no need to specify a JAVA_LIBRARY_PATH or attaching the JNI library....if you pull some tricks.  I can give an example if someone would like, as I'm still not sure if this is 'acceptable'...but I think it works well.

  • New versions ported as soon as possible.  This may not be a priority as jME hasn't yet made extensive use of them.

  • Look into having the jar automatically install the PhysX runtime (yes, it may have to open an EULA for the user to agree to)

That's a wishlist.  If I could get my hands on an easily distributable version for Linux, I'd be most interested in seeing how it could be integrated into jME.  My development box is Ubuntu, so this seems to be an uphill battle.

Also, if JPhysX is looking for help, I'd be interested in seeing if I could offer some assistance.  As it stands, I've been playing around with SWIG (I need it for another project) and it would be cool to see how it was implemented here.


I think the JPhysX input for SWIG is closed source because it contains parts copied from the PhysX source code (headers) and thus must not be redistributed. Did you manage to write a SWIG input without copying source code (e.g. by including complete .h files)?

Writing an input file for SWIG that doesn't actually contain the header files is easy - all you have to do is reference the header files.  I've got it and it will generate the whole PhysX library.  I even built the shared objects and call into them from Java.  The input file for SWIG only contains a reference to the header file, nothing in the header file.

So, I was thinking that was pretty good.  Of course, there is always a catch.  While SWIG does a great job for the simple stuff (and most of the non-simple stuff), it gets a heck of a lot harder when you start dealing with double pointers, a pointer to an array, etc…  Basically, all the pointer hell that we don't have to deal with in Java.

Anyway, all you really asked was if I got a an input file that would generate SWIG without copying source code.  Answer, yes.  I'm just saying that right now its useless because it is not handling all situations correctly.  If anyone is a SWIG expert, then I'd really appreciate some help, but I didn't think I should post those questions here…

I think I am pretty close (maybe a week or two?) away from having a working port of the PhysX library using SWIG input files that don't copy the source of the PhysX.  I guess it is more accurate to say, I am maybe a week or two away from having something to compile and test out.  No guarantee it would actually work.  XD 

Irissor - I know that you wrote the start of an implementation and it looks like I can do an almost straight port to this new code.  I'm wondering though, are there any tests I can run to perform any sort of validation on this implementation?


thorst said:

Irissor - I know that you wrote the start of an implementation and it looks like I can do an almost straight port to this new code.  I'm wondering though, are there any tests I can run to perform any sort of validation on this implementation?

sure, the simple tests from test-interactive are working fine. Esp. turning on physics debug mode should tell you what's going on.


Quick question about jmePhysics.  Do you know if the implementation for PhysX would work generally the same in jme 2 vs. jme 1?  If I remember right (and correct me where I'm wrong), there was a separate implementation of the jmePhysics2 for jme v.1 and jme v.2.

When I started porting PhysX…I used the implementation that you had provided.  That implementation was tied to jme 1.  I thought it would be better in the long run to try to tie it to the physics engine tied to jme 2. 

I am running into a few problems (I'm thinking I can work through them fairly easily)…but was just curious if you knew this off hand.


thorst said:

Do you know if the implementation for PhysX would work generally the same in jme 2 vs. jme 1?

Yes, should be no conceptual difference (only renamed calls etc.).

:(  That's what I thought.  I can get the scene to draw fine now…it just seems that the 'simulate' step isn't actually doing any simulation.  It's almost as if the actors aren't yet added to the scene. 

I'll just have to keep poking around in here.  Thanks for the help!

And now it's done.

The tests work great.

Cool. Glad you got it working.

Hi Thorst,

I currently consider switching from ODE to PhysX.

I'd very much appreciate it if you would like to make SWIG input files and Java source code available somewhere? Perhaps email? (My email is my user name, plus AT

Regards, Magnus

Unfortunately, there are a few more issues to work through before I guess I'm comfortable releasing the tool.  It comes back to what irrisor said a bit earlier.  To get it working correctly, the input files had to be parsed from the header files.  If I were to distribute the header files, I want to make sure that there aren't any license problems.  It kind of stinks.

However, that said, I have a linux working version…but before I want to 'release' it per say, I'd like to put some more polish behind it.  I've got the boxes/spheres bouncing, some joints working, etc…  My next goal is to get the triangle meshes working.  Unfortunately, I found it somewhat difficult to merge into jME physics so the work has been directly with PhysX itself.

If you would be willing to wait a bit, I think I'll have a much more robust solution in a little while.  It would be a straight Java port without the .i files (for now at least).  However, as it stands I'm not comfortable distributing the .i files because I don't want to violate any licenses within PhysX and to be honest, I just haven't done enough research to figure out whether or not distributing the .i files would violate a license.

I also kind of want to wait until the next version of SWIG comes out so that the comments are also ported.  Right now it doesn't port the comments, but that isn't a big deal to me because I have all the header files.

Sorry if that's a long, ambiguous answer…  :frowning:

thorst said:

I want to make sure that there aren't any license problems.

Yes, okay.
(How would one do that? By emailing Nvidia perhaps?)

I would not be discouraged, however, by a pre-alpha state of the wrapper that, say, doesn't compile, or, say, crashes directly. Also, if you'd send an email, that wouldn't have to be a release? I'm more interested in learning how to use SWIG and contemplate how using PhysX would affect my current code.

But I can do some of that now anyway: learn how to use SWIG, and study the PhysX docs a bit further.
Hmm, and lots of unrelated things that will take a year or so :)  :(

Good luck anyway :)