blowing up my enviornment
Author
In games like Red Faction and the upcoming Halo 2, you get to blow the geometry around you up with your gun our rocket launcher. i was wondering how it would be possible to do this for a small demo. I thought at first that i could load a model and then reload it depending on the amount of damage it takes, but that way wouldn't seem dynamic to the player if he saw every object around him crumble apart the same way every time he/she shot at it. So I was wondering if any one else has any ideas.
-darkzim
I know of 3 options:
The easiest way to make destroyable worlds is to use voxels. Voxels are 3D objects made out of 3D particles. (more about voxels). The problem is that voxels are not yet very practical with current hardware. They take a good amount of memory, and are not supported directly by our rendering hardware. This means that if you want to use voxels, you have to implement support for them yourself, and if you want to keep a decent level of detail, you're going to have to limit the size of your world. The advantage, though, is that you can destroy any part of your object (you could even destroy it from the inside) without problems.
Your second option is a more mathematical one. You could build your scenery out of smaller objects (building materials) that each have a relatively simple shape, and some specific physical properties. These objects would have to obey a set of physical laws that define their interactions so that they behave realistically. In other words, if you were to build a virtual house this way, you would have to build it like a real house, with a support frame, and then material panels on the outside and the inside. If any of the objects was to be broken or destroyed, you would need your algorithms to analyse what effect this has on all the other components of the house. If you were to break a pillar in your virtual house, your algorithms would need to determine how this affects the rest of the structure. Obviously, the objects that hold the pillar wouldn't immediatly care, but the objects that are held by the pillar could possibly fall. In their fall these objects could also affect other objects. An inconvenient of such a method is that it becomes more complex to build virtual objects, because they must respect realistic constraints.
The third option, which seems quite hard to implement, and less realistic, would be to create your own algorithm to break a mesh into separate parts and hollow it as needed. I believe this is similar to what Red Faction did. This would result in higher tesselation, and wouldn't necessarily behave realistically. I don't think its a good option in itself. It does simplify the job of those who create the objects, but it complicates the programming. Its disadvantage is that this will unavoidably turn out to be a hack. Your programming code can hardly guess how the object would behave if it were designed in a realistic manner, when its actually not designed in a realistic manner. It could still be an interesting experiment, however.
These are the ways I see to solve the problem you suggested. I have never actually read anything about this subject... But I think what I said made sense. I still hope this was helpful to you. Whichever method you choose, good luck soldier ;)
The easiest way to make destroyable worlds is to use voxels. Voxels are 3D objects made out of 3D particles. (more about voxels). The problem is that voxels are not yet very practical with current hardware. They take a good amount of memory, and are not supported directly by our rendering hardware. This means that if you want to use voxels, you have to implement support for them yourself, and if you want to keep a decent level of detail, you're going to have to limit the size of your world. The advantage, though, is that you can destroy any part of your object (you could even destroy it from the inside) without problems.
Your second option is a more mathematical one. You could build your scenery out of smaller objects (building materials) that each have a relatively simple shape, and some specific physical properties. These objects would have to obey a set of physical laws that define their interactions so that they behave realistically. In other words, if you were to build a virtual house this way, you would have to build it like a real house, with a support frame, and then material panels on the outside and the inside. If any of the objects was to be broken or destroyed, you would need your algorithms to analyse what effect this has on all the other components of the house. If you were to break a pillar in your virtual house, your algorithms would need to determine how this affects the rest of the structure. Obviously, the objects that hold the pillar wouldn't immediatly care, but the objects that are held by the pillar could possibly fall. In their fall these objects could also affect other objects. An inconvenient of such a method is that it becomes more complex to build virtual objects, because they must respect realistic constraints.
The third option, which seems quite hard to implement, and less realistic, would be to create your own algorithm to break a mesh into separate parts and hollow it as needed. I believe this is similar to what Red Faction did. This would result in higher tesselation, and wouldn't necessarily behave realistically. I don't think its a good option in itself. It does simplify the job of those who create the objects, but it complicates the programming. Its disadvantage is that this will unavoidably turn out to be a hack. Your programming code can hardly guess how the object would behave if it were designed in a realistic manner, when its actually not designed in a realistic manner. It could still be an interesting experiment, however.
These are the ways I see to solve the problem you suggested. I have never actually read anything about this subject... But I think what I said made sense. I still hope this was helpful to you. Whichever method you choose, good luck soldier ;)
You can also do the following:
1. Split your models in different sections. i.e. If you have a car then parition it into body, windshield, tires, engine, hood. Keep the number of partitions at minumum to avoid having lots of geometry.
2. Create damage permutations for each damageable section. i.e. different versions of the broken windshield
3. When you detect a rocket hit on the engine, have a list of affected objects, compute damage per-object, and then change the permutation depending on the amound of damage.
If you have enough permutations then the user will not perceive always the same explosion.
1. Split your models in different sections. i.e. If you have a car then parition it into body, windshield, tires, engine, hood. Keep the number of partitions at minumum to avoid having lots of geometry.
2. Create damage permutations for each damageable section. i.e. different versions of the broken windshield
3. When you detect a rocket hit on the engine, have a list of affected objects, compute damage per-object, and then change the permutation depending on the amound of damage.
If you have enough permutations then the user will not perceive always the same explosion.
Its seems like you could just define a set of points(vertices) beneath your regular mesh. lets take the instance where a player launches a rocket into the ground and you want to deform the mesh.
in pseudo code.
You have your regular mesh(heightmap or arbitrary mesh)
You have a list of vertices contained within the mesh that arent initiially rendered.
The rocket collides with the mesh.
You test a bounding sphere vs. the point of collision with the mesh. Subtract the damage from the "fortitude" member variable of the effected vertices.
if (effectedvertex.fortitude <= 0.0)
{
effectedvertex.renderable = false;
}
//Reconstruct Mesh with visible vertices
Here you update your dynamic index buffer to reconstruct your vertices to a solid mesh.
Each new face constructed should prol be assigned a different texture.
the main problem with this is interpreting your vertices into a solid geometry at runtime, as well as ensuring your sorting or spatial algo doesnt require convex geometry, as concave results will almost certainly take place.
in pseudo code.
You have your regular mesh(heightmap or arbitrary mesh)
You have a list of vertices contained within the mesh that arent initiially rendered.
The rocket collides with the mesh.
You test a bounding sphere vs. the point of collision with the mesh. Subtract the damage from the "fortitude" member variable of the effected vertices.
if (effectedvertex.fortitude <= 0.0)
{
effectedvertex.renderable = false;
}
//Reconstruct Mesh with visible vertices
Here you update your dynamic index buffer to reconstruct your vertices to a solid mesh.
Each new face constructed should prol be assigned a different texture.
the main problem with this is interpreting your vertices into a solid geometry at runtime, as well as ensuring your sorting or spatial algo doesnt require convex geometry, as concave results will almost certainly take place.
The first thing that came to mind when I read this was to use a mesh and subtract it from the other mesh. It'd require a bit of math but would look really cool.
Say you have a rocket launcher and you fire the rocket at a wall. You could model what the damage explosion would look like. Then in the game/demo, you could use that damage mesh place it where the rocket hit, and subtract it from whatever meshes it intersets. In your maps, you could set a texture property for the inside and the new poly's created would get that texture.
So after the rocket would hit the explosion mesh would be subtracted from the wall. You could take a texture from a cross cut of a brick (in the wall's case), and that would be textured to the deformed area. And if you really wanted to, you could use some particle effects to make it look like bits of debri and smoke are coming out.
And you could do that with anything you wanted to have collision with. Smaller bullets would just mean smaller damage meshes.
Anyways, just my thought.
Say you have a rocket launcher and you fire the rocket at a wall. You could model what the damage explosion would look like. Then in the game/demo, you could use that damage mesh place it where the rocket hit, and subtract it from whatever meshes it intersets. In your maps, you could set a texture property for the inside and the new poly's created would get that texture.
So after the rocket would hit the explosion mesh would be subtracted from the wall. You could take a texture from a cross cut of a brick (in the wall's case), and that would be textured to the deformed area. And if you really wanted to, you could use some particle effects to make it look like bits of debri and smoke are coming out.
And you could do that with anything you wanted to have collision with. Smaller bullets would just mean smaller damage meshes.
Anyways, just my thought.
I was thinking about what I said. That method would create pretty sharp edges when the subtraction mesh comes out perpendicular to the static mesh. Which would work well for buildings and harder peices.
Maybe you could impliment a hardness variable to your static objects. And then when your subtracting the mesh, you could smooth out the edges based on the hardness factor. Which would make the whole thing work well with terrain. And give you a nice indent instead of a really sharp crator.
You could create 2 or 3 damage meshes as well and randomly pick one. Or base it on the impact strength. It'd give you a really nice dynamic feel to it all too.
Maybe you could impliment a hardness variable to your static objects. And then when your subtracting the mesh, you could smooth out the edges based on the hardness factor. Which would make the whole thing work well with terrain. And give you a nice indent instead of a really sharp crator.
You could create 2 or 3 damage meshes as well and randomly pick one. Or base it on the impact strength. It'd give you a really nice dynamic feel to it all too.
Quote:Original post by eklypse
I was thinking about what I said. That method would create pretty sharp edges when the subtraction mesh comes out perpendicular to the static mesh. Which would work well for buildings and harder peices.
Maybe you could impliment a hardness variable to your static objects. And then when your subtracting the mesh, you could smooth out the edges based on the hardness factor. Which would make the whole thing work well with terrain. And give you a nice indent instead of a really sharp crator.
You could create 2 or 3 damage meshes as well and randomly pick one. Or base it on the impact strength. It'd give you a really nice dynamic feel to it all too.
If you were to use such a method you could also vary the impact angle and scale (on all three axis) of your damage meshes randomly. This would help to improve the variety.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
