What to study in prep for writing a physics engine?
Posted 16 June 2011 - 02:01 PM
I suspect that there have been new developments since the article was put together, which brings us to the reason for this post: Do you guys have any additions/changes to the list he gives? For example, changing the order in which a topic is studied, a new and better book for a particular topic in the list, new topics to add to the study list (with accompanying book recommendations if you can), etc.
I like the fact that he discusses each set of books and the pros/cons. If you guys could provide similar notes with your recommendations, as well as when I should study that topic (right after reading the Calculus book? After reading everything else in that list?) and what I will be able to do in my physics engine after I study it (like his "milestones"), it would really help :) Thanks
Posted 16 June 2011 - 03:43 PM
- Hecker doesn't handle friction iirc, the Coulomb friction model is popular.
- Stacking objects is a nasty problem, I've read and used the ideas from the famous "nonconvex rigid bodies with stacking" paper for my own engine. I recently read a series of articles how Angry Birds (might) work, it discussed the physics as well but I didn't read it, so I don't know if it is interesting: http://www.wildbunny...y-birds-part-1/ that guy has more physics stuff on his page iirc.
- Box2d has tech info which was presented at some (?) conference.
- I think that it isn't wrong to start in 2D and get an idea of how complex physics engines can be before you advance to 3D.
Posted 20 June 2011 - 07:50 PM
Uhm, all of Newtonian (classical) mechanics?
Posted 20 June 2011 - 07:56 PM
Posted 20 June 2011 - 08:02 PM
Posted 20 June 2011 - 08:06 PM
Posted 30 August 2012 - 02:07 AM
The way I see it, physics is just a set of interaction rules for various actors involved. Just like ticket reservation system.
Learn the rules, when you see a box tumble down a slope, it shouldn't look magical. If you can garner exactly whats at play, you can apply the rules in programming.
Now the trick with game physics: it bends the rules slightly, some will skip details, simplify a model, reduce the number of variables.
Using finite element/slice methods - in this you simulate a few set if equations over a finite body for a finite duration of time (cycletime).
Physics engines wouldnt be realtime if they really simulated reality.
Read kinematics and rigid body mechanics in 'Fundamentals of Physics - Resnick and Haliday'.
Try to solve a problem or two from 'Problems in Physics - Irodov'
Then comes the programming.
There is always a debate - go procedural / object oriented , have inheritance hierarchies / composites.
In the end you'd really have to be a good programmer - no alternatives.
Master double dispatch and visitor pattern for c++/java, or take to dynamic languages like Ruby.
Posted 16 February 2013 - 05:53 AM
While knowing the rules of physics is obviously important, it's not enough.
Numerical stability is very important to achieving realistic results. This stems from the fact that you tick your physics engine at discrete time intervals.
To solve this you must understand how Integration works, this is the best article I've seen on the internet:
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users