In the new release of Battlefield Bad Company and other games, they have destructible environments. I am assuming these engines are using the geometry shader to process how and where the model splits, and creating new geometry from that. my question is, how does the engine get the "new model" back from the shader pipeline to know that this model is to be rendered "destroyed". thanks in advance

See what i was thinking, on a very simple level, would be a building, with 4 walls. each wall is a seperate object. then in its place, would be a "destroyed" wall version. maybe a piece missing, etc...

in the level management system, it would hot swap objects to show the destroyed wall object.

This would work, but it doesn't show realism, as i could hit the wall on the right side, and the hole might be shown on the left side. This approach is similar to what was in zelda games, where if you close to the "destoryed" spot, it would blow the hole in the object.

Quote:Original post by Orbital Fan
Red Faction (1 and 2) use a fancier system with CSG subtraction.

And Red Faction: Guerrilla uses a much fancier (and commensurately more complex) stress simulation to handle destruction.

I'll just ramble on for a bit, if you don't mind. ;)

Destruction in games is often done with a technique commonly referred to as "pre-fracture." This is roughly what is described in this thread, prior to my message. I like the way Orbital Fan described it best, "Fault Lines" in the geometry, pre-processed either by an artist who creates/crafts them to look good and possibly using some tools to somewhat automate the pre-processing work. By the time the game is shipped, all the fault lines are baked into the art, but at runtime the models can break in various ways. Here is how. The different pieces are put together as rigid body pieces glued together with 6 degree-of-freedom joints that have force limits. Depending on where the model is impacted, different joints exceed their respective force limits and break the rigid bodies apart in potentially different places each time the level is played.

So, apart from pre-fracture, there is the possibility of using something like finite element analysis (a traditional engineering technique used to design things like vehicles, engines, etc. in real life) to determine the geometry fracture at runtime. The promise of this is that you get more realistic fracture and more variation from session to session. But, in reality, I haven't seen this promise truly fulfilled so far. Finite element analysis requires that a model be volumetrically meshed, creating, for example, tetrahedron elements instead of just surface triangles. This meshing is expensive. So, I expect any use of finite element analysis in games would pre-process the volumetric mesh, at least up to this point in time. Then there is the issue of where to fracture the volumetric geometry. Some of the published literature talks about splitting the tetrahedrons at runtime, allowing for infinite options for fracture lines, but tetrahedron splitting too is expensive. So, currently it may be more likely that splits are done at the pre-processed tetrahedron boundaries. So, this sort of no-split-tetrahedron, finite-element-style fracture is essentially....you guessed it, pre-fracture. You do get some benefits. I like this approach quite a bit. You have a more realistic deformable material model, so can represent materials that are somewhat plastic/pliable/deformable and aren't perfectly brittle (the rigid body/art-directed pre-fracture mentioned above is mostly optimized for brittle materials like ceramics). You also have a more formal representation of the interface stresses between tetrahedron elements while the rigid body/joint approach tends to be based on overall joint forces and maybe not in the principal stress directions...so, getting the fracture to work...the code with the rigid body approach is less formal, more...I'll just say it...hacky. That is my view.

I've seen games that use both approaches. I have seen demos that convinced me that the latter approach is capable of producing some very nice results, but the games I've seen using the latter approach...not particularly compelling. The commercial physics engines out there that provide destruction based on art-directed pre-fracture and breakable joints are extremely capable. And from what I've seen so far look every bit as good as the scientifically fancier techniques. No offense intended to those companies and people working on the fancier techniques. I love them, studied them when I was an engineering student, and believe in them. I just don't think they have shown their potential in real games yet, while the engines that support pre-fracture have really stepped up to hold their own.

There are some games/game engines that seem to be doing geometry splitting on the fly. (I'm thinking of Red Faction Guerrilla with the latest geomod engine, for example.) And there is very likely some research and development work going on, maybe even released or ready to release, that I'm not aware of yet, that takes it to the next level. Will be exciting to see where we go from here.

As for doing model swaps, this certainly happens, now as it did in the past. No need to have a full, fancy pre-processed model with geometry splits and multiple rigid bodies if you don't need it. So, use a lightweight, no-damageable version until something happens that needs the detailed model (e.g., the lightweight, single piece model is impacted by an object, triggering the swap...or the game's LOD system decides the thing is close enough to camera or player to trigger a swap...).

You probably couldn't do realistic style damage/fracture with geometry shaders. At least it would not be straightforward. I have seen some stylized demos of a model shedding its triangles, but nothing realistic. If you want something that looks heavily stylized or formulaic, then, yes, you could use geometry shaders. (You might be able to couple geometry shaders with something like a fracture texture that contains more realistic fracture patterns that the geometry shader would map to the geometry, I guess. I have seen some research in the literature about generating realistic-looking fracture patterns into an image, so maybe this could work...but not sure current hardware would be able to do anythihg like rigid body dynamics with the pieces after the geometry-shader generated split.)

[Edited by - grhodes_at_work on March 10, 2010 10:55:39 AM]

Quote:Original post by RobMaddisonThinking out loud, instead of destructing the object itself using geometry, why not keep the geometry as it is but reverse the idea and create some kind of stencil containing the parts that are missing. Then when drawing the object, only draw the bits that don't show through the stencil (i.e. the parts of the wall that haven't been hit). I suppose the problem is that you'd still need geometry for the inside bits of the object (e.g. the concrete inside the wall) - but it might be less than the whole object, especially if you use CSG which will splice up the side of a wall into dozens of triangles if your area destroyed is very detailed.

I have no idea whether it's really applicable to games, but Open CSG implements the kind of image-space CSG which you are talking about. It's always looked like a pretty cool library to me :-)

The image space CSG stuff, I don't find compelling with respect to damage. And the CSG is pretty fill rate intensive so I think it would only be practical for small amounts of "destruction."