[##UnknownPlayer##]

Currently I've managed to think of two ways to do this though my relative inexeprience with 3D programming means it would take me ages to implement them.

The first is the traditional method where we draw a whole lot of blended polygons textured and blended with the decal. This has a number of problems - beam cannons leave a lot of decals, and ships take a lot of hits so this method would very rapidly pile up the poly count of a scene.

The second method would be to not actually use polygons but instead dynamically modify the textures of the ships themselves. This has a lot of problems though since textures are shared in memory across several models and in different parts of a model. However, it involves no extra poly's but it will need a creative way around the problem of shared textures and such.

So, does anyone have any additional solutions or refinements on my proposed two methods?

[Sandwich]

Uhm, yeah - the way it's always been done in games: paste on a new decal where a weapon hit occurs - oveerlaid on the ships texturing. No need for extra polys.

[##UnknownPlayer##]

As I understand it not quite otherwise why would we have decal limits? Each decal is a sprite and a sprite has to be drawn on to a polygon - its just blended so only the 2D sprite is visible. The polygon then sits at a certain point on the model. Hence why in some FPS's you can get decals sitting off the walls sometimes.

[Nico]

Originally posted by ##UnknownPlayer##
As I understand it not quite otherwise why would we have decal limits? Each decal is a sprite and a sprite has to be drawn on to a polygon - its just blended so only the 2D sprite is visible. The polygon then sits at a certain point on the model. Hence why in some FPS's you can get decals sitting off the walls sometimes.

no, that's not the way it works: look at the shield effect for exemple. A decal would be a bitmap, that's all, but instead of being projected as a 2D bitmap (like engine glows), with only Z scaling, the bitmap will use the normals of the poly were it is applied ( note that it won't use the UV projection of the map applied to this poly ), which will give it rotation and scaling on all the axis, making it look really 3D ( which it is not I think ).

[Bobboau]

decals are handeled in a completly diferen't way, there more like the sheild hit effect, exept they arn't animated (although it would be cool to have a few that were and the last frame was held as a normal decal), and they are blended onto the existing textured polys not the untextured sheild mesh

[Nico]

Originally posted by Bobboau
and they are blended onto the existing textured polys not the untextured sheild mesh

nah, otherwise, they'd be stretched. In other games like FPS, maps aren't usually applied on perfect square surfaces, and still they are generally square (256*256 etc). If it was blened on the maps, the decal would be completly deformed most of the time.

[delta_7890]

Didn't they implement this feature in XWA?

[Mysterial]

Originally posted by sandwich
Uhm, yeah - the way it's always been done in games: paste on a new decal where a weapon hit occurs - overlaid on the ships texturing. No need for extra polys.

That is generally how it's done. There are decal limits because each poly that has decals that need to be applied has to have its texture stored seperately, instead of sharing textures as the program would in a normal situation. This dramatically increases the amount of memory required.

[Grey Wolf]

In Bridge Commander, it took a certain amount of damage at the point to cause a damage decal. If it continued to get hit there, the hull is "burned" away and a separate mesh is shown through the hole in the outer mesh. This caused some pretty interesting effects, like a Galaxy-class with it's forward torpedo tube are burned away or with a large chunk of it missing on the back.

[##UnknownPlayer##]

Ok, well I doubt we''re going to be putting something like geo-mod in any time soon so let's focus on how we should do decals.

EDIT: People I did some research and it turns out that I'm right and your wrong. Yes we do just paste a decal there, but the decal as I said has to be pasted onto a new polygon (a square to be precise) that gets sized to be no larger then the face the decal is going onto. For more info go here: http://www.flipcode.com/tutorials/tut_decals.shtml

[Bobboau]

that is A "simple way to do it"

[##UnknownPlayer##]

Still, if you'll note the end it is also the way Quake III does it and I imagine that the id guys would know a thing or to. Still, I'll keep looking for examples of other methods but as far as I know this is the most common (thought that could be coz Quake engine games are among the most common).

[LAW ENFORCER]

I don't know if some one said this but couldn't you make a special map of the ship (damage) then weapon hits would 'uncover' the map so a long line of damage wouldn't be just a line of damage decals???

[##UnknownPlayer##]

Hmm...its possible. The easiest way to do it would be to just chnage the texturing of individual polygons. Problem is it would have to be solid otherwise it might not create the right effect for weapons. And on capchips we'd have issues....

[Mysterial]

Originally posted by ##UnknownPlayer##
Still, if you'll note the end it is also the way Quake III does it and I imagine that the id guys would know a thing or to. Still, I'll keep looking for examples of other methods but as far as I know this is the most common (thought that could be coz Quake engine games are among the most common).

That is the most common method of doing it. I had thought it was pasted on the original poly (it actually is in some games), but that requires more texture memory, so they avoid that nowadays by using the method you said, because it allows both the original textures and the decal textures to be in memory only once. The drawback is that it increases the poly count, but unless there's a LOT of decals, it isn't likely to matter.

[Nico]

Originally posted by Mysterial


That is the most common method of doing it. I had thought it was pasted on the original poly (it actually is in some games), but that requires more texture memory, so they avoid that nowadays by using the method you said, because it allows both the original textures and the decal textures to be in memory only once. The drawback is that it increases the poly count, but unless there's a LOT of decals, it isn't likely to matter.

a lot, indeed. a quad= 2 polys

[##UnknownPlayer##]

The polycount thing is the problem - beams cannons would leave A LOT of decals on a ship so we'd probably want to cull them and tile the decal across just one or something, which would be a fairly complex thing to do. Then we've also gotta handle hits from fighters, which there are several thousand in any given mission where we attack capships. Lots of code would be needed to intelligently handle them.

[Bobboau]

we'd want to handel beams diferently, like takeing the start and end points and have a few specal beam decal textures

[##UnknownPlayer##]

Really good idea there! I hadn't thought of that.

[daveb]

There are two ways to approach this problem in general.

- Paste-on decals. You project a rectangular or cone shaped volume onto the model and generate vertices where the volume clips against the polys of the model. In theory this is the "best" way to do it since you're generating the smallest possible polys for the decals. But it suffers from the venetian blind problem. That is, because the vertices of the decal poly aren't the same as the vertices of the poly its being drawn on top of, inaccuracies in the 3d rotation/projection code will cause them to have slightly inconsistent Z values. So the two of them will end up "fighting" for the zbuffer in a view-dependant manner.  There are 2 fixes for this. First is to use the "z bias" setting available in D3D. The squad logos use this to work properly. Alternately, you can multiply 1/z value of each of the projected verts by some slightly-greater-than-1 value to fake their depth "out" of the wbuffer. For small decals (where "small" means small onscreen) this is the preferred method. But if you do this for blast decals which could be applied to, say, the side of a capital ship, they could potentially end up very large onscreen. In this case, you'd need to use a larger value to mess with the 1/z depth and that's going to result in really ugle view-dependant warping of the decal. Which brings us to method 2 :

- Multi-pass decals. As with the paste-ons you're projecting a 3d volume onto the model and "clipping" it against each relevant face. But the difference here is that instead of calculating vertex points, you just calculate texture UV's to map the decal texture onto the existing model verts. Kind of like a lightmap. As long as you draw the decal face with clamping enabled, you're all good. The main advantage is that you'll never have zbuffer fighting. The main disadvantage is that you're going to end up drawing more pixels per decal. In theory this could eat away framerate. But on newer 3d cards, maybe that's not an issue.

I'm not sure which I'd use in this particular case. If I were going to implement this for a "real" game in this circumstance, I'd probably go with method 2 and impose some hard limits on the # of decals per ship or something like that, to make sure fillrate doesn't skyrocket.