You could simulate them as spheres, with some special code to make them stick to each other (eg apply force to stop relative motion) to simulate the coarseness of real stones.

Basically if the relative velocity (rotational or translational) is below some threshold, you stop it entirely or apply force to stop it over time.

I would expect this to allow creating walls of stone that stay together but fall down if force is applied.

The problem with your wall is that stacking many things and keeping it stable is a difficult problem physics engines have to handle. If you implement the above and are able to keep most of the stones not moving at all relative to the ground, it might work, but multiple slightly moving stones will need more intelligent handling to "resolve" all the collisions into a stable state (since collisions will probably need to propagate through all stones in the wall for it to be stable, and it is probably also iteration order dependent if you do it in a simple way)

Assuming you already got a physics based integrator working for impulse based simulations and collision of rigid bodies working (if your meshes aren't cuboids or simple shapes e.g. cones, cylinders, spheres, capsules are ok too (cylinders with sphere caps), you need arbitrary convex mesh collision: look at the GJK algorithm. Concave meshes are best avoided if possible), you should look at moments of inertia/inertia tensors which handle rotations of rigid bodies. Friction shoudln't be hard (it's just a threshold applied before motion occurs).

Ellipsoid-trimesh collision is ok (squash space so the ellipsoid is spherical) but ellipsoid-ellipsoid collision involves solving a quartic equation, which is tricky.

Sorry for confusion, the meshes will be visually non-cuboid and slightly irregular, but I will definitely consider them just cubes for physics calculations. So, it's basically down to cube vs cube collisions.

Ok, well cubes and cuboids (i.e. right angles only, but sides can be of different lengths) are good for collision detection so if you have that side of things working you just want to read up on moments of inertia to get rotations around the centres of mass going. The inertia tensor for a cuboid of constant density is simple and you just need to add angular velocity into the mix.

You need to be able to handle multiple cuboid-cuboid collisions though, at arbitrary orientations of course.

EDIT: Here's a video of Blender & Bullet physics collapsing towers made up of cuboids with cannonballs made from spheres.

If this isn't a major feature of your game, you might just want to have a particle effect that is bricks flying apart. It depends on what you're trying to do with your bricks. But I agree that what you're basically wanting is an entire physics engine, and it is not an easy task at all.

If it's not a requirement, I'd look for shortcuts, as this is going to take you down a large rabbithole. Though if you have the time and the tenacity, it will be a good learning experience, even if at the end of it you end up throwing away your code and using someone else's physics engine. =)

(if you're game is 2D, I highly suggest looking into box2d, it's fairly easy to integrate into an existing codebase, and is in several different languages)

The problem with your wall is that stacking many things and keeping it stable is a difficult problem physics engines have to handle. If you implement the above and are able to keep most of the stones not moving at all relative to the ground, it might work, but multiple slightly moving stones will need more intelligent handling to "resolve" all the collisions into a stable state (since collisions will probably need to propagate through all stones in the wall for it to be stable, and it is probably also iteration order dependent if you do it in a simple way)

Well, that might not be a big problem, since I would fire up the physics engine only upon a script trigger. At which point a huge force would be applied that very moment (to break it), so some small inaccuracies should not matter at that point. I am pretty sure all that will require some tweaking (as everything with game programming).

Ok, well cubes and cuboids (i.e. right angles only, but sides can be of different lengths) are good for collision detection so if you have that side of things working you just want to read up on moments of inertia to get rotations around the centres of mass going. The inertia tensor for a cuboid of constant density is simple and you just need to add angular velocity into the mix.

You need to be able to handle multiple cuboid-cuboid collisions though, at arbitrary orientations of course.

EDIT: Here's a video of Blender & Bullet physics collapsing towers made up of cuboids with cannonballs made from spheres.

Interesting video. While I need about an order (or two) of magnitude less cuboids to handle,. I suspect it doesn't really change the implementation complexity, since the physics processing will be done on an array of cuboids - so it's not like simulating 20 cubes is going to be very different than 200, correct ? Apart from performance costs, of course.

Thanks for the terms. I studied the physics in a different language, and my translations didn't really provide me with meaningful search results, but the "inertia tensor" you mention, did finally.

If this isn't a major feature of your game, you might just want to have a particle effect that is bricks flying apart.

Oh, that would not work. The camera is FPS-style and you'd be about 5-10 meters from the wall, so that would look totally out of place these days. Besides, you need to be able to see through the hole / pile of stones, so that's why it has to look as realistic as possible.

But I agree that what you're basically wanting is an entire physics engine, and it is not an easy task at all.

What do you mean by that ? It's just rigid-body physics of static objects (albeit in slight movement). It's not even ragdoll (of characters) or soft-body physics/deformation.

BTW, how much more work would be needed to take that and upgrade it to support ragdoll (on characters) ? 50% ? 200 % ? I always wanted to have ragdoll, but feared the implementation costs. I hope, that once I got the rigid-body physics implemented, the ragdoll should be doable...

If it's not a requirement, I'd look for shortcuts, as this is going to take you down a large rabbithole. Though if you have the time and the tenacity, it will be a good learning experience, even if at the end of it you end up throwing away your code and using someone else's physics engine. =)

(if you're game is 2D, I highly suggest looking into box2d, it's fairly easy to integrate into an existing codebase, and is in several different languages)

I do have the time. Tenacity is something I unfortunately cannot avoid, so I'll just go with the flow...

I'm returning to my engine/game work (after a short break) and suspect to work on it for next 4-5 months during evenings.I've been postponing the physics in my engine for many years and the time has come to revisit that particular shortcoming.

I am pretty sure I will not just use someone else's physics library. If I was willing to do that, why not just jump straight to Unity ? But I'm a SW engineer, not a gui-clicker.

(if you're game is 2D, I highly suggest looking into box2d, it's fairly easy to integrate into an existing codebase, and is in several different languages)

Not sure if you're familiar with the grid dungeons, but I'm working on something similar to Legend of Grimrock. Tight dungeons, walls very close to you, high-res textures and plenty shader effects. Physics is probably the No 1 thing missing there right now.

I think I found a fantastic studying material:

http://chrishecker.com/Rigid_body_dynamics

If you guys know of some other similar tutorial series, don't hesitate and share the link.

Thanks !

For ragdolls you need to define joints (various different types e.g. hinge, socket) and put constraints on the angles.

"Physics For Game Developers" is probably a book you should read.