Problem with static rigid body in 2.11

[B_old]

Hello,

when I use 2.11 I have a problem with static rigid bodies and I can't quite figure out what is wrong.
I use a function that is practically identical to localCreateRigidBody() from the demo framework. The rest should also be set up the same as in the demo.

Anyway, the problem is, that when I let the DebugDrawer visualize the AABBs, the one of my static body is really tiny, which seems consistent with the behaviour of the physics.

EDIT: For a sphere shape the AABB seems to have suitable sice, still the collision behaviour is strange.

Do you have any idea what could cause this? I just can't find what I am doing different compared to the demo.



P.S.:
Have you considered to give the DebugDrawer the ability to draw the collision shapes? When I draw them myself, they look like what I think they are supposed to look. Bullet obviously has a different oppinion in my case .

[Erwin Coumans]

Hi,

More information would be helpful. What static shapes are you using? Can you try a simple version, and debug it yourself? Some screenshots would help. What object sizes are you using? Note that the _order_ of initializing does matter. Changing the transforms for static shapes after creation might fail (for example, BVH tree is build during creation, not re-build).

still the collision behaviour is strange.

If you can be more specific that would help. How does it differ from the Bullet demos?

Also notice that you can directly create btCollisionShape for static stuff, you are not required to create a btRigidBody (although that should still work).

I consider adding more to debugdrawer, making it more a btAnalyser, that can be used more generally (for example to detect number of GJK iterations, cache misses etc).

Please let us know on the forum what you find out,
Erwin

[B_old]

Hi,

I found my problem.
For static stuff it seems to be important, that you don't forget, to call btTransform::setIdentity() before you set the origin ect.. I just assumed btTransform would be constructed as being identity.

I drop a box straight down on a static plane (a)/big static box (b).
In case a) the box just falls down bounces upwards a little bit and everything looks normal.
In case b) the box falls down and bounces around a little more also having some spin to it.
So although you might expect the same behaviour in both cases, this is not the case (not that dramatic either though...).
My fault?

btMatrix3x3::getOpenGLSubMatrix(), what is so OpenGL about this?
I use this matrix as it is, rendering with D3D. That is, neither do I transpose the matrix nor invert any axis. (Although I believe I had to do that when I used the finished transformation matrix, which I rather calculate myself now)

[Erwin Coumans]

Hi,

I found my problem.
For static stuff it seems to be important, that you don't forget, to call btTransform::setIdentity() before you set the origin ect.. I just assumed btTransform would be constructed as being identity.

Just like the C/C++ built-in types like float and int, the math classes btScalar, btVector3, btTransform needs to be initialized before usage. I can put asserts in the operators in debug mode, to easily detect uninitialized data, or put it in the documentation (or both).

I drop a box straight down on a static plane (a)/big static box (b).
In case a) the box just falls down bounces upwards a little bit and everything looks normal.
In case b) the box falls down and bounces around a little more also having some spin to it.
So although you might expect the same behaviour in both cases, this is not the case (not that dramatic either though...).
My fault?

Single Convex Collision Objects should be moderately sized. Using the default settings, none of the objects should be larger then say 40 units, or smaller then 0.2 units. The btPlaneShape tesselated the ground into triangles on-the-fly, by projecting objects onto the plane.

getOpenGLSubMatrix(), what is so OpenGL about this?
I use this matrix as it is, rendering with D3D. That is, neither do I transpose the matrix nor invert any axis. (Although I believe I had to do that when I used the finished transformation matrix, which I rather calculate myself now)

The btTransform::getOpenGLMatrix(..) returns a matrix that is compatible with OpenGL. Referring to this well documented and multiplatform graphics API should help developers synchronize the physics worldtransform with the graphics worldtransform. If you use another API, you can find out how the memory layout of the matrix differs from OpenGL, or just convert the Bullet transform element by element.

Thanks for your feedback. This will all be added to the documentation (work in progress, see the Bullet TODO topic).

[B_old]

I was wondering about units.
With the default settings, what would 1 unit correspond to in the real world. 1 meter maybe?

[Erwin Coumans]

It is a matter of interpretation, and you get what you put into the system, but if you use default gravity of -9.8 m^2/sec, indeed 1 meter equals 1 unit, and 1 timeStep unit equals 1 second.

The tuning parameters (collision margin, timestep size, contact breaking treshold etc) have been tuned with those settings in mind.

You can also interpret the values in other units (aside from the tuning parameters, Bullet is unit-free).