To avoid further confusion: here is a full example of using PandaPhysX from C++. The example is roughly equivalent to the Python sample “01_Basics.py”. A simple scene with a ground plane and a falling box is created, plus the debug renderer.
Thanks for the help. I appoogize for overseeing this stupid mistake.
Still, debug node prolem remains - even when using your code.
g_pDebugNode = g_pPhysScene->get_debug_node();
This line will actually be run through normally. Upon entering panda’s main loop, however, the application will shut down immidiately, without any messages or exceptions thrown.
This line will cause an exception in PointerToBase.I
Of course, the first problem only occurs (is visible) when the second line is not active. Since I do not know where to search for the problem, I’m kind of lost here. I don’t know what information to supply either, since I do not get any error messages.
Strange. I have compiled and run the example from above on a Windows
maching, and it (1) doesn’t crash, and (2) renders the debug geometry. I’m pretty sure the problem is somewhere else, maybe you still have mistakes in your code or your project setting are bad.
First hinT: VC has a built in debugger as far as I know. Try using the debugger to find out where the problem ist. Another NULL pointer access?
Another hint: posting just two lines doesn’t help much. As you have seen it is easy to oversee mistakes, because they are made somewhere else. The best chance to get help is if you pack up your project files and source code in such a way that others can download it and compile it.
Strange indeed. I set up a new project, created Main.cpp and copied your code (“01_Basics.py” imitation from earlier in this thread) into it. I linked the project against
This project is clean of all external code (e.g. by me) and I did not modify the source in any way. Yet I still get the error when accessing the scene’s debug node:
The first line will - by itself, second line commented - cause the application to terminate instantly, without any messages what so ever.
Inspecting the variables upon crash the debugger tells me the g_window variable holds (apparently) valid data while the g_scene and g_debugNode only hold a PointerToBase and PointerToBase respectively which both only hold a pointer to void. I don’t know if this is supposed to be or if the debugger cannot obtain more detailed information.
Further confusing is the fact that only accessing the scene’s get_debug_node() method by itself will cause strange behaviour. The application will run through the statement without any special messages but upon encountering panda’s main loop statement it will terminate instantly. This will happen even if I only call the method, not even assigning its return value to a variable - less to speak of actually doing something with it.
Deactivating/commenting both lines will have the project work just fine so I would expect the problem to be only with the scene’s debug node.
I’m using VS2008 on WinXP with Panda’s windows standard build.
You’re not making your build in Debug mode, are you? If you’re using the standard Panda3D libraries, you have to make your build in Release mode, or it will crash at inexplicable places.
I am using VC2008 too, but from the command line and using scons as a build system. anyway, here are the command lines I got for compiling and linking the example (main.cxx, no header file). Please check if you are using different compiler/linker flags. VC should display what commands it executes.
Hmm… you are using 0.4.7 (just to make sure)? And did you compile PandaPhysX yourself? If so, did you use the scons file or did you setup a VC project yourself?
Reduce the height of the controller, e. g. PhysCapsuleController.setHeight(). You might have to adjust the offset of your ‘visual’ character model (aka Actor), since the visual models usually have their origin between their legs, while the physcial controller has it’s origin in the center of the body.
PhysCapsuleController.setHeight() makes my PhysController fall through the floor, even when setting it to its current height. I guess the capsule gets removed and then replaced with a new one, I’ll probably have to make the controller jump before changing the height.
It seems that the radius is also changing even though I’m not calling a setRadius. If I use setRadius after or before setHeight I get some weird results, the radius becomes more, even though I am also setting it to its supposed current radius. I see that you did not implement croutching in the controller sample. After adding self.controller.setHeight(factor) to the doCroutch function, the controller also falls through the ground, but if I jump first and then croutch the radius also changes. Could this be a bug?
Yes, there is a bug. setHeight() doesn’t set the height, but the radius.
Trying to place the controller exactly on the height of the ground will result in it randomly falling through the ground. Try setting it a bit above the ground. Depending on the ground slope you might want to set it even higher.
I’m simulating a whole bunch of boxes falling into a container. They nicely fall down and begin stacking in some random order just like one would expect but there is also some odd event happening: they won’t settle down completely.
Every once and then one of the boxes suddenly leaps up and falls down again, just like something has hit it from beneath. At that point in time, the boxes have alrdeady started to settle down and are barely moving at all. It’s unlikely one of the boxes on the bottom of the stack could be moving that fast as to push/hit other boxes completely ouf of place again - not to speak of making them fly up.
From my experiences with the physics engine I guess this is due to some “internal” collision of the boxes - meaning their physical shapes overlap instead of collide - which will result in a strong force pushing hem away from each other, just as putting two actors in a scene with overlapping coordinates and bodies. At least it looks pretty similar.
Unfortunately, I still can’t use the pandaphysx debug mode as it will crash the application immidiately upon initialization of the mode. I’ll get to that problem one of these days. Until then, I hope you can give me some advice on what is happening here and how I can analyze/solve the problem. Is there a way to set something like a “penetration depth” for actors so those boxes will collide immidiately upon contact ? Although I guess they are already doing exactly that.
The boxes will eventually come to rest but it does look kind of odd until then.
Maybe these parameters will help:
Box count: 4x4x50
Mass: 1 - 10 (random for each box)
DynFrict: 0.4
StatFrict: 0.4
Rest: 0.01 (even this low a restituion will not prevent “late bouncing”)
Shape: 1x1x1 up to 5x5x5 (random for each box)
This is a problem inherent to computer physics (note: physics not physx). It can’t be solved in a physical correct way. The best you can do is to “cheat” and use tuning factors to get better results. All physics engine offer various tuning factors. This is what you could try with PhysX:
Modify the skin width. The PhysX SDK has a nice chapter about skin with and what it is for. This is the most important factor, since the skin is a region where shapes can interpenetrate.
Increase solver iteration count (not sure if this is wrapped…).
Use smaller timesteps/substeps.
Tune sleep thresholds (e.g. energy threshold).
Be aware that all tuning has downsides too. So you might gain in one aspect but loose in another. It depends on your scene.
I have yet another problem, this time with PhysCapsuleShapeDesc. Whenever I try to create an actor with a capsule shape my application’s heap gets corrupted. If I replace that one line with just any other kind of shape it’s all fine. I checked everything else but it seems like it really is a problem with the capsule shape.
I figured the bug with the capsule controller you mentioned might be causing the trouble but then again I don’t have any collision problems with the capsule (so far). The run-time will just tell me there’s a heap corruption but is still able to continue (no crash!). I don’t get this …
Question for enn0x and also for Panda3D gurus out there:
I have a set of animated characters (22 total), and i’m attaching kinematic PhysActor objects (boxes) to each joint of each of those characters. Each character has 20 joints, so there’s 440 joints total. Since the movement of joints is controlled by animation, i have this function that is called once every frame:
def moveJointActors(self):
for actor,nlist in self.jointActors.iteritems():
for jnp,cnp in nlist:
cnp.setGlobalMat(jnp.getMat(render))
jnp - is a joint NodePath
cnp - is the corresponding PhysActor object
So basically, it just takes the position/rotation of a joint and applies it to the corresponding PhysActor.
For some reason, this appears to be really ineffective - i checked with pstats, and it takes over 8 ms to do this operation, which is way too long (I’m trying to keep the entire frame time under 17 ms, to maintain 60 fps). Is the approach i’m taking with moveJointActors a fundamentally wrong way to do what i’m trying to do?
Without any measuring by myself: seems right. 440 transforms from C to Python to C is a bit of work. Synchronization from PhysActor --> NodePath is done automatically, but NodePath --> PhysActor not.
If nobody else has an idea: my suggestion would be to extend PhysScene with a list of registered (kinematic) Actors for which a NodePath --> PhysActor sync should be done automatically when calling doPhyscis (or a new method, e. g. updateKinematic). I don’t want to promise any number for performance increase.
Should not be to much work. I could try to do it this weekend. Are you on Windows?
tried to implement your suggestion, and got everything to build and work correctly, it seems, but no real speedup . I’ll wait for your version. Thanks.
Here it is. For updating the kinematic actors I use actor.moveGlobalMat(), and not actor.setGlobalMat(). This way is recommended by the PhysX manuals. I have not done any performance tests, so please tell me if there is a speedup. PStats should have a PhysX category now, with some subcategories, to give additional info.
Please notice that this is an experimental release. Also my Linux box died, so this time there are only binaries for Windows. I have not been able to test the code on Linux.
. I’ll wait for your version. Thanks.