How to create a physics engine

Note: I'm going to assume this is about implementing a 3D physics engine.

Additional disclaimer: I've never actually written a 3D physics engine, so I'm just summing up where I'd start off if I were to try and implement one. I have done 2D physics engines though.

First of all: Welcome to the forum!

Let's get down to business.

Is this going to be a physics engine you're actually going to use in a game, or is this a personal educational project?

If it's the first case I'd recommend against writing your own physics engine as there are a ton of excellent professional physics solutions available for use without cost. Examples of these would be Bullet or Nvidia Physx. Havok would also be an option as they have licensing options for low cost and low budget games.

If this is an educational project there are a couple of places where you could start, and I hope I can explain somewhat why it might not be the best idea to write a fully featured physics engine for a project you want to actually release. Full featured physics engines are massive projects which require quite a bit of expertise.

First of all you'll want to have a good grasp of at least classical mechanics and how the concepts found in classical mechanics would translate to actual real-time simulations (warning: this can be tricky). Maybe you should try to get your hands on some introductory textbooks on mechanics and study those until you grasp the concepts explained within to start out.

Second, you're going to have to make some decisions on what you want your physics engine to be able to do and what you'll want to use it for. Do you just require basic rigid body physics or do you want to implement some more advanced stuff like soft body physics as well? Do you want it to be able to hande massive amounts of varying bodies flying around everywhere? Do you want to support just simple shapes like boxes, spheres, etc. or do you want to support more complex bodies (meshes?) or even multiple constrained bodies (eg. ragdolls, hinged bodies, ball joints, pistons, etc)? Do you want to implement destruction like bodies being able to break or shatter? Try to write up a list of things you want to implement into this engine first before doing anything else.

Once you've taken these steps you'll probably have an idea of how to start out with writing something very primitive like moving a box around by applying a force on it for example.

From here on out you'll probably want some interaction between your entities, so you'll have to look into collision detection algorithms and methods of applying these algorithms as efficient as possible (read: acceleration structures).

When you've reached this point you'll probably want to come back and ask more specific questions about the features you'd like to implement (if you haven't figured out how to implement them on your own by then). As I said before, physics engines are massive projects so I couldn't sum up the process of implementing one in one forum posts (nor do I know any tutorials or books, sorry).

To be honest with you, even though I've been tempted to write one on some occasions I've personally always been quite intimidated by physics engines, even with a pretty good knowledge of the fundamental aspects of classical mechanics.

Oh and by the way, your choice of graphics API (OpenGL, DirectX) doesn't really have anything to do with physics engines unless you plan on using your GPU to do some of the heavy lifting.

First of all: Welcome to the forum!

Thanks

If it's the first case I'd recommend against writing your own physics engine as there are a ton of excellent professional physics solutions available for use without cost. Examples of these would be Bullet or Nvidia Physx. Havok would also be an option as they have licensing options for low cost and low budget games.

Well, it is the first case, and kinda the second. But, I would like to do it anyway.

Oh and by the way, your choice of graphics API (OpenGL, DirectX) doesn't really have anything to do with physics engines unless you plan on using your GPU to do some of the heavy lifting.

Ok, just wanted to make sure I gave all of the information I needed to.

Thanks for all of that help. That had to take you a long time to type that up.

EDIT: +1 for your answer! :D

You'll have to decide for yourself whether it's actually the game you care about or the technology behind it. Be aware that writing a physics engine of your own will take a lot longer than just a couple of months, especially if you don't have any background knowledge yet.

If you're actually set on building and releasing a game in the next couple of years you'd be much better off using a proven physics engine.

Writing a solid physics engine can take quite a bit of time. What you gain, well for your first one, probably very slow physics engine that no one is going to use in real projects. If you come with something interesting though (very easy and good interface), people might start to use it and you may need to refactor and improve the code.
 
I've actually written few physics engines in my life. Both 2D and 3D, basically the math is very similar ... my first one was really bad, checking sphere vs mesh (1k triangles) took like 70 millis on Pentium D at the time (ofc I haven't dreamed about multicore back then, even when I had one of the first ones) - yup, epic fail. Then I started reading a ton of stuff about optimization, getting the code faster, several times totally refactor (e.g. rewrite) most of the code.
 
Anyways for purpose of learning, go for it. It will learn you a ton of stuff. For purpose of creating good physics engine, it will take years if you don't know the "math". If you know the math, it will still take some time, but magnitudes less.

EDIT: Finally got to finish my answer...

I presume you have some knowledge of math (vectors, matrices, etc.). Now, most physics engines are composed of two main parts - the part that handles collision detection and the part that handles collision reaction.

As for the first part, even though most cases are simple to think about and solve (or derive), it is actually a bit more complicated. Imagine you have support for 2 primitives - Sphere and Triangle. You have to have test for Sphere vs Triangle - that works, but when they start moving, it starts to become problematic. So you have to have Moving Sphere vs. Moving Triangle (for performance reasons you might also consider implementing Moving Sphere vs Triangle and Sphere vs Moving Triangle) ... note you most likely need to know exact point in the time and space where the collision occurs, not some state where they're in each other.

The next main part is collision reaction, based upon information you gathered in the previous part, you can change speed and direction of primitives. This one needs a bit of physics, and joints make it a bit more complicated. Not even mention harder concepts like fluids.

If you want to start building physics engine, start small - preferably with 2D one, report us progress and some of us can point you in good direction. If it will be enough good with good interfaces and fast, people here might consider using it or contributing into it.

As some said, I'd strongly advise against it, yada, yada, yada.

But now that I think of how to implement a physics engine, let's say 2D, the first thing you should do would be to define your problem.

What does your engine needs to handle? Will you need only simple Gravity and small collision and friction systems, that can only handle circular or rectangular bodies and no rotation? (something like a super mario clone)

Or will you need rigid body physics with entities composite by one or more concave polygons, restitution, friction, continuous contact resolution, etc.

When you know exactly what you'll need, you'll be able to start something. But starting without a definite objective (or at least a good idea) will get you off with the wrong foot.

Maybe this forum will be helpful: http://www.gamedev.net/forum/20-math-and-physics/

I recommend the books Real-Time Collision Detection by Christer Ericson and Game Physics Engine Development by Ian Millington.


L. Spiro

If you want to make a physic engine, that may be used in a real project, you should hardware accelerate your physic engine for the GPU, by OpenCL or just by OpenGL shaders( a lot harder though, and more hackish...). That's what makes PhysX and Havoks performance so good.

As people have pointed out, the method and algorithm used in a physic engine is common across the engines. And as L. Spiro said, Real-Time Collision Detection and Game Physics Engine Development are very good books(I have both). So it is up to you, how you gonna implement the engine, however you should have a decent understanding of geometry and physic laws, that you may recall from high-school. Another thing, it takes time to create a physic engine, so it should only be made for learning purposes or as part of your CV.

Game Physics Engine Development by Ian Millington.

I had already gotten this book.

Thanks for the ones who actually answered.

No thanks to the ones who were trying to discourage me. :P :P

No thanks to the ones who were trying to discourage me.

Nobody here is trying to bring you down or anything, we're just trying to give you a realistic picture of what writing a physics engine is about. It's just a fact that if it's your goal to build a game anytime soon it's not a good idea to spend years trying to build a physics engine from scratch first, it's as simple as that.

you should hardware accelerate your physic engine for the GPU, by OpenCL or just by OpenGL shaders( a lot harder though, and more hackish...). That's what makes PhysX and Havoks performance so good.

Not at all, Bullet's GPU solver is not yet in release.

No thanks to the ones who were trying to discourage save me from wasting my time, effort and energy

Corrected that for you. I wish you good luck, you're going to need it.

Not at all, Bullet's GPU solver is not yet in release.

Did i mention Bullets? Even if i am wrong with Havok, since it has limited GPU support, however are going to have full on next-gen consoles.

Hmm, poorly expressed by me. What i mean is that AAA physic engines are moving towards GPU acceleration, which is state of the art. With the next-gen consoles, we would see that CPU based physics engine are being slowly thrown away, in favor of GPU based. Why create a CPU based physic engine, when we are missing a good and open-source GPU based physic engine, that are platform independent. Not that he is going to create a open-source engine, but you see what i mean. The question is what's the goal. Do you want to create an useful engine and push the market, or are you going to create an engine just for education(where parallel programming is a good start though).

You could start with making a physics engine that can deal with forces but not collisions to start with. Basically add the ability to apply forces and torque on objects (eg. apply some force on some point on object) and have them move accordingly. This will already give you something usable, you could for example make collision simply range based and make a small game (some sort of an object avoidance game?)

You might want to look into using an integrator to reduce error at that point.

Then you need to add the collision detection & reaction part. Detection means pretty much finding all the collisions present (this is where you need to do a lot of optimization) and then figuring out how all the forces balance out so your stack of boxes doesnt explode.

No thanks to the ones who were trying to discourage save me from wasting my time, effort and energy

Ok, sorry for taking it that far. I understand what they meant. They were trying to save me from wasting my time, etc.. Which, I thank them for that, but if someone started a thread on it, they probably want to learn how to do it, not to be told that is wasting my time. This is something that I really want to do. So maybe I was wrong, and I apologize for that. This is it fixed

No thanks to the ones who were trying to discourage save me from wasting my time, effort and energy