# Destructible Enviroments [closed]

I've got my own game engine, now rendering and animating, MD2 MD3 and MD5 models now. I feel i am only just starting to get comfortable with opengl.

I'm currently writing code to render Quake 3 maps now too but, i would love to know how games like red faction allowed for destructible environments. Not quite sure, where to start with this. If i render a map do i have to turn the map into constitute components where by a physics engine controls every brick in the map or something maybe someone could tell me where i should look or read would be great. Thanks.

• possible duplicate of How'd they do it: Destructible environments in BF:BC2 and BF3 – concept3d Jan 22 '14 at 10:55
• I remember reading somewhere that the first Red Faction did not actually destroy environment, but instead it placed "holes" as actual objects into the map, which was also the reason why there was a relatively low limit to how much you could deform the terrain in any given area. I don't have any sources though, so I don't know if that's really true or if I'm misremembering. Also, I don't think it's the right approach nowadays. I guess you first have to decide what you want to destroy, i.e. only objects, or the actual terrain, and then look for a way to do each. – Christian Jan 22 '14 at 11:35
• I notice it's not mentioned in the answers -- I think Worms 3D used "voxels" to do this, with mesh deformation. It's something you can look into. – ashes999 Jan 22 '14 at 15:37

This is a wery Advanced and complex subject, But there is (Luckily) some resource on how to achive this. I cant say with a straight arm which one is the best. My best suggestion for you is to read some article about it and later try something out, see if it works and if you can get it in a manageable state.

And the best idea on how i would do it is to have a geometry shader spliting a specific mesh and restiching it after it's been destroyed. This of course comes with bad memory consumptions since you are probably going to need a copy of the orginal mesh and then a second one for each destruted object. But there is always stuff to improve.

And here are the good links :
DICE This is basicly how my idea also would be. DICE DESTRUCTION
A Good read on a White paper : White paper

There are many many ways of doing this in games and simulations in general. No one technique will ever be the best as they all have their place.

In general, destructible material goes along with the subject of soft body simulation.

I will assume from here that you have some form of rigid body physics engine which can detect collisions and resolve forces.

## Precomputed Fractures

Take a mesh and slice it up into nice pieces before even running the game. Connect them with joints in your physics engine and split those joints dynamically based on the item used to fracture the object.

Don't use the joined mesh until you have to. Use the un-fractured version until it's hit with a certain impact/weapon then quickly swap the models, break the joints and let the physics engine take over.

This gives you great control over what can break and how it can break. Truly dynamic fracturing could cause unexpected results and in certain circumstances prevent the game from continuing. Imagine if a pillar broke only just enough to block the exit and the player had no more rockets.

To give it the appearance of being dynamic simply use a mix bag of variants. The physics engine will make the pieces move nicely based on impact point and weapon used anyway.

## Material Point Method

You can fill your object with a cloud of particles and then augment your mesh based on how these particles move internally. This is often used in soft body or fluid simulations and allows for things to bend, dent, melt etc.

The particles should be bonded together and, when appropriate, these bonds should be broken. When they are the mesh should be split between these bonds.

The way in which things break can be defined through the bonds being used between the particles. Tougher materials like metal can have stronger bonds. Also, you can use different bond definitions with the same object to have it act differently based on the material it's supposed to be made of.

This is an all-round technique, but it's especially good for natural soft things like organic materials. The main issue is the computational load it adds resolving all those particles.

## Voronoi

Voronoi fracturing is probably the one I like best. This is simply a technique for splitting the mesh in an interesting way.

It looks nice for structural environments and seems fairly straight forward. This technique will help define fracture lines alone which new polys should be added to the mesh.

The advantage to the example in the link is the decomposition into convex shapes. Convex shapes are required for some physics systems, especially those based on the separation of axis theorem.

## Finite Element Method

FEM is basically about breaking the problem down into small pieces. In this way the particle method above falls into this category, and is considered an "FEM based particle method".

Commonly in FEM the object is represented by a simplified triangular mesh cage which is used as a deformer for the main object mesh. The triangles are dealt with in a fairly individual way to determine how forces work upon them before working out how they impart force onto adjacent triangles.

One difficult part here is how you describe the material used in each triangle. This will determine how the triangle responds to various forces/effects and can make the difference between the simulation seeming real and looking terrible.

This method you will find all over the place and is used in high detail for modelling complex simulations for use in engineering. A common example is modelling how an impact affects a car and those inside it, so various designs can be tested before a working prototype is put through crash testing.

This is mostly a technique for breaking your problem down into managable sets and it's expandable to simulate many physical phenomenon, such as heat transfer or fluid movement. You should be able to find many articles, and probably sample code, around the place, but here is a place to start.

## Conclusion

This is a massive topic and will require a lot of research before picking the method you like for your purpose. My main advice is to remember that we are making games, not simulation software, so whichever method you use in the end, make sure it looks good, plays well, remains stable/bug free and, above all, is really good fun.

I'm doing something similar.

What I'v done until now is to have

• a procedurally generated terrain
• a structure of the world which could fit my needs (a 3d matrix or an octree)
• function to modify the base structure (i.e. a dig() function which for example removes a quantum of cells from the world structure)

If you never dealt with procedural generation of terrain, you should indeed read some arcticle, because it is a very broad subject. You should choose algorithms depending on your needs of preformance/precision/speed/etc. Basically you have to choose an algorithm for pseudo randomly generate the structure and then another one to render it.

I will link you something I found of interest which could help you out as I have a little more time to re-arrange things. By the while you could start reading something more generic about procedural geenration of terrain. Then I will link documentation I refered to about Perlin/Simplex noyse algorithms for pseudo random generation and Marching Cubes and Marching Tetrahedra algorithm for rendering (for which you could start looking by yourself)