Making an Informed Decision on Physics Engines for Games

In summary: He attributes this to the air resistance and discusses how to correct for it. So this seems to be the dynamics part of the equation.Yes, the dynamics part is to correct for air resistance.
  • #1
Adder_Noir
239
0
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 physics 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:
 
Physics news on Phys.org
  • #2
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.
 
  • #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.
 
  • #4
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.
 
  • #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:
 
  • #6
I'm outta this one. I don't even know what half of those things mean. :redface:
Good luck with it, though. :smile:
 
  • #7
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.
 
  • #8
Thanks for the replies both of you :wink: Ranger I do now believe that is indeed the case thanks for pointing that out.
 
  • #9
Adder_Noir said:
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.
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.
 
  • #10
Thanks technobot! That's helped my understanding of it a lot :wink:
 
  • #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.
 
  • #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.

f=-v

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:
 
  • #13
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:

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.
 
  • #14
Acceleration in, velocity out is indeed an integtrator. I didn't see that before. Thanks ranger :wink:
 
  • #15
Adder_Noir said:
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.
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:

http://www.performancesimulations.com

http://www.virtualrc.com
 
Last edited:
  • #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:
 
  • #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:
  • #18
What educational background do you have?
IF its high school/1st year I recommend picking up

Eric Lengyel's: Mathematics for Game programming to supplement a lot 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 a lot 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:
  • #19
Nice one Neuro thanks for that mate :wink:
 
  • #20
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:
  • #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:
 
  • #22
daniel_i_l said:
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.

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 achieve 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:
 

1. What is a physics engine for games?

A physics engine for games is a software component that simulates physical interactions between objects in a game environment. It calculates the movement, collisions, and interactions of objects based on real-world physics principles.

2. Why is choosing the right physics engine important for game development?

Choosing the right physics engine is important because it can greatly impact the realism and overall gameplay experience of a game. A good physics engine can also save time and resources for developers by providing pre-built tools and features for handling physics.

3. What factors should be considered when selecting a physics engine for a game?

Some important factors to consider when selecting a physics engine for a game include the type of game and its specific physics requirements, the level of realism desired, the target platform and hardware limitations, the availability of support and documentation, and the cost and licensing options.

4. Are there different types of physics engines for different types of games?

Yes, there are different types of physics engines that are designed for specific types of games. For example, some engines are optimized for 2D games, while others are better suited for 3D games. There are also physics engines that specialize in certain types of physics, such as fluid dynamics or ragdoll physics.

5. Can a game use more than one physics engine?

Yes, it is possible for a game to use more than one physics engine. This is often done to handle different types of physics interactions or to achieve a desired level of realism. However, using multiple physics engines can also add complexity and may require more resources from the game's development team.

Similar threads

  • Programming and Computer Science
Replies
9
Views
1K
  • Quantum Interpretations and Foundations
Replies
2
Views
648
Replies
9
Views
890
Replies
2
Views
794
  • STEM Academic Advising
Replies
11
Views
2K
  • STEM Educators and Teaching
Replies
3
Views
3K
  • STEM Academic Advising
Replies
24
Views
2K
  • Thermodynamics
Replies
13
Views
2K
  • Science Fiction and Fantasy Media
Replies
2
Views
1K
Back
Top