Projectile motion - prediction vs Box2D actual

Here's the place to get help and discuss features. The focus is on the C++ version, but generic questions are welcome.
Boxen
Posts: 7
Joined: Thu Jun 24, 2010 8:25 pm

Projectile motion - prediction vs Box2D actual

Postby Boxen » Sun Feb 27, 2011 4:01 pm

I'm writing a game that involves launching box2D bodies and I wanted to provide a visual indicator of where the body will go when released. I'm using basic projectile motion maths to draw the path I expect the body to take, but when it's launched it consistently arcs lower than my predicted curve (by roughly 5-10%).

Can anyone think of any reason this would be happening? Does box 2D use some other algorithms for gravity/velocity/etc that would be inconsistent with what I'm using (like maybe simplified estimated maths for performance reasons)? Or is there some sort of global damping/drag that is being applied for stability sake?

I could just use trial & error to work out what percentage to dampen my prediction path, but that seems a bit hacky without knowing why it's not working.

If it makes any difference I'm using the Box2D implementation inside the AndEngine for android (which I believe is native compiled C++, not Java).

pTymN
Posts: 518
Joined: Tue Sep 25, 2007 2:22 pm

Re: Projectile motion - prediction vs Box2D actual

Postby pTymN » Sun Feb 27, 2011 7:54 pm

Box2D, and probably most other physics engines that you'll see in games are not going to match up very well with predicted results. Physics equations are used when making a physics engine, but they generally don't take into account real world performance, particularly with collision resolution.

Here's the code for integrating body positions: (from b2Island.cpp)

Code: Select all

      // Integrate velocities.
      b->m_linearVelocity += step.dt * (gravity + b->m_invMass * b->m_force);
      b->m_angularVelocity += step.dt * b->m_invI * b->m_torque;


As you can see, it just uses euler integration, nothing fancy. I think that there are other physics engines whose design goal is less focussed on use in games and real time applications that will give you more accurate results.

irresistible force
Posts: 1991
Joined: Tue Jun 24, 2008 8:25 pm
Location: Tokyo
Contact:

Re: Projectile motion - prediction vs Box2D actual

Postby irresistible force » Tue Mar 01, 2011 11:50 pm

Is there any linear damping on the projectile body? I tried this too but I didn't have any trouble like you mention...
Just take the starting position (px,py) and velocity (vx,xy) of the projectile, and each step do:

px += vx;
py += vy;
vy += (-9.8f / 60.0f / 60.0f);

In my case gravity was the typical -9.8, and the 60 was the time steps per second.
Note that you need to know the velocity the projectile will start at, so if the inputs from your player are say a direction and a 'power' then you'll need to consider how that will affect the projectile depending on how heavy it is etc and calculate the initial velocity.

Boxen
Posts: 7
Joined: Thu Jun 24, 2010 8:25 pm

Re: Projectile motion - prediction vs Box2D actual

Postby Boxen » Thu Mar 03, 2011 10:12 pm

Thanks for the replies guys... I switched my calculations over to using similar euler integrations to what @pTymN posted and was hopeful that that would be the issue. Unfortunately it wasn't... In fact, as I played around with the number of iterations in my prediction simulation, I noticed that the less accurate I made my simulation, the further from what Box2D was doing it got. In other words this clearly isn't the (only) issue as it's ranges of accuracy are always going to be outside what Box2D is actually producing.

The error is only occurring on the y-axis (which I guess makes some sense, since it's the only access that's varying velocity over time), but it appears I can make it pretty much match Box2D by damping my y velocity with a 0.925 multiplier.

It's not a mass issue as I'm using things as pure velocities (not impulses or forces, etc). I've double checked that there's no damping or other stray forces/acceleration at work and certainly can't see any. My launch code currently sets the body's velocity, angular velocity, damping, etc to 0, sets it's position with a transform, then set's the linear velocity to the same values I'm using for my prediction calculations...

Any other ideas??

Here's the code I'm using (for the prediction curve):

Code: Select all

            float a = -SensorManager.GRAVITY_EARTH;
            float vx = -(float) Math.cos(angle) * power;
            float vy = -(float) Math.sin(angle) * power * 0.925f; //TODO: WTF x0.925???

            float deltaTime = 1/30.0f;
            float x = 0;
            float y = 0;

            for (Sprite dot : trajectoryIndicator) {
                x += vx * deltaTime;
                y += vy * deltaTime;
                vy += a * deltaTime;
                dot.setPosition(getCenterX() - x * PhysicsConstants.PIXEL_TO_METER_RATIO_DEFAULT, getCenterY() - y * PhysicsConstants.PIXEL_TO_METER_RATIO_DEFAULT);
                dot.setVisible(true);
            }

sketchbookgames
Posts: 564
Joined: Tue Feb 24, 2009 4:10 pm
Location: Michigan
Contact:

Re: Projectile motion - prediction vs Box2D actual

Postby sketchbookgames » Fri Mar 04, 2011 7:07 am

i think the easiest way to draw a predicted path is to actually throw an object and track track its position each frame.

you could use an invisible sensor as your object, if you don't plan on predicting its path after collision.

irresistible force
Posts: 1991
Joined: Tue Jun 24, 2008 8:25 pm
Location: Tokyo
Contact:

Re: Projectile motion - prediction vs Box2D actual

Postby irresistible force » Sat Mar 05, 2011 1:15 pm

Perhaps you could compare the position and velocity immediately after the first iteration in each of the cases, might give you a better clue than looking at the arc curve.
Your prediction's deltaTime and Box2D's timestep are the same length right? (just in case :p)

divad4686
Posts: 4
Joined: Tue Jun 07, 2011 7:49 am

Re: Projectile motion - prediction vs Box2D actual

Postby divad4686 » Thu Sep 15, 2011 1:31 pm

irresistible force wrote:Perhaps you could compare the position and velocity immediately after the first iteration in each of the cases, might give you a better clue than looking at the arc curve.
Your prediction's deltaTime and Box2D's timestep are the same length right? (just in case :p)


I just resolved a problem I had with projectile prediction thanks to this post, my prediction time stept didn't have the same length as the game time stept, but I don't undertand why does this makes a different. If we are using physics calculations should not the predictions be the same for 1/60 time variable or 1/6.

Erin Catto
Site Admin
Posts: 2948
Joined: Thu Sep 06, 2007 12:34 am

Re: Projectile motion - prediction vs Box2D actual

Postby Erin Catto » Thu Sep 15, 2011 4:51 pm

A search for Euler Integration will answer that question: http://en.wikipedia.org/wiki/Euler_method

irresistible force
Posts: 1991
Joined: Tue Jun 24, 2008 8:25 pm
Location: Tokyo
Contact:

Re: Projectile motion - prediction vs Box2D actual

Postby irresistible force » Thu Sep 15, 2011 8:57 pm

Yeah it may not be immediately obvious why, but if you take a look at what happens each time step the reason should become clear.

As an example, suppose you have an object at height 0, and you let it drop under a gravity of -10m/s/s. No matter what time step you choose the velocity after one second will be -10m/s, but the position will depend on how many increments were allowed during that one second time span:

rateofchange.png
rateofchange.png (3.52 KiB) Viewed 4469 times


*EDIT*

I made a tutorial about this:
http://www.iforce2d.net/b2dtut/projected-trajectory
Last edited by irresistible force on Mon Nov 07, 2011 3:37 am, edited 1 time in total.

divad4686
Posts: 4
Joined: Tue Jun 07, 2011 7:49 am

Re: Projectile motion - prediction vs Box2D actual

Postby divad4686 » Mon Sep 19, 2011 3:20 pm

Thanks guys, I undertand it better now


Return to “General Discussion”



Who is online

Users browsing this forum: No registered users and 2 guests