2
\$\begingroup\$

I tried to set up a test demo to see if Box2D physics are working. It works, but I have one small problem: I cannot seem to get the dynamic b2Body to fall faster.

I tried modifying and setting the gravity and its gravityScale, its fixture, the density. I also tried applyForce and setLinearVelocity in a constant loop. I tried passing different values for the b2World.Step() function, by giving it different dt, velocityIterations and positionIterations. I know it has nothing to do with it, but I also tried modifying the mass of the body. By changing the gravity, I only managed to decrease its falling speed.

This is currently the falling speed.

I managed to find a way to increase the falling speed of the dynamic body, but only because I performed a b2World.Step() function multiple times per loop. I do not want to use that method to increase the falling speed.

This is the falling speed with multiple b2World.Step()-calls.

Do you have any suggestions what I could use to increase the falling speed of the dynamic body?

Edit: I now include the source code for anyone who is interested.

\$\endgroup\$
7
  • 2
    \$\begingroup\$ What size are your objects? Could you be hitting a speed limit? \$\endgroup\$ – Tyyppi_77 Jun 10 at 14:59
  • \$\begingroup\$ Note that you might want to add a MCVE to your question so that we know exactly what's going on. \$\endgroup\$ – Vaillancourt Jun 10 at 15:50
  • \$\begingroup\$ It looks to me like your object accelerates very quickly and then plateaus at a terminal velocity for the rest of the fall. That suggests to me that you're either hitting an absolute speed cap as Tyyppi_77 suggests, or you have linear damping applied to the body that's balancing out the additional acceleration due to gravity on subsequent steps. When documenting the MCVE as Vaillancourt suggests, please include both the size of the object and its damping settings. \$\endgroup\$ – DMGregory Jun 10 at 17:52
  • \$\begingroup\$ I remember many years ago learning with LibGDX and Box2d. I had this exact problem many times. It was always to do with my scale/size of objects and world. And the world tick value. There may have been more it was a long time ago \$\endgroup\$ – I_Keep_Trying Jun 11 at 12:48
  • 1
    \$\begingroup\$ Your code belongs in your question itself. Assume that any external links will not be clicked. You also have not answered the question about the size of these objects. \$\endgroup\$ – DMGregory Jun 11 at 15:37
5
\$\begingroup\$

This Stack Overflow question titled "Too slow movement despite enormous gravity in box2d" contains a link to this Box2D tutorial which says:

There is a maximum movement limit of 2.0 units per time step give in the file b2Settings.h in the source code.

(It however seems that the movement limit is now defined in the file b2_common.h, if you want to verify this yourself)

This means that if you are using pixels are units for your object sizes, you will have a maximum movement speed limit of 2 pixels per time step. This is why you only get a speed up by executing multiple timesteps, and the other parameters have no visible effect, since the speed limit is reached extremely quickly.

You will want to use smaller coordinates and sizes in your physics simulation, and multiply with an appropriate scalar to convert world coordinates into view space.

There is a mention about the units in Box2D in it's documentation's FAQ portion:

What units does Box2D use?

Box2D is tuned for meters-kilograms-seconds (MKS). Your moving objects should be between 0.1 - 10 meters. Do not use pixels as units! You will get a jittery simulation.

How do I convert pixels to meters?

Suppose you have a sprite for a character that is 100x100 pixels. You decide to use a scaling factor that is 0.01. This will make the character physics box 1m x 1m. So go make a physics box that is 1x1. Now suppose the character starts out at pixel coordinate (345,679). So position the physics box at (3.45,6.79). Now simulate the physics world. Suppose the character physics box moves to (2.31,4.98), so move your character sprite to pixel coordinates (231,498). Now the only tricky part is choosing a scaling factor. This really depends on your game. You should try to get your moving objects in the range 0.1 - 10 meters, with 1 meter being the sweet spot.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ I would like to thank you a lot. I really helped converting the unit at which the b2Body falls to a more appropriate unit at which the displayed objects fall. \$\endgroup\$ – WHofstra Jun 14 at 8:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.