I’m developing a very simple game for kids where objects bounce one with each other and with borders of the screen, like in a top view billiard table. So far I have only the right border and I move the objects like this:
msg.post("#collisionobject", “apply_force”, {force = vmath.vector3(28, 0, 0), position = go.get_world_position()})
The mass of the bouncig objects is 0.009, restitution is 1, friction is 0, collision shape Box.
The right border is dynamic, has mass 1000, restitution 1, friction 0, collision shape Box.
The problem I’m facing is that the objects move a little too fast, but to make them slower I have to either increase their mass (for example 0.01 instead of 0.009) or decrease the force I apply them, (for example 25 instead of 28).
If I do one of these changes the initial speed is correct, but the objects get stuck to the border when they touch it instead of bouncing.
start to adjust their friction and restitution figures as well, by that i mean if you increase the velocity, you can afford to increase friction and decrease restitution
Thanks but changing friction and restitution does not help.
I would like objects to move slowly (this is easy adjusting mass and initial force) and to bounce at the same slow speed, with opposite direction, when they touch the border.
Unfortunately if they don’t have enough initial speed they simply don’t bounce at all, they get stuck to the border like a magnet, I don’t understand why. It’s not realistic.
In my first post I forgot to mention that in game.project I have set gravity_y = 0.
Why don’t you make the border a static object? Even with that mass it is probably soaking up some of the impact. Not to mention that ridiculous mass ratio might make the physics engine buggy.
You can double-check the “contact_impulse_limit” in your game.project file, but it does default to zero.
I made the border a static object, it does not help. The objects touch the border and get stuck.
I also tried to change the mass of the objects to 1, and the initial force to something like vmath.vector3(3100, 0, 0).
As with previous experiments what matters is initial speed, with vmath.vector3(3100, 0, 0) the objects bounce correctly, but if I change that to, for example, vmath.vector3(3000, 0, 0) (to reduce speed) the objects get stuck to the border.
Thanks anyway for the suggestion.
I’m sure that would be an interesting learning experience, but I also think that the defold physics engine should handle this scenario correctly.
The manual says that:
The restitution value sets the bounciness of the object. The value is usually between 0 (inelastic collision—the object does not bounce at all) and 1 (perfectly elastic collision—the object’s velocity will be exactly reflected in the bounce)
It seems that, under a certain speed, objects with restitution 1 behave like objects with restitution 0. -> THEY DON’T BOUNCE AS EXPECTED
I think it’s a bug.
To reproduce:
In game.project set gravity_y = 0.
Put a static object somewhere on the right
Take an object with mass 1 and restitution 1 and give it an impulse like this: msg.post("#collisionobject", “apply_force”, {force = vmath.vector3(3000, 0, 0), position = go.get_world_position()}) -> THE OBJECT DOES NOT BOUNCE
Use 3100 instead of 3000. -> THE OBJECT BOUNCES CORRECTLY
I’m able to reproduce the same behaviour with the ball getting stuck to the wall:
We use Box2D and the physics behave according to the specifics of that physics engine. What you’re describing sounds a bit like this issue:
We use a b2_velocityThreshold value of 1.0f and it’s currently not exposed as a value that you can adjust yourself. I’ll add a ticket for this once I’m back at the office tomorrow morning.
This is really good news, thanks for taking care of this issue!
Will you include the ability to change b2_velocityThreshold value in the next update of Defold? (and if yes, when is it scheduled?)
I’ve looked into this a bit more and while a configurable b2_velocityThreshold would solve some issues I also believe that a reasonable approach would be for you to increase physics scale in game.project. If you increase the physics scale from the default value of 0.02 up to 1.0 (maximum value) you will see that collisions are resolved correctly even at very low speeds.
In short it was a problem of my development notebook not respecing vsync, that I resolved enabling variable_dt. After that, bouncing was “slow enough” without any tweaking.
Thanks for support.
Good to hear that you’ve solved the problem! I believe @Johan_Beck-Noren is looking into this problem with throttling of the engine if the gfx driver doesn’t respect vsync.