Pages: [1]
  Print  
Author Topic: Doing Game Gravity Right  (Read 12176 times)
GrosBedo
Member


Cakes 20
Posts: 710


« on: January 25, 2015, 01:21:52 am »

I don't know if this has ever been posted here, but I couldn't find any mention.

Being myself quite keen on playing Defrag, I read a lot about why the ioquake3 engine's physics works as it does, but I have never found a very clean and clear cut explanation, and how it should be fixed.

Here, I finally found one.

Source by Hannu Kankaanpaa:
http://www.niksula.hut.fi/~hkankaan/Homepages/gravity.html
Quote
Doing gravity right

Now you may be thinking: "baah, I know how to do gravity.." but there's a big flaw in the commonly used Euler's method to handle the gravity (or other forces). Even all the Quake games have this problem. Then what is it? If you have more frames per second in Quake, your player will run faster and jump higher. There are some places in Quake where you can't jump high enough if you don't have enough frames per second. Sounds odd, right?

Most of the programmers do the gravity something like this:

velocity = velocity + gravity*delta_time
position = position + velocity*delta_time

The algorithm above is ok but when delta_time changes or delta_time is too high, it causes many unwanted problems. Gravity adding should actually be done like this:

velocity = velocity + gravity*delta_time/2
position = position + velocity*delta_time
velocity = velocity + gravity*delta_time/2

That's it.. but you need proof, right?

Picture on the left shows that you should integrate the blue area to get the correct position values after deltatime (you should know from physics that velocity integrated by time gives you position).

But what the bad algorithm actually does is shown in the picture on right. It integrates the velocity incorrectly and causes many troubles.

Real integration

Wrong algorithm


Here is how the new algorithm handles the integration:

New algorithm


Now the blue area is exactly the same as in the picture on top left. You first add half of the acceleration to velocity, then add velocity to the position and then add half of the acceleration to velocity again.

Results in practice

Here is a "jumping" parabola with different delta times, using the bad algorithm. The picture on the right corresponds almost exactly to Quake. As you can see, you can't jump in Quake if you have less than 3 fps.



As delta time (dt) gets higher, the jumping curve gets lower.

Now here are results with the new algorithm:



Quite nice, don't you think? Accelerating physics are no longer approximation!

Remember that you should do all the accelerating forces like described above, not just gravity.

Integrating to the same results

The proving of the formula can also be done using integration (of course, because you are calculating areas..)

After integrating you'll get this formula:

pos = pos + 1/2*acc*dt^2 + vel*dt
vel = vel + acc*dt

Note that pos = position, vel = velocity, acc = acceleration and dt = delta_time

And optimizing that formula leads to this:

temp = acc*dt
pos = pos + dt*(vel + temp/2)
vel = vel + temp

This equals to the second formula given at the beginning of this document.

Also a great discussion that goes beyond with several commenters who propose even more exact calculations:
https://news.ycombinator.com/item?id=4934855

And a tutorial specifically aimed at real time games:
http://gafferongames.com/game-physics/fix-your-timestep/

Note also that this last website offers a very nice pack of free tutorials about networking for real time games:
http://gafferongames.com/networking-for-game-programmers/
http://gafferongames.com/networked-physics/
Logged
grey matter
Member


Cakes 8
Posts: 381

>9k


« Reply #1 on: January 25, 2015, 05:47:36 am »

