Destructibility in 3D game editors

Started by
2 comments, last by bzroom 14 years, 5 months ago
I'd like to take a bit of a shortcut here and avoid doing a whole bunch of illegal downloading (since I don't own almost any of the newest games) - and also hopefully save a whole bunch of time because I'd have to get into each of the programs (which I imagine to be pretty time consuming enterprise) while there are probably a number of experienced level editors around who know this stuff rather well. How is destructibility implemented in various 3D game editors/engines? Examples: HL2 - are the rubble piles and collpased walls hand-modelled or modelled based on physical destructibility? What about newer stuff like Crysis (which I haven't played) or FarCry 2 (which probably has destructibility, but I haven't played enough of it to really see it)? I'm curious because I'm considering implementing an iterative destructive system myself that uses random geometry as input, and I don't have much experience in this field :). The main points I'm interested in are: - different approaches to handling a collision between a destructive object (such as a heavy ball) and geometry - handling a destructive explosive force (eg a bomb) Both cases could be simplified to a point/sphere-geometry interaction. I'm currently not planning on concerning myself with a physics feedback system, eg structural collapsibility etc etc. My orientation is towards providing a level editing capability to produce geometry which would be similar to some of the stuff you can see in HL2 without physical simulation outside of the scope of the actual event of destruction itself. To recap in simple terms: if I want to put a bomb in a house to make a hole, how I go about achieving that in various 3D engines/editors?
Advertisement
Most model formats will support submeshes. Each model instance holds a mask of which submeshes are visible. You could have a submesh covering the premodeled hole in the buidling. Hiding the submesh reveals the hole.

Then it would be up to game logic and scripting to hide the submesh. You may have a generic destructable game entity that is attached to the model instance. It will be preconfigured by a designer to have different destruction states, including which submeshes are visible for each state, what effects to play on transition, network syncronizaion, etc. The destructable object will also be tied to the damage or physics system to monitor conditions for state changes.

So basically you need a model editor and format capable of submeshes. A scripting system capable of manipulating the submesh mask, and then any editors you feel necessary to make the editing of that content easier.

It could also be that the destructable entity is capable of spawning additional model instances. The new model instances will only have a single submesh visible, that of a specific piece of debris from the original mesh. A bounding box could be constructed around this single submesh and attached to a rigidbody or any other sort of physics simulation. You're also going to want to support a spawn velocity for each debris piece, either random, around local/world vector, or designer edited.
Ok, that's the standard way of encoding scripted sequences of destruction for live animation in a game. Unfortunately this is not what I'm really after. Sorry for expressing myself poorly - let me try again :)

What I'm after is the generation of the result of (eg the new geometry generated by) a destructible process, such as a bomb exploding. I want to simulate the destruction as an iterative process to provide the artist with the "explosion hole and resulting debris" to work off of.

As such, I was wondering how commercial 3D editors handle this problem - as is with everything natural (eg the placement of trivial objects for a composition that is supposed to look natural), hand-generating natural-looking debris is a very time-consuming process (eg see the level of detail in Fallout 3). Hence my assumption that level editors porbably have tools to aid the user in this process. The underlying logic of this kind of an approach is what I'm curious about :)
It sounds like you know what you want. Just run the game simulation in the editor, and capture the state so it can be baked to a mesh or reloaded later.

I'm not sure that any tools support this but it doesnt sound very difficult to implement.

Using collision detection and a force based manipulation scheme for placing objects would allow the designer to place things manually in a realistic configuration.

Or just have the physics running in the simulator and drop object so that they can come to rest before storing their position.

In my demo the game was edited entirely in game. At any point you could save the state of everything. This would be the state of the game the next time you loaded it, debris and all.

This topic is closed to new replies.

Advertisement