1. Limited time only! Sign up for a free 30min personal tutor trial with Chegg Tutors
    Dismiss Notice
Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Game Physics

  1. Jun 23, 2007 #1
    Hi I was wondering which of the following titles I should buy with regards to building a fairly simple physics engine for a game idea I have. I don't want to rush in I want to spend my money wisely. The titles are (roughly) as follows:

    Real Time Collision Detection
    Game Physics
    Game Physics Engine Development

    They'e all in the Morgan Kaufman series. I know the last title might seem the obvious choice but I would like to be sure before I buy. For your information it is intended to be used with an existing game engine which I presume already has collision detection built in. Does that I wonder rule out the first topic title? This also makes me think is the Game Physics Engine Development thus going too far seeing as the game engine is already there?

    Would I be best looking at Game Physics as it is the physic concepts I wish to learn about the most at the moment rather than actually transferring them to code. Maybe I've answered my own question I'm not too sure I could do with some help thanks chaps :wink:
  2. jcsd
  3. Jun 23, 2007 #2


    User Avatar
    Gold Member

    Are you sure that any of them will be beneficial? Do you have a chance to review them to make sure that they're not just duplicates of stuff that you already know? It would probably be worth your while to investigate other sources as well. Shop around.
  4. Jun 23, 2007 #3
    Nice idea, I'll do that :wink:

    I think they go quite deep, I've read a few of the customer reviews and apparently the books are quite complex as is game physics apparently. No major surprise there. I bought a book to brush up on my calculus aswell.

    I think on the strength of the reveiws I'd probably go for the game physics one but again I'll stay undecided until I know for sure or someone else contributes who's been there.

    Thanks for the reply.
  5. Jun 23, 2007 #4


    User Avatar
    Gold Member

    You're more than welcome. Another thing that I forgot to mention is the possibility of joining, or at least contacting, a game-programmers' community. If it's anything like special-effects, or costuming or home-made jet engines, there's probably at least one site out there that's PFish in its eagerness to help novices along. You might end up learning all that you want to without buying anything.
  6. Jun 25, 2007 #5
    I've had a good read through Chris Heckers website and it appears that the differential and integral are used to 'jump' between evaluations for position, velocity, and acceleration.

    I wonder indeed though which quantity must be evaluated first? I would expect the dynamics is used to evaluate forces and thus resultant acceleration, which is then integrated with respect to 'physics-frame-rate' time to find velocity and positional changes.

    Could someone help me and confirm if that last affirmation is indeed correct?

    Thanks :wink:
  7. Jun 25, 2007 #6


    User Avatar
    Gold Member

    I'm outta this one. I don't even know what half of those things mean. :redface:
    Good luck with it, though. :smile:
  8. Jun 25, 2007 #7


    User Avatar
    Gold Member

    I'm not sure about the specifics in doing this with game physics. But given a rate of change, one can integrate to get back to the original. So if you have a function that describes the objects acceleration, you'll integrate it a couple of times to get to the original positional function.
  9. Jun 25, 2007 #8
    Thanks for the replies both of you :wink: Ranger I do now believe that is indeed the case thanks for pointing that out.
  10. Jun 25, 2007 #9
    Yes, this is correct. First you find all the forces, then you convert that to accelerations, then you intergrate to find the velocities, and finally the positions of the objects. Though iirc, the more advanced physics engines work with momentum (and perhaps some other quantity) instead of velocities and accelerations. But I don't remember the details of how or why it is done.

    In any case, the difficult part with a physics engine is exactly how to calculate the forces, and how to intergrate everything, such that the simulation will be stable, but at the same time fast enough and accurate enough. As you may be able to guess, there are different approaches and algorithms, with different performance characteristics.
  11. Jun 25, 2007 #10
    Thanks technobot! That's helped my understanding of it alot :wink:
  12. Jun 26, 2007 #11
    As long as your questions are physics and mathematics related, you probably get good answers here, but check out http://gamedev.net/ for specificly game programming related matters. They have a good discussion forum.
  13. Jun 26, 2007 #12
    Thanks jostpuur :wink:

    I've just been reading through Chris Hecker's articles (his first one) and he introduced a Euler Integrator. He was working with a force equation (the dynamics part I assume) relating velocity to air resistance of a moving body.


    Which when applied to the f=ma equation comes out as:

    ma=-v thus a=-v/m

    so dv/dt=-v/m

    Fine with me. He then plots a velocity plot and states that the dv/dt part of the preceeding equation is used to model the gradient of the velocity plot at any instantaneous point. Followed that bit. He then states that if you go a short distance along the gradient denoted as (the distance) 'h' you have the following formula:

    yn+1=yn + h(dy/dx)

    Which in the force equation evaluated above and thinking of it on the velocity plot:

    vn+1=vn + h(dv/dt)

    Which becomes:

    vn+1=vn + h(-v/m)

    Which gives us the next velocity point on the graph. He states this is an integrator. This I don't follow. How can something which does not evaluate the area under a graph be described as an integrator? I see that it is getting the next velocity point on the graph (well roughly, h puts an error in) but how is it integrating?

    Am I putting the cart before the horse a bit? Is the above formula meant to be used to trace the line of a graph before it exists after being given some initial conditions?

    I have another question which can wait because if I ask it now it will just confuse people replying to this thread.

    Thanks for the help offered so far :wink:
  14. Jun 26, 2007 #13


    User Avatar
    Gold Member

    All he seems to be saying here is that the equation gives you the rate of change of velocity - (dv/dt = acceleration).

    But it seems that he calls this an integrator because it evaluates the velocity at any given point; given that you have the acceleration (-v/m). So you enter an acceleration and out comes the velocity i.e. it is integrating acceleration.
  15. Jun 26, 2007 #14
    Acceleration in, velocity out is indeed an integtrator. I didn't see that before. Thanks ranger :wink:
  16. Jun 26, 2007 #15


    User Avatar
    Homework Helper

    You're correct. Forces are calcuated, then numerical integration is done to determine velocity and position. Don't forget that angular stuff is done as well, such as yaw rate. I'm not sure if torques are calculated, then numerically integrated to give yaw rates and orientation. There's also pitch effects as well (acceleration and braking).

    Slip angle (angle between direction tire is pointed versus direction tire is moving), along with downforce, and tire physics determines pavement force reaction that accelerates the car (in addition to aerodynamic forces).

    Personally, I would just use a canned method for collision modeling. Trying to get it near perfect isn't worth the efforct since accidents should be relatively rare, and would waste CPU bandwidth (unless it's a Nascar simulation with all the crashes). Bouncing or sliding along walls might be important.

    For a source in racing game simulation development, a guy named Todd Wasson has been doing a lot of work in this area. Click on contact on the first link for email address:


    Last edited: Jun 26, 2007
  17. Jun 26, 2007 #16
    Thankyou Jeff that's very kind. I aim ultimately to produce a military simulator. I have now ordered one relevant book to help me although I expect the journey to be a long an arduous one through several different texts.

    I am indeed interested in things such as yaw rate and slip given that the game will include tanks and the like. I wonder if Todd would be prepared to enlighten me on certain issues regarding torque and slip and the like as I would expect racing games to be hot in this area.

    In fact I'll drop him an e-mail now. Thanks again :wink:
  18. Jun 26, 2007 #17
    For those whom are interested here is Chris Hecker's Integrator proof. Whether or not it's absolutely correct I don't know but I think it is.

    Not that dv/dt is given by -v/m and f is taken to be f=-v (air resistance style).

    I plotted in blue the series (Series 1) which uses the equations of motion to accurately predict velocity. I plotted in magenta the copycat profile (Series 2) using the integrator Chris talks about. You can see the slight error difference as the plot progresses but it's only small at that defined value of h.

    Equations of motion plots are bounded in green whilst integrator data is bounded by blue on the sheet. Hope someone finds it useful.

    http://www.savefile.com/files/843884" [Broken]
    Last edited by a moderator: May 2, 2017
  19. Jun 26, 2007 #18
    What educational background do you have?
    IF its highschool/1st year I recommend picking up

    Eric Lengyel's: Mathematics for Game programming to supplement alot of the mathematics you would need aside from that taught in university. It gives you a better picture of how to code the core 3DMATH component of engines.

    But as pertaining to your list: pick up Christof Ericson's Book(realtime...) ...i've browsed through all three and the last two dont' really talk alot about rigid bodies pertaining to code rather than theory.

    Ericson's book is kind of shotty at the beginning(first 2 chapters) because for some reason he starts with Matrices/Determinants rather than vectors....but all the other stuff in his book is way too crucial if your venturing into game dev (or any simulation type application). Things as numerical robustness and geometric robustness are a must and he does a good job on memory stuff ie bit manipulations if you don't already know them. Plus he has an extremely good 3 chapters on bounding boxes and solid geometry queries for physics(though i think they are somewhat outta order) but the material is what you care about. ALso he does quite a bit on Scene management which is crucial to any large N-body simulation even with pseudo physics.

    As for the integrators they themselves are standard in any numerical methods course (if your not in university nr.com numerical recipes nice and simple).
    But if you are...lengyel's book also gives some details but the course text would be just as good...euler/rk4

    also take a look at gamedev.net for their book reviews i believe the ericson book and the eberly book both got 5 stars.

    As for the physics themselves you compute the Forces first(given the systme state) and compute v,x (a is assumed via a=F/m and some code doesn't require that extra value to be passed as you compute v directly)..

    Lucky you stumbled on hecker's work so early...i wish i have them in my first year of university(granted they were written in 4)...

    Crucial to any gamedev 3D engine is the understanding of how meshes are stored for physics-based objects(rigid bodies) so if you can pick up a classical mech book too..
    Last edited: Jun 26, 2007
  20. Jun 27, 2007 #19
    Nice one Neuro thanks for that mate :wink:
  21. Jun 28, 2007 #20


    User Avatar
    Gold Member

    I've been working on a physics engine for the past year and these links have been very useful:
    http://chrishecker.com/Rigid_Body_Dynamics -no need to say more

    http://www.cs.cmu.edu/~baraff/sigcourse/ -A very thorough explanation of the relevant differential equations, rigid body dynamics, and constraints.

    http://www.rowlhouse.co.uk/jiglib/index.html -here you can find some very helpful notes and source code

    http://www.gaffer.org/game-physics/ [Broken] -here're some good articles on physics programming, this page had the simplest explanation of the RK4 integration method.

    http://www.cs.ubc.ca/~rbridson/docs/rigid_bodies.pdf -an amazing paper

    http://www.gphysics.com/ -here's some good source code and articles. He has an interesting approach to solve the collisions called 'Sequential Impulses' instead of the usuall LCP solvers.

    http://www.continuousphysics.com/Bullet/phpBB2/index.php -a great forum with some very helpful articles

    http://wiki.slembcke.net/main/published/Chipmunk -some great code in 2D, it's based of Cattos papers.

    http://www.gamedev.net/reference/list.asp?categoryid=28 [Broken] - some good math and physics articles

    About the books:
    Collision detection is a fascinating field. If you want to implement it on your own then I'd highly reccomend Ericson's book. He explains almost all the crucial aspects of the subject.

    If you want I can send you my physics engine code (2D or 3D). Feel free to send a PM or email if you need help.
    Last edited by a moderator: May 2, 2017
  22. Jun 29, 2007 #21
    Hi mate thanks for that super reply! I'm working through the book by Ian Millington right now. Slow going but I've allowed a couple of years for the physics in the timescale.

    When I can get at the computer for a longer period of time I'll peruse those links. Thanks again :wink:
  23. Jun 30, 2007 #22
    That would by the way be very nice of you indeed. I'd prefer 2D to start with thanks :wink:

    I'm about 100 pages through Game Physics Engine Development by Ian Millington. I've just finished his section on springs. To be honest I'm not following his source code, my C++ isn't up to it yet, despite having read over 450+ pages of C++ novels *sigh*.

    Anyhow he has introduced many new aspects which I never considered. He uses Hooke's law to model buoyancy and uses fixed anchor point springs to model a rope bridge! Very nice. He also goes into a great amount of detail about how stiff springs can be a serious problem.

    He states that the spring constant can be too high and causes the reactions of the springs to be faster than the framerate can deal with and as a result things gain huge quantities of energy out of nowhere and the like. Makes me scratch my head at how mass-aggregate engines work which is what he is actually building in the book? Crackers I think but I suppose that issue is one which falls under the categeory of Constraints and hard limits in games such as non-deformable rods and the like linking mass particles.

    He overcomes stiff springs by faking forces using a damped harmonic motion predictor which gives the spring end's velocity after a certain time period. One then applies the required acceleration (force) to acheive it. It must be used with a damped harmonic formula though or it will again risk overshoot. He also actually kind of recommends not using these in a game as they're too unstable even though he explains them.

    As for what lies ahead I dread to think how rotation is dealt with in mass-aggregate engines but that's all to come. I think several re-reads of the book will help too, although I don't want to dwell too long on it without devoting some time to C++ learning.

    Thanks for the replies so far to everyone :wink:
Share this great discussion with others via Reddit, Google+, Twitter, or Facebook