Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Doing Game Gravity Right

niksula.hut.fi

Post reply on HN
Print view View original

81–86 of 86 posts

Re: Doing Game Gravity Right

#81

Post by teamonkey »

jheriko wrote: post #68
teamonkey wrote: post #40

Earlier quoted context omitted.

> This is still Euler integration Actually it's a form of Verlet integration, which performs much better than Euler's method while being much cheaper than RK4. Euler's method does not perform well with any form of acceleration and should not be used when acceleration is present. The equations here will remain accurate under constant gravity.

actually this is the 'midpoint' method. verlet is different in that it negates needing the first order term altogether, which is instead gotten at any instant from the previous and current position (zeroth order term). but yes, verlet is much more powerful for game physics, especially when coupled with constraints since it allows all kinds of non-trivial behaviour (angular momentum) to fall out.

IIRC

  Midpoint
  v(n+1) = v(n) + a(n)*dt
  x(n+1) = x + v(n)*dt + 0.5*a(n)*dt^2

  Velocity Verlet
  v(n+1) = v(n) + 0.5*[a(n)+a(n+1)]*dt
  x(n+1) = x + v(n)*dt + 0.25*[a(n)+a(n+1)]*dt^2
With fixed acceleration a(n)=a(n+1) so the two methods are equivalent.

Re: Doing Game Gravity Right

#82

Post by teamonkey »

robertfw wrote: post #36
pfisch wrote: post #4

Why does this even matter? If you have a large delta time then your game is fucked anyway. Collision detection will likely also be broken and the game is unplayably choppy anyway so it doesn't even matter.

I remember a car trick (do a barrel roll) in GTA San Andreas that for the life of me I could not accomplish. I found out that this variable physics was likely the problem - I dropped the graphics settings to minimum, and I was able to do the trick. This is on a quad core, 8GB ram, 1GB video card machine - it's no slouch - but the subtle difference was enough to make my task impossible.

On the PS2 you could adjust the roll and pitch of your car in midair. It was possible to do backflips.

Re: Doing Game Gravity Right

#83

Post by csense »

rom16384 wrote: post #61
ori_b wrote: post #13

This is still Euler integration, which has poor accuracy whenever the derivative varies with time. The standard numerical integration method is 4th order Runge Kutta. RK4 is also popular for solving many forms of differential equations. A good summary is here: http://gafferongames.com/game-physics/integration-basics/

RK4 is indeed a popular and standard method. However for this particular equation or other equations with a conserved quantity a Symplectic integrator [1] should be used, as they are much better at keeping the numerical solution close to the real solution since they conserve the quantity of interest (energy, etc.). [1] https://en.wikipedia.org/wiki/Symplectic_integrator

RK4 is hard to write. Symplectic integrator looks even harder. (I'm not familiar with symplectic integration, but I've just read the Wikipedia article and it's not immediately obvious how to go from the math in the article to working code. I have written an RK4 integrator in the past, and the RK4 Wikipedia article looks like it's much easier to apply if you're writing the integrator for a physics engine.)

Euler, Euler midpoint, and Verlet are all very easy to code.

Also, you have to keep in mind the operation count versus the numerical stability. For the case under discussion -- constant acceleration -- Euler midpoint is perfectly suitable, as it gives the same answer as an exact analytical solution for the case where x(t) and y(t) are quadratic polynomials. RK4 or the like would only result in longer and slower code with no actual benefit in this particular application.

Re: Doing Game Gravity Right

#84

Post by csense »

hyperlogic wrote: post #24
ori_b wrote: post #13

This is still Euler integration, which has poor accuracy whenever the derivative varies with time. The standard numerical integration method is 4th order Runge Kutta. RK4 is also popular for solving many forms of differential equations. A good summary is here: http://gafferongames.com/game-physics/integration-basics/

Correct me if I'm wrong, there is no reason to numerically integrate this. This is not a differential equation. The integral solution is a simple function that can just be evaluated.

I think the article is handling it this way for pedagogical reasons. It's more clearly in the realm of "Software Engineering" to say "This is what our solution's trying to approximate, and the easiest approximation causes practical problems, so this is a better way to approximate the same thing (in an only slightly more complicated way) by adding an extra term." The author's approach is easier to understand because it's merely a small patch on an existing design.

If you say "By the way, there's an exact solution to this, it involves something called Integrals that's usually the focus of at least three semesters of Calculus in college, but you can't really understand it without a few courses in Real Analysis, Differential Equations, and Numerical Methods..." then it seems like you're talking too much about Math instead of Software Engineering. As a result, you lose the audience whose main interest is making games for fun and profit, and don't care about math (or so they think). It's much harder to understand because it's a complete redesign of the integrator that relies on a non-trivial body of theory.

Re: Doing Game Gravity Right

#85

Post by Garoof »

njharman wrote: post #72
raldi wrote: post #60

Earlier quoted context omitted.

Yeah, I don't get the difference between the left and right sides of the two graphs either.

I believe the only difference is in units. Left showing delta time. right showing FPS.

Yeah, but shouldn't a delta of 1/3s be the same as 3fps? But the 1/3s to the left does not look like the 3fps to the right.

And it does say that the picture to the right is just like in Quake. So I was guessing that maybe the one to the left is not. Like, it has higher initial velocity and max height, and longer time spent in the air. Like the picture to the right is a jump that lasts for Would be nice to have like axes with labels and things on them.

Re: Doing Game Gravity Right

#86

Post by Arelius »

Garoof wrote: post #48
Arelius wrote: post #38

Earlier quoted context omitted.

So, why is it important to have a fixed deltaTime? Except in cases where determinism really does matter. I.E. lock-step based networking. Why is this important?

Because without fixed deltaTime, if the framerate is too low, you can't jump in Quake. With the "new algorithm", in the 3fps example, you still have to luck out and get a tick at the right time. And with a constant delta, if you choose it right, it can be easier to get collision detection right. You can possibly get away with checking if two things are colliding with each other right this tick instead of checking if…

Constand delta time does not solve collisions. You should always be using continious collision detection for things you care about, or eventually something will go to fast even for fixed dT.

One good argument for variable dT is if you do enough logic such that game time may be a major performance bound. If on a machine that is running fixed dT cannot perform all computation in the allotted time, then the game will get behind schedule, and how do you resolve the problem of having a wall clock 10, 100, or more frames ahead of simulated time when you can't keep up. In that regard variable dT degrades more gracefully.

Post reply on HN