Panda Bullet

as you wish:

paste.pocoo.org/show/451498/ <- rotation

node rotates 90° but the box rotates 180° or 0°. Testing with different rotations shows very strange results.

And for the “Trianglemesh” issue: paste.pocoo.org/show/451548/
The last parameter of the create calls (ll. 49) can be used to switch between hull and trianglemesh. The problem only occurs for scaled models, so the scale seems to be applied correctly for the hull but not for the trianglemeshshape.

Any ideas how to create a ragdoll? I could provide a rigged human model.

Oh and when I turn on shader generator on render, the debug lines become black.

@Nox_firegalaxy
Thank you for the samples; this is by far the best way to describe a problem.

I won’t have a change to run the scripts this evening, but I will do so tomorrow. So please have a bit patience.

I had a look at your first script. I can’t see a bug. Your problem are these lines:

node = loader.loadModel("models/ralph/ralph").copyTo(render)
node.setHpr(0,0,20)
amin, amax = node.getTightBounds()

You load the model, rotate it, and then read the tight bounds.

Tight bounds is an axis-aligned bounding box! This means that amni and amax depend on the orientation of the model. Try yourself: start with setHpr(0,0,0), then increase a little bit (0,0,10) and then more. At first everything is fine, then the box becomes more and more stretched, until at (0,0,90) it seems to be rotated.

So first read the bounds, then rotated the model:

node = loader.loadModel("models/ralph/ralph").copyTo(render)
amin, amax = node.getTightBounds()
node.setHpr(0,0,20)

Just for the record:

The above samples used by Nox_firegalaxy all have one thing in common: The PandaNode for the Bullet body/ghost is a CHILD of the PandaNode with the visual geometry.

This might work for Nox_firegalaxy, since he is interested in collision detection only. But it certainly won’t work if you are interested in physics. Because the synchronisation Bullet --> Panda will move the BulletGhostNode/BulletRigidBodyNode/etc. nodes around. The visual models will stay where they are.

I mention this explicitly because newbies might look at the samples and apply to this pattern to their own script, and then tell me there is a bug because the bodies don’t move. So please always have the visual geometry etc. as childs of the BulletRigidBodyNode (or other Bullet objects):

render
    ...
        BulletRigidBodyNode
            GeomNode (visual model)
            ...

Right. I remember having read somewhere on the Bullet forums that scaling dynamic triangle meshes (btGImpactMeshShape) can be tricky. I will investigate. Generally it is best not to use scale at all when dealing with collision and physics.

If I try to collide a sphere with mass 0 with a cube which is on a collision plane, then they won’t collide with each other, if the cube will be in midair or if the collision shape will have mass, then they will collide.

Sorry my fault. I reduced the example to strongly and made this stupid misstake. Please have a look at (now hopefully without missuse of mine): paste.pocoo.org/show/453064/
So you seems to be right that currently senseful to avoid using scales at all. Will be hard to remove it in my usecase…

What is the best way to represent an object composed of multiple movable parts? My main concern is to avoid the “collision” between these parts at bulletlevel if this is possible.

If I understand you right then you don’t get collision between two static objects. This is ok, since afaik Bullet won’t generate collisions or collision response (forces) between static objects.

I can see what you mean now. So far I am not 100 percent sure what is causing this effect. It seems like this effect is caused by Bullet internally (Bullet distinguishes internally between an object’s transform and it’s interpolated transform). At the moment it seems hard to fix.

However, if you set up the scene graph in the way the Panda Bullet module designed you won’t have this problem (BulletGhostNode, then the Actor/whatever nodes as children). Also the effect is gone if you don’t set a scale.

anyway, while investigating I found a bunch of other issues with local/global scale. I am currently working on an improved system for synchronisation, but this will need some time.

If composed means that they somehow should stay close together then it would be joints. The bullet term for joints is “constraint”. And you could use collision filtering for deactivating collision between these objects.

Hello,
While testing BulletCharacterControllerNode i received the following warning:

after some debugging I found that the character controller ghostobject collision flags in Panda3D are set as follows:

but in bullet character controller sample they are set as follows:

changing the flags in Panda3D to match bullet removed the warning.

@AL.dev
Ahh… right, the kinematic flag is not necessary. Thanks for finding out. I checked in a fix. What operating system are you using, because I never have seen this warning before?

My pleasure :slight_smile:. I’m using windows xp, the message appeared in the console window.

Ok, I investigated some more, and found the cause for this strange behavious. The problem has been my conversion from (Panda3D) TransformState to (Bullet) btTransform. This conversion has been fudged if the TransformState had a scale unequal 1. I just commited a fix.

After fiddling for several hours yesterday and reading through this whole thread today, I finally found the constraint test in enn0x’ r18 release. In there, it says that all constraints except ConeTwist and Distance don’t work on linux yet. On one hand, that explains my massive problems getting a slider to work. :slight_smile: On the other hand, it blocks further development for me. Is there any chance getting them to work somewhere in the foreseeable future?

I’d be happy to write some documentation (once I figured out how that works in the end…), but I’m afraid I cannot really help on code on that layer.

These constraints work find on windows, but lead to numeric overflows in bounding boxes on Linux. It seems to be a problem inside Bullet, but I’m not certain here. Anyway, so far I didn’t have time to investigate deeper. Any tips or hints are welcome.

I’ve got a brand new question!

It took a while for me to figure out that there should be exactly one debug node in the scene graph… Now that I know that: is it possible to selectively disable debug rendering on nodes? My heightfield terrain kills a whole lot of performance in debug mode while seeing normals floating around everywhere doesn’t get me any further. :slight_smile: