Endless Bounce Problem

There are some parts of the solid level that bounce more than it would be possible in real world, resulting in a perpetuum mobile… Is this a bug in the bullet framework?

[video]http://www.youtube.com/watch?v=9BqLyRjwJZo[/video]

As mentioned above, most parts of the level walls do have a correct behavior.
The physics space uses an accuracy of (1f / 1080f). Both the level and the ball have a restitution and friction of a value lower than 1. The sleeping treshold equals 0.035f and dumping equals 0.24f.

You move a mesh collision shape, so you will get no normal collision results. Your values for the physics space accuracy are insane, you should stick with the defaults, they are fine.
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.

Also with rotation objets that behaviour is expected, as the bulle documentation states, due to precision issues. A simple solution would be to set a very small linear dampening (or angular dampening) to slow it down a bit artifically.

@normen said: You move a mesh collision shape, so you will get no normal collision results.

That’s not true. The ball is caculated using a SphereCollisionShape. In the video you should identfy blue little “x” signs on the surface of the ball. A mesh collision shape would look like a mesh… BTW I also tested a mesh collision shape which would not even roll :slight_smile:

Your values for the physics space accuracy are insane, you should stick with the defaults, they are fine.
I totally disagree with that. Using the default accuracy of (1f/60f) the ball bounces very oddly and falls through the level very easily. If I drop the ball from 2f = 2 meters at the beginning of the game, the ball would certainly fall through the ground. So the defaults may be good for some blood splatter effects and kicking some bricks around but not for achieving a roughly realistic behavior. I must repeat: Most parts of the level do have realistic and accurate behavior with an accuracy of (1f/1080f)

What could cause this bug?

Are you sure, this behaviour is caused by bullet?
Maybe you apply forces accidentally in a collision handler, because the ball is receiving forces every time it bounces off the wall - I can’t really imagine, that bullet is doing this by default… But I don’t know it good enough, just a random idea. :slight_smile:

Also with rotation objets that behaviour is expected, as the bulle documentation states, due to precision issues.

Do you mean that physical bugs can occur everywhere because of fundamental issues in the bullet framework?
Where to find the bullet documentation? I probably have to know this part of the documentation…

Yeah, from how the ball moves I deduced that you move the outside mesh somehow, making it bounce away from the sides. Because vanilla bullet with a static mesh like this and spheres doesn’t behave like this. Make a test case if you really think it does, without all of your code, just with the mesh and the sphere and I can look at it.
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.

http://bulletphysics.com/ftp/pub/test/physics/Bullet_User_Manual.pdf

http://bulletphysics.org/Bullet/phpBB3/index.php

I sugest reading 14, you probably use real sizes ? Thats a problem, make the pool table like 100 meters long and scale everything accordingly, then you can use normal 1/60 accuracy, and probably your effects that come from rounding errors of very small nubmers go away as well.

1 Like
@Empire Phoenix said: http://bulletphysics.com/ftp/pub/test/physics/Bullet_User_Manual.pdf

http://bulletphysics.org/Bullet/phpBB3/index.php

I sugest reading 14, you probably use real sizes ? Thats a problem, make the pool table like 100 meters long and scale everything accordingly, then you can use normal 1/60 accuracy, and probably your effects that come from rounding errors of very small nubmers go away as well.

Scaling everything up with a factor of 5 did the trick. Now every bug has dissapeared. Thank you four this tip Phoenix!