I want to add a bit of physics into my engine / games. I most certainly will not use any external library, and want to code it from scratch.

I expect a lot of code to be refactored progressively, and that's fine. The thing is, I have to avoid reading 5 books and 20 articles to extract just those few important bits and pieces of them. This is not a complex ragdoll physics.

Desired characteristics:

1. All I need is to be able to break the wall of stones (say, 20-30 big stones) and have them react realistically, depending on the force exerted.

2. Perhaps only 1 stone will fall out (and others will move a bit - kinda lean along the vector of the force), with the quadratic falloff based on distance from the center.

3. When you exert more force, more stones will fall out and when they collide, they should definitely react realistically - e.g. behave differently depending whether they fall on edge or a side.

4. My understanding is that I need to account for a friction, since if they just slid smoothly over one another, that would break the realism

5. Stones need to pile up

6. Stones will be aware of the gravity, so if enough of the stone is sticking out (without the support of the stone below and above), it will tip over itself and fall down.

So, how would I go about it and where would I start ? I remember having a physics subject at high school where we used to calculate all kinds of examples with heavy stones/friction/falling - but it was all just a single stone.

I'm not really looking for code examples, more like articles with game environment in mind.

Theoretically, it does not sound like a lot of work - perhaps 50-100 hrs would be my early guess ?

My early outline of things to experiment with:

1. Start with stone simply falling down (accounting for gravitation) and stopping when it hits floor.

2. Get two stones to react - when one falls on top of another - and let it react appropriatelly (either stay on top of it, or tip over and continue falling till it reaches floor)

3. Self-aware stones in the wall, sticking out a bit that will tip over based on how much they stick out.

Any specific ideas ?

From the looks of it you're going to need all the key components of full fledged physics engine: collision checking, forces, friction etc. I read you are trying to indicate it doesn't need to be that fancy but on the other hand if you want "realistic" results you're going to have to start by implementing the very same rules you studied in high school. Objects have masses and force impacts give them acceleration. Take it from there (after you've got collisions figured out) rather than dealing with situations such as falling brick.

Never programmed one myself so I can't comment on your estimation of hours. But I would say it is a lot of work and getting good collision checking system for example can take a lot of time either by trial and error or research on existing examples. Using uniform shape physics colliders might ease on handling the many situations a bit, though. But note that even if you use the system for couple of bricks instead of physics being the entire point of the game you're still going to need the physics calculation with all the features if you don't want to simulate the objects in an external software and bake it into a fixed animation. When you get the features working it doesn't matter how much you use it Using the system modestly could mainly save you only some optimizing / scalability time.

I agree use a physics engine, it's just rigid body physics which is quite complicated to do efficiently. It's going to be best if your pebbles are nice regular shapes like cuboids though; collision detection will become inefficient for arbitrary shapes especially if they are non convex.

From the looks of it you're going to need all the key components of full fledged physics engine: collision checking, forces, friction etc. I read you are trying to indicate it doesn't need to be that fancy but on the other hand if you want "realistic" results you're going to have to start by implementing the very same rules you studied in high school. Objects have masses and force impacts give them acceleration. Take it from there (after you've got collisions figured out) rather than dealing with situations such as falling brick.

Never programmed one myself so I can't comment on your estimation of hours. But I would say it is a lot of work and getting good collision checking system for example can take a lot of time either by trial and error or research on existing examples. Using uniform shape physics colliders might ease on handling the many situations a bit, though. But note that even if you use the system for couple of bricks instead of physics being the entire point of the game you're still going to need the physics calculation with all the features if you don't want to simulate the objects in an external software and bake it into a fixed animation. When you get the features working it doesn't matter how much you use it Using the system modestly could mainly save you only some optimizing / scalability time

Well, the physics for sure won't be entire point of the game (e.g. it's not a physics-based game). The physics there is there merely to add immersion and few effects.

I'm not really worried about the performance costs, since the CPUs these days have plenty of cores and MHz. Besides, there can't be that many calculations involved that would actually even remotely slow down the game. I remember those friction equations remotely, and those are very simple formulas.

It is true, that I thought about doing it the same way as Doom3 had - e.g. just precalculate the whole physics scene as an animation (e.g. just store the matrices for each frame of the animation) and then just interpolate at run-time.

This would have the added benefit that I could tweak the parameters here and there for added effect and there would be no unexpected bugs at runtime (e.g. because of the slow framerate or anything else).

Meaning - it would be, sort-of, a cutscene, but you would not have to really stand still, you could just go away (well, you probably would, since it would be a monster breaking its way through the wall).

I do have a lot of collision-detection routines in my engine, though I might have to code one or two for the purposes of physics, which is all good and expected.

If you are doing a cutscene style thing you can just bake a physics simulation into an animation and play that back, I know you can do that in 3DS Max I assume Maya and Blender can do it too.

I agree use a physics engine, it's just rigid body physics which is quite complicated to do efficiently. It's going to be best if your pebbles are nice regular shapes like cuboids though; collision detection will become inefficient for arbitrary shapes especially if they are non convex.

While the stones themselves won't be a perfect 6-side box with 12 polygons visually, they will be 12 triangles for the physics purpose.

Visually, the mesh of each cube will have anywhere between 250-500 triangles, since I want to have a reasonably detailed stone mesh (a normal map can go only so far) with visible curvature and edges / holes chipped off. I don't think it's important to calculate properly the chipped-off corners (for the physics purposes) though. No one would notice that anyway.

As for the external physics engine - uhm, no. It's not going to take me 2 hrs with another engine anyway. This way, I'll have the basic physics support integrated in my engine. I can devote a week or two for the implementation, assuming I have all the necessary articles in the queue.

So, any rigid-body articles you can recommend that cover all of the above requirements ?

It's a lot of work to do efficiently you need to do moments of inertia and multiple rigid body collisions. If you were to do it yourself take a look at open source implementations (ogre? bullet?) first to get an idea of the complexity.

Bake it from a 3D modelling package if you only want canned animations.

If you are doing a cutscene style thing you can just bake a physics simulation into an animation and play that back, I know you can do that in 3DS Max I assume Maya and Blender can do it too.

Yes, I am aware of that possibility, but that's cheating

Besides, later I would like to introduce some other scripting events - say a stone falling off the platform and breaking into few bigger pieces upon collision (pieces already modelled in the 3d mesh, obviously), or a stone sliding down the platform and starting to rotate. That would be a nightmare to keep importing from Max back and forth and tweaking it.

I suspect, but I could be really wrong about it, that tweaking it inside engine or via script, is going to be less work than keep export/import-ing it from 3dsmax.

Plus, and that's kinda important, I like to keep the dependency on an artist minimal. Saves time, money and stress

Well as I said look at open source implementations first and prepare yourself for a lot of work and debugging. EDIT: A week or two is a massive underestimation.

Well as I said look at open source implementations first and prepare yourself for a lot of work and debugging. EDIT: A week or two is a massive underestimation.

OK, that's entirely possible that I underestimated something I never worked on

Let's say, I'll leave the interaction of multiple rigid bodies (e.g. breaking the wall into pieces that pile up nicely) for last and just go for the low-hanging fruits (the single / two rigid body physics - e.g. simple fall, friction and tipping over&falling).

Does that too seem like an overkill for 2 weeks of work ?

Also, I'd appreciate some links to proven papers/tutorials on this subject.