Right. New NVIDIA graphics drivers come with PhysX bundled.
What rbd doesn’t know is that PandaPhysX 0.4.8 is linked statistically against NxCharacter.lib, so NxCharacter.dll ist NOT required.
The problem is that Panda3D .dlls are missing. 0.4.8 is linked against Panda3D 1.6.2, and won’t work with 1.7.0. The only way to make it work with 1.7.0 is to compile it and link it against Panda3D 1.7.0.
For Panda3D 1.7.0 rdb asked me to integrate PandaPhysX. This is not 100 percent done, but all the basic features are already available in Panda3D, without need for downloads from this thread. What is missing is cloth/softbody/vehicle. So if you don’t need these experimental features you are probably better off using the PhysX support that comes with Panda3D 1.7.0 SDK.
The Panda3D 1.7.0 SDK is linked dynamically against NxCharacter.dll, so you need to have a copy of this file, like rdb explained. We have discussed this topic (include NxCharacter.dll, links statically, …) for a long time, but finally decided not to link dynamically.
This means you are supposed to download your own copy of the PhysX SDK from the NVIDIA website, and copy NxCharacter.dll from there to either Panda3D-1.7.0/bin or your project directory (main.py). But extracting it from the Panda3D runtime works too
This also has the benefit that you get the full PhysX documentation, which is very very helpful. With just a few samples at hand you are not able to use PhysX efficiently.
I didn’t provide a new download of the code from this thread so far, since I want users to switch to the Panda3D SDK, but I can compile and provide downloads too (within a few days…)
Ah, thanks for explaining the situation. But I think you didn’t notice my update to that post, I’ll quote myself:
So I did get nxcharacter.dll from there as you said but I get the same error.
Also, faced with the inability to run the physx samples I kinda moved on to bullet in this time, I got it to work fine with my app, so I’ve partially lost interest in physx (sorry, after you took the time to address my issue). Btw, my main requirement is determinism, which do you think is better in this regard, ode, bullet or physx?
And you said some time ago that you were working on bullet integration, what’s the status on that? It’s not essential for me since I use c++ so I can use bullet directly, but it would be nice to have it integrated (just curious.)
Won’t help. It’s not NxCharacter.dll, as I explained. You won’t get these samples running without recompiling. Or using OTHER samples for the Panda3D 1.7.0 SDK. The API changed quite a bit.
About bullet: I’m have rigid body, several collision shapes, and the character controller working, but in an experimental way. Still doing experiments. Don’t expect a release for at least two month. But if you are using Bullet from C++ then you don’t have any need for a Python Bullet module.
I installed the 1.7 SDK and the newest PhysX SDK and I’ve managed to get PhysX working but I can’t seem to figure out PhysX in Panda.
I dropped NxCharacter.dll from the SDK in Panda3D-1.7.0/bin. I tried running the old samples from the last version (which I didn’t think would work because you said they were linked against an older version of the SDK or something) and they gave me the DLL load error.
I think tried snooping around in 1.7 (with the idea that things had been remapped for PandaPhysx’s now built-in status) and I found panda3d.physx, but trying to import it gives me the same DLL load error. Is there some documentation somewhere on how to get the old examples working in 1.7? This is frustrating!
I am aware that a chapter in Panda3D’s manual concerning how to use PhysX with Panda3D is still missing. Sorry. It will be added soon (don’t want to give a date though).
Interest for PhysX has been fading lately, for three reasons:
NDIVIA no longer provides a PhysX SDK for linux
NVIDIA has removed the public downloads and moved them to a section where only registered developers have access.
NVIDIA’s PhysX license is too ambiguous.
Anyway, here is the short version, since this has come up a few times now:
3.) Download and unzip the Panda3D PhysX samples from http://enn0x.p3dp.com/samples.zip. The samples from any previous release won’t work!!!
4a.) Copy NxCharacter.dll from your PhysX SDK to the directory where you unzipped the samples.
4b.) If you are an experienced Windows user you can also copy NxCharacter.dll to the “bin” directory of your Panda3D SDK. Just “dropping” it there - like you described - most likely didn’t work if you are on Vista!!! You may see it, but it’s not there.
5.) Try running the samples (“ppython 01_basics.py” etc.)[/b]
Interesting comparison, indeed. I didn’t get the expression that the guy is all for PhysX. HAVOK seems to be stronger on consoles.
No question HAVOK and PhysX are the two big players in AAA titles. After all up until a few years ago game developers have been paying 50000 dollars for a license (per title!). However, both engine come with proprietary licenses, and I didn’t hear any rumors that this will change soon. Even worse, PhysX dropped their Linux support silently.
This forum is dominated by what this article calls “indie game developers”, which have most benefit from open-source engines. I think this article missed Bullet, which has been growing constantly during the last few years. My guess is that in a few years there will be three “big players”: HAVOK, PhysX, and Bullet.
Well it’s not really a surprise that a physx fan (first link) sees that one as the better engine, and then a bullet fan (second link, from enn0x) sees bullet as one of the best new contenders.
Nonetheless, this discussion is interesting and I’ll now go read both articles
Thanks for you help before, enn0x! I got it working and in a few days built a force directed graph layout tool using Panda/PhysX. I then used it for a Wikirace style game where you’re flying around the wikipedia web graph trying to connect two random nodes. Here’s an early screenshot:
I want to try and scale this up (it works great at 30-60 fps for graphs of up to a couple hundred nodes), but I noticed that I’m probably CPU limited on the PhysX workload. I’m using exclusively rigid body constructs (force fields and springs) and I know those are done on the CPU in PhysX < 3.0 (whenever that comes out), but I thought PhysX is supposed to support multiple cores. Am I getting stuck under the GIL or something by the Python bindings? Only 1 cpu is being used, which is a sucky bottleneck. If so, would this be alleviated if I worked in C++ Panda and #include’d the PhysX lib directly?
Secondly, I had a hard time with mouse picking. I initially tried to use the built-in ODE stuff from the manual, but there must have been a broken callback or something because it had no idea of the movement of the PhysX actors in space. It would only let me pick my nodes initial starting positions. I tried a hybrid approach using the mouse ray generation stuff from the tutorial (because it has to be camera aware) and the raycasting from your demo, but there was some sort of disconnect between the APIs (I was getting a really wrong vector) and I couldn’t get it to work. Do you have a mouse picking demo using PhysX that you could share?
Lastly, and this is more of a Panda question, but I’ve been using the Rope class for edges to visually join together two nodes as they move through space, but it’s really flaky (sometimes they disappear) and a lot of the cosmetic stuff in the API is broken (like thickness, color, etc). Is there an easy way to draw real polygons as edges that’ll anchor to nodes (over the top of the physx spring actors) without having to use additional PhysX primitives? I’m trying to save all of the available PhysX bandwidth for the forcefields and springs doing the layout.
If you’ve got any additional wisdom about a better way to do things than I’m doing right now I’d definitely appreciate it. It’d be really neat to be able to distribute this via the web runtime, but it seems like that’s impossible with the PhysX DLL requirement. Is the only way to achieve that kind of portability to use the vanilla engine with ODE? If so, can you think of a similar feature/primitive in ODE for point to point repulsion that performs similarly to PhysX forcefields?
Well, in theory Panda3D/PhysX applications can be distributed as .p3d file and thus be played within a browser, since the Panda3D runtime contains a PhysX module which comes with all the libraries needed, even NxCharacter.dll.
We had working samples at the time of the Panda3D 1.7.0 release. Unfortunately this doesn’t work anymore with the newest PhysX runtimes. I will talk with rdb about this. I’m afraid the only solution would be to open the Panda3D runtime and let it access libraries outside it’s sandbox, which is a possible security risk and rdb won’t like it.
Mixing different physics engines (Panda built-in, ODE, PhysX, Bullet) is never a good idea. First you have to get the ‘ray’ from your mouse, in ‘world’ coordinates. This is pure Panda3D code and independent on any physics engine. Second, you have to do the raycasting. How to do this depends on the physics engine. Here is a quick and dirty sample code:
#Part one: coordinates
pMouse = base.mouseWatcherNode.getMouse()
pFrom = Point3()
pTo = Point3()
base.camLens.extrude(pMouse, pFrom, pTo)
pFrom = render.getRelativePoint(base.cam, pFrom)
pTo = render.getRelativePoint(base.cam, pTo)
direction = pTo - pFrom
# Part two: raycasting
ray = PhysxRay()
ray.setOrigin(pFrom)
ray.setDirection(direction)
ray.setLength(direction.length())
hit = self.scene.raycastClosestShape(ray, PhysxEnums.STDynamic)
if not hit.isEmpty():
print hit.getShape().getActor()
print hit.getImpactPos()
Current implementation is that PhysX simulation happens in a separate thread (NX_SF_SIMULATE_SEPARATE_THREAD). This thread can be moved to a different core by the OS. It’s up to the OS. Simulation happens between the two PhysxScene calls “simulate” and “fetchResults”. Your application can do whatever other work it has to do in between these two calls. “fetchResults” blocks until the PhysX simulation is done, and copies the results back to the physics objects. You could work with two Padna3D tassk for example, one with high priority to start the simulation, and one with low priority at the end of the frame. Or call “simulate” at the end of a frame, and “fetchResults” at the start of the next frame.
PhysX SDK allows a finer thread control by using NX_SF_ENABLE_MULTITHREAD. This is not yet implemented by the Panda3D PhysX code. I will put it on my TODO list. It will probably become a config option.
If you use PhysX from C++ you can of course make use of every feature the PhysX engine offers. Less restrictions, but more work to do yourself.
Speaking about performance: are you using the rigid body combiner from Panda3D? If not this is most certainly your true performance bottleneck.
One idea would be to create a single GeomNode with line primitives (one line for each link), and use a GeomVertexWriter to update the vertex positions each frame. I think this would be faster than using ropes.
Another idea would be to use the LineSegs utility class. Maybe a bit slower than the GeomVertexWriter, but very easy to use.
Sure. A force field is nothing but an utility class which computes and applies a force each frame to each actor (or body in ODE). It is always possible to compute the forces yourself. If done in C++ this might not be much slower than PhysX force fields.
Done. There is a config option ‘physx-internal-threads’ now which allows to enable multithreaded/multicore mode. Default value is 0, meaning no internal threads. Internal threads will be created on each logical processors, skipping the first.
wow, you’re amazing thorough! I’m traveling right now but I’ll get to work on all of the food for thought when I get back on Saturday night. I’ll let you know how I fare with each piece. Is the change you’ve made in the threading available in a repo somewhere?
This is strange. Downloading and compiling Panda3D yourself won’t fix it, since the line which generates this error has not changed and the error comes from the PhysX engine and not the wrappers.
One idea would be to upgrade the PhysX runtime to 9.10.0129. Your 9.09.0814 is quite outdated and contains the very first release of the 2.8.3 runtime. I think Panda3D 1.7.0 is compiled with a more recent version.
If this doesn’t help I will need more information.
For some reason I no longer remember I thought it would be clever to have the release method for an object on the object itself, and not on the owing object. So for releasing an PhysxActor you can use actor.release(), instead of scene.releaseActor(actor).
Hmm… I just noticed that the new automatic created API documentation is missing these methods. Static methods seem to be missing too.
I just started to look into this, and found out that this isn’t true. They pulled the linux download, but they are (very shortly now) planning on releasing a new version. (They said 2 to 3 weeks on May 19th)
Now, all the other concerns certainly are an issue, and I won’t argue that enthusiasm may be fading… but I thought I’d point out that they claim linux support is returning.
I’m still looking for something that works better than ODE, and PhysX(specifically PandaPhysX) looks viable at the moment. (I really wish there were Bullet support for Panda3D) Just have to have Linux support… so here’s hoping.