Changing game physics is a NOTTODO.
Quote from: ([b
DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/NOTTODO#Stuff_we_won.27t_do_and_never_will]
Changing the core gameplay of the original game. This includes the physics, weapons, and anything that's the default gameplay. That's stuff for a mod, not for the original gameplay.

The "fixed" or "accurate" physics options already conflict with that statement, but at least they're configurable.
Logged

This space is for rent.
sago007
Posts a lot
*

Cakes 62
Posts: 1652


Open Arena Developer


WWW
« Reply #2 on: January 25, 2015, 06:22:44 am »

One thing is to know what is wrong another thing is to actually do anything about. Once the render and the physics have been coupled it is hard and risky to decouple them again.
Logged

There are nothing offending in my posts.
Suicizer
Member
Member
*

Cakes 2
Posts: 401


WWW
« Reply #3 on: January 25, 2015, 02:29:56 pm »

I'm not even into coding; yet I start to understand it a little bit.
Nice tuts.
Logged

I'm good at everything but can't do anything...
Gig
In the year 3000
***

Cakes 48
Posts: 4281


WWW
« Reply #4 on: January 26, 2015, 03:20:56 am »

Changing game physics is a NOTTODO.
The "fixed" or "accurate" physics options already conflict with that statement, but at least they're configurable.
More, "fixed" option was already built-in in latest Q3 pointreleases, IIRC, and supported in many Q3 mods. "Accurate" is OpenArena-specific, instead... but, as you said, it's configurable.
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Game_physics

However... maybe, an optional "fair new" option made by using a different algorythm with integer instead of using floating point numbers like current "accurate physics" does may allow to still have its fair physics without the extra network traffic caused by floating point... but I wonder if a such effort is really worth it...

PS: Also, that article at the beginning is especially about the first Quake game, instead of Quake 3. Although the alghorythm may be similar, maybe something may differ in the way server and client communicate or something else, I don't know.
However, I just tried in Openarena, with old-style physics (pmove_float 0 and pmove_fixed 0), and it IS possible to jump with com_maxfps 3. Same with Quake 3 1.32c. I don't have access to a Quake 1 installation at the moment, so I can't test there now.
« Last Edit: January 26, 2015, 03:38:50 am by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
andrewj
Member


Cakes 23
Posts: 571



« Reply #5 on: January 26, 2015, 05:56:05 am »

However... maybe, an optional "fair new" option made by using a different algorythm with integer instead of using floating point numbers like current "accurate physics" does may allow to still have its fair physics without the extra network traffic caused by floating point... but I wonder if a such effort is really worth it...
Physics (including gravity) is done purely server-side -- networking is not a concern here.
Logged
Gig
In the year 3000
***

Cakes 48
Posts: 4281


WWW
« Reply #6 on: January 26, 2015, 06:34:56 am »

Physics (including gravity) is done purely server-side -- networking is not a concern here.
Are you considering the long-term framerate-dependent physics problem of Q3A? I don't know the process in detail, but in general it should be someting like that at different framerates, clients do send ther infos to the server at different intervals, and this causes their position coordinates (and thus, also speed) to be rounded up at some framerates and rounded down at some other framerates. Hence, some framerates allow users to jump higher (and longer) than other framerates (at different gravity values, optimal framerates vary).

If I understood correctly, server relies on infos sent by clients... and clients with different settings do send their infos at different times, causing this "unfair" effect.

"Fixed physics" option somehow forces all clients to compute their coordinates at the same time, so all clients get the same rounding error... (although this has got some drawbacks, too, like poor connections losing many in-game sounds)...

"Accurate physics" option solves the rounding error by not rounding... sending floating point numbers instead of integer numbers in the network... at the cost of using more bandwith due to sending "longer" values.

PS: I don't know how much the "rounding error" problem has to share with the algorythm suggested at the beginning of this article... I simply meant that clients do play a part in the way Q3A do compute physics...
« Last Edit: January 26, 2015, 06:56:12 am by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
sago007
Posts a lot
*

Cakes 62
Posts: 1652


Open Arena Developer


WWW
« Reply #7 on: January 26, 2015, 10:50:54 am »

The physics are calculated on both the client and the server. The server maintain the "true" state the clients (used for anything game related) but the individual clients predicts there own movement so that they rarely experience the server correcting them (Think standing on a rotating fan). Further more the client decides the length of the time steps (inside an allowed range) and the server just recalculates based on those values.

The "Fixed physics" is close to "The final touch" from http://gafferongames.com/game-physics/fix-your-timestep/ except that it does have an accumulator and suffers from strong connection in the logic (try running at 60 fps with with Fixed 125 Hz, feel the shuttering and listen on how many announcer events are dropped).

The original physics and the "Accurate physics" options uses "Semi-fixed timestep" with an additional extension to keep it stable over a network.
Logged

There are nothing offending in my posts.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #8 on: December 06, 2015, 05:39:34 am »

First off, sorry for the ambiguous tone of my post, I didn't mean nor want to modify the OA/Q3 physics at all, they are very fun to play with and allow to do amazing tricks and fun games like defrag, so I see no reason to modify the physics at all!

My post was just a reference to a very good mathematical article that, I think, did the best job I've seen in explaining why OA/Q3 physics work the way they do, in a much clearer way than other indirect statistical analysis of the impact of FPS on the jump height (which is the basis of the FPS tuning we all know).

Knowing the exact mathematical reason why the physics work the way they do may allow to deduce interesting facts and tricks we may not even know currently, and is one of the reasons I have posted this here, maybe someone will be interested and use the maths to do some interesting calculations Smiley
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #9 on: December 06, 2015, 05:46:17 am »

About Q3, yes it has this same Euler's approximation error, and as Sago said, in the original "non fixed" physics, the client participates in the calculation of the physics, else of course there wouldn't be any impact of the client's FPS tuning on the player's physics... So, without fixed physics, the client may modify the whole game's physics, even if the server tries to fix it somewhat. In fixed physics, the server is bounding the whole game physics so the client cannot "bend" them anymore.

But indeed, the link I posted can be very interesting to make a new "very-accurate" mode that wouldn't suffer from physics approximations nor events dropping. But personally, I would still use the original physics mode, because it's just so much fun Cheesy
Logged
Pages: [1]
  Print  
 
Jump to: