• Create Account

Banner advertising on our site currently available from just \$5!

# Breaking a wall of stones

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

22 replies to this topic

### #1VladR  Members   -  Reputation: 722

Like
0Likes
Like

Posted 22 November 2013 - 10:23 AM

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 ?

VladR    My 3rd person action RPG on GreenLight:    http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

### #2ShadowFlar3  Members   -  Reputation: 1258

Like
1Likes
Like

Posted 22 November 2013 - 10:44 AM

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.

Edited by ShadowFlar3, 22 November 2013 - 10:44 AM.

### #3Paradigm Shifter  Crossbones+   -  Reputation: 5556

Like
1Likes
Like

Posted 22 November 2013 - 10:47 AM

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.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

### #4VladR  Members   -  Reputation: 722

Like
0Likes
Like

Posted 22 November 2013 - 11:06 AM

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.

VladR    My 3rd person action RPG on GreenLight:    http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

### #5Paradigm Shifter  Crossbones+   -  Reputation: 5556

Like
0Likes
Like

Posted 22 November 2013 - 11:14 AM

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.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

### #6VladR  Members   -  Reputation: 722

Like
0Likes
Like

Posted 22 November 2013 - 11:14 AM

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 ?

VladR    My 3rd person action RPG on GreenLight:    http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

### #7Paradigm Shifter  Crossbones+   -  Reputation: 5556

Like
2Likes
Like

Posted 22 November 2013 - 11:18 AM

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.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

### #8VladR  Members   -  Reputation: 722

Like
0Likes
Like

Posted 22 November 2013 - 11:20 AM

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

VladR    My 3rd person action RPG on GreenLight:    http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

### #9Paradigm Shifter  Crossbones+   -  Reputation: 5556

Like
2Likes
Like

Posted 22 November 2013 - 11:22 AM

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.

Edited by Paradigm Shifter, 22 November 2013 - 11:35 AM.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

### #10VladR  Members   -  Reputation: 722

Like
0Likes
Like

Posted 22 November 2013 - 11:54 AM

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.

VladR    My 3rd person action RPG on GreenLight:    http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

### #11Waterlimon  Crossbones+   -  Reputation: 3089

Like
0Likes
Like

Posted 22 November 2013 - 12:03 PM

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)

o3o

### #12Paradigm Shifter  Crossbones+   -  Reputation: 5556

Like
0Likes
Like

Posted 22 November 2013 - 12:04 PM

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.

Edited by Paradigm Shifter, 22 November 2013 - 12:11 PM.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

### #13VladR  Members   -  Reputation: 722

Like
0Likes
Like

Posted 22 November 2013 - 12:59 PM

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.

VladR    My 3rd person action RPG on GreenLight:    http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

### #14Paradigm Shifter  Crossbones+   -  Reputation: 5556

Like
0Likes
Like

Posted 22 November 2013 - 01:07 PM

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.

Edited by Paradigm Shifter, 22 November 2013 - 01:15 PM.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

### #15ferrous  Members   -  Reputation: 2715

Like
1Likes
Like

Posted 22 November 2013 - 02:31 PM

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)

Edited by ferrous, 22 November 2013 - 02:33 PM.

### #16VladR  Members   -  Reputation: 722

Like
0Likes
Like

Posted 23 November 2013 - 10:03 AM

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).

VladR    My 3rd person action RPG on GreenLight:    http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

### #17VladR  Members   -  Reputation: 722

Like
0Likes
Like

Posted 23 November 2013 - 10:14 AM

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.

VladR    My 3rd person action RPG on GreenLight:    http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

### #18VladR  Members   -  Reputation: 722

Like
0Likes
Like

Posted 23 November 2013 - 10:35 AM

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.

VladR    My 3rd person action RPG on GreenLight:    http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

### #19VladR  Members   -  Reputation: 722

Like
0Likes
Like

Posted 23 November 2013 - 10:55 AM

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 !

VladR    My 3rd person action RPG on GreenLight:    http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

### #20Paradigm Shifter  Crossbones+   -  Reputation: 5556

Like
0Likes
Like

Posted 23 November 2013 - 10:56 AM

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.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS