Blasting a hole thru a wall

If that were easy, every FPS would do it. The problem is possible (read up on constructive solid geometry, ie. newmesh=cube-cylinder) however it''s very computationaly expensive and results in lots of little polygons. When used in a game it will probably wreak havoc on your level organization, so major slowdowns will occure when you have to recalculate the bsp tree or whatever else you use. Another major problem with this has to do with texturing. What texture do you use for the inside of a wall? if one side is a brick, and the other is plaster, your level editor would have to store information on "inside" textures also. Basically, it can be done but it''s not easy, luckly if you do a google search, you will find lots of info on this because it''s been around for a long time. Tron was actually rendered (raytraced) using constructive solid geometry because back then they didn''t have the storage for fully polygonal models.

exactly as Pseudo said, but thought I''d add you might want to look into the "Boolean" geometry operations - Boolean Subtraction, Addition, Intersection ... (sometimes OR/AND/NOT terminology is used)...

hth
Jack

What about putting a decal on the wall with a bump map on it to look like it has a big dent in it? Would probably be much less hassle, and look better, assuming you can support bump mapping in your project.

I would think that generally you would only want that to be possible with certain walls, i.e. secret areas. So to actually do it in a game one option seems to be to use a model for that section of wall and have before/after models. Of course if you want to procedurally generate the after model then that leaves the original problem.

When I first saw this thread I thought of a decaling method, but it is possibly wandering away from what you are trying to achieve and dependant on the rendering api you are using. I''ll throw it in anyway...

Render the box with an alpha channel for each face. At the beginning each alpha channel would cause the faces to be rendered solid, then you''d have to cut "holes" in the alpha channels as they are hit.

The advantage would be that you can hit it as many times as you like with no complex mesh adjusting algorithms that will take time and increase the triangle count (increasing rendering time).

There''s still one oddity though... what happens if the user shoots a complete line of holes all around the perimeter of the face? - the middle section should fall to the ground!

quote:

---

Original post by matibee
When I first saw this thread I thought of a decaling method, but it is possibly wandering away from what you are trying to achieve and dependant on the rendering api you are using. I''ll throw it in anyway...

Render the box with an alpha channel for each face. At the beginning each alpha channel would cause the faces to be rendered solid, then you''d have to cut "holes" in the alpha channels as they are hit.

The advantage would be that you can hit it as many times as you like with no complex mesh adjusting algorithms that will take time and increase the triangle count (increasing rendering time).

There''s still one oddity though... what happens if the user shoots a complete line of holes all around the perimeter of the face? - the middle section should fall to the ground!

---

Unless you''re using 3 dimensional textures(no, not cubemaps) then this suggested method would artefact horribly. Its not really viable, and if it were this easy, then it''d be common in nowadays games. Not trying to make you feel bad or anything though.....

Red Faction did it rather good.

Unfortunately, deformable terrain was one of the few things Red Faction did well...

Peace,
ZE.

edit Sorry, had to remove the link because of bandwidth restrictions.

//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links


[edited by - zealouselixir on November 24, 2002 4:37:21 PM]

quote:

---

Original post by ZealousElixir
few things

---

BWAHAHAHAHHAAHAHAH :D

[edited by - Hairybudda on November 24, 2002 3:19:09 PM]

[edited by - zealouselixir on November 24, 2002 4:37:48 PM]

How did Red Faction do it? Bridge Commander did it too right? Making a game using CSG would slow it down, at least I think so. Plus you were right about recalculating the BSP''s etc. Hmmm...I guess what it all boils down to is having an algo that generates triangles, given a set of vertices and outer edges.

I have a compromise though, first I set my walls to have fixed sizes for its triangles, that way a triangle on one face will correspond to an identical triangle on the other face. When the wall gets shot, I select the vertices affected and move them into the wall, creating a dent. I''ll paint a decal on it too I suppose. Once the dent has reached a certain size, I remove a slice of the wall (using the affected vertices to determine the dimensions of the slice), and make new triangles to reflect this hole. I''m quite sure this will work, however it will mean that a phaser would make square/trapezoidal holes instead of circular ones.

This is the only feasible plan I have at the moment, I was just wondering if there was a better way

Your idea about denting the wall would "work" but it would require high tesselation of the walls to look good, and that''s going to kill perfomance. That anonymous poster made is sound easy enough, except he''s never tried it, so he doesn''t reallize that it''s NOT easy. Any game with semi-large levels neads some sort of visiblity. When you go blasting holes through things the visibilty gets messed up because now you can either see things you couldn''t before (bad for portals) or you have to recalculate bounding tree''s (slow and adds lots of triangles) So no matter how you do it, you have limitations. Compiling a level may take .3 seconds, but it doesn''t have to fit changes into an existing level, is simply does it from scratch with all the knowledge of the "burshes" in the game you wouldn''t have that knowledge, you would just have triangles. Also if you''re doing lightmaps, punching holes in things could pose a problem.

I recently made a few thoughts on this topic . My conclusion is that the only way to accomlish this using triangle geometry is tesselation . It can be dynamic or precalculated .Take a quad for example . You can load it as a set of 100 smaller quads or based on the bullets that hit it during runtime , tesselate it to smaller ones.The second solution might result in less polys but it IS more expensive to calculate in real time.Now as regards space partitioning , to avoid real time calculations you could enclose each deformable wall/object with a bounding box .This way , PVS calculations would NOT require alot more processing power .However , all the above examples should only used in a sophisticated manner .It is unlikely that using todays hardware , a game would feature the above operations while 10-50 players (or more) would have the possibility to fire bullets anywhere with their machine guns ...

Hello:

This is my first post, but I''ve been a frequent visitor and found out about this site and openGL about a year ago. I forgot my old user name!

Anyway, I think the "deformable" wall would be great for secret areas. Also, the question remains -- how much of the original wall remains? How many little quads do you leave hanging around?

Finally, I''m looking into portal engines right now, as they look very promising as far as creating realistic interiors. A question that needs to be addressed is: what is the basis for your engine? If it happens to be derived from some type of portal engine, then it could be easier to tear down walls to open up new spaces; my guess is that opening a new portal where an explosion occured would make this more automatic.

PS I''m going to start a new post asking about 3D world creation and portal engines.

Oh yeah, about the quads --

of course if tessallation is working for you then you could tear down a roughly circular, randomly determined set of those quads ...

Uless you have developed gravity system that pulls down objects that have their bases blown off, realtime csg will look weird. There''s visibility problem as mentioned above plus you will have to remove t-junctions unless you want visible creases in your level. Not sure how collision system will work out. I agree the csg is fast when used on low poly geometry. You''ll need blocking geometry to prevent player from destroying entire level. This csg is an interesting idea if used correctly in a game. If not used correctly you can run into some game story line flow problems. Also gameplay can be compromised, ie. instead of looking for a key or password to a door you blast your way thru a side wall instead. Might as well leave the door open in the first place. Once you start putting blocking geometry to prevent player from destroying things you have to tell player which walls he can destroy and which he can''t, otherwise he''ll go nuts blasting everything and wasting ammo. Using csg will increase realism but make sure you can destroy other things as well to have a consistent destroyable world, instead of able to blast thru a wall but not take out a tire on that halftrack, etc. One nice way to use csg and not go bonkers would be to mark a crease in a wall that can be destroyed thru csg something like in duke3d game. Just some thoughts...

I managed once to get some artifacts in the Red Faction demo that reveal a lot about how the game does deformable environments.

It seems that the brush is never split at all. Rather, the "hole" is clipped to the brush, and rendered on top of the brush without z testing. For physics, then, whenever there seems to be a collision with a given brush, check to see if the point is within any of the brush''s child "holes;" if it is, then there really was no collision. This way, you simply store a list of holes, in some sort of spacial data structure, for each brush. It seems, then, that it would be fairly easy to merge holes, etc. It''s a clever technique, which keeps physics easy, triangle counts down, and geometry simple. I think it''s what Red Faction did.

however, RF was a good example of why it kills performance as well... blowing chunks out of a wall tended to make mg gf2mx crawl a bit at times (and i wasnt playing at that higher res)

I do agree, its an intresting thing to look into, maybe i''ll give it some more thought myself

Really? I never played the whole game, but the demo ran fine on my computer, and I only have a PIII550 Katmai with 256 MB RAM and a TNT2 - and I dug whole tunnel systems in the test box map. Maybe I''m just used to lower framerates.

quote:

---

Original post by Anonymous Poster
Once the Geomod has completed, the code does a search through adjacent faces and finds any chunks of the world that are separated from everything else (like a bridge that has been blasted on each end) and separates it into a new piece of geometry and either deletes it or adds physics to it, depending on the version of the engine we''re using. RF2 just deleted them, for framerate reasons.

---

Hang on, does this mean that in RF2 large chunks of geometry can dissappear if they have no connections to the world... ie, destroying both sides of a bridge, would make it collapse in RF... Surely you just don''t delete it in RF2?



Death of one is a tragedy, death of a million is just a statistic.