[Nuke]

perhaps just use 3 decals, the start point, a segmented decal that continues from that point and tiles , and an end decal. that way you could have a seamless effect. and nothings getting stacked.

[WMCoolmon]

I don't see a particular reason why a series of decals wouldn't be faster to render than some kind of segmented setup. The GFX card would only have to load one diffuse/glow/shine map set, and could just draw a bunch of polygons that would be identical, aside from position.

Compare this to a segmented setup, where you'd need 3*the original amount of memory or so.

[FireCrack]

Returning to the original topic, wouldnt it be easier, better, and cooler, to just have random explosions on the ships hull as the ship takes damage. A lower hull integrety, and higher damage from a hit, would increase the probability, size, and number of explosions randmly created across the ship. THese explosions would ofcourse cause decals, so the ship would look more beaten as it's hull got lower.

[Cartman]

Hello everyone.

Just one remark on the decal system: I'm not sure how it works exactly, but I suppose you're adding an additional texture with alpha channel to the model. For every hit. Is that right? If so, it would be much more efficient if you merged the decal with the original texture of the mesh which is already in memory. This way, the merging operation is done once and not for every new frame (though you would need to do this in software, without the help of the gpu). Thus, the number of textures in memory is reduced. This makes it possible to have an unlimited number of damage decals per ship. The whole hull could be damaged over the time of a mission, without decreasing performance. (The effect is not that great for fighters, but imagine a colossus being slowly shot down over half an hour)

The downside is that the texture needs to be reloaded from disk when a new mission starts and the ship is meant to be repaired.
And there would need to be a means of managing the shared textures. This is not that much of a problem for capships, because there's likely to be no more than one of a class in a mission, at least for most missions. For fighters, I suggest having maybe three "lod" (read: level of damage ) maps for a ship class. These could be chosen by looking at the damage level of a ship. Concerning the sudden change from new and shiny to totally screwed, the new texture could be assigned if the ship has a certain amount of distance from the player. If he's right next to it, you could use the current texture plus maybe up to three real damage decals, drawn the normal way. Given the visible effect and screen estate for the model, this should be worth the performance hit.

[Nuke]

youre thinking to much there, stop or your head will explode. your typical htl texture is huge. my biggest texture is about 8mb, and thats in dxt1 format.  using damage skins would double that. so its a no go.

now in theory you could have a clean texture, and a damaged texture, and a dynamic mask between the two. when an impact is registered the rendering would return the uv position of the impact, and the impact size. using that data darken the area of the mask in the given radius that corelates to the part of the ship was hit. that part of the mask becomes transparent and the underlying damage skin is revealed. this has a couple of downsides. more textures / texture passes, and ships sometimes share a section of uv spqace for multiple parts. and if one of those parts got hit you see damage in places where the ship wasnt hit. this idea sucks unless you designed a whole game to use it..

right now the decal system works for small impacts, but big ones look pretty awefull, expecially on a curvy ship. you could render the decal over the texture but its would still be suceptable to the same limitation above and thus would suck. what you need to do is make smart decals that can bend around corners, but thats rather complicated stuff, and it would probibly be easyer to geomod. perhaps render a bunch of smaller decals that would overlap and look like a larger effect that would conform to corners, but all that alpha blending would sap your framerate.

[Unknown Target]

Um, something close to geomod would be what IL2 does, where the ships have specific damage points. When you hit that area with a big enough weapon, it'll display a transparant texture in that area, and its up to the modeler to put the wing spars and stuff underneath that area (and only there).

Just something that you guys could use.

Another idea that could be streamlined would be to make the ship out of destructable sub-systems, and when they get blown up, they leave a big hole. The only problem with this is that if you have a wing and the center section is blown up, it might leave the end still there - but I think that's bypassable.

[Flaser]

Um, something close to geomod would be what IL2 does, where the ships have specific damage points. When you hit that area with a big enough weapon, it'll display a transparant texture in that area, and its up to the modeler to put the wing spars and stuff underneath that area (and only there).

Just something that you guys could use.

Another idea that could be streamlined would be to make the ship out of destructable sub-systems, and when they get blown up, they leave a big hole. The only problem with this is that if you have a wing and the center section is blown up, it might leave the end still there - but I think that's bypassable.

The main problem with that approach is AFAIK is that each subsystem needs its own render pass, so that effect would be similar to having the same number of ships/textures in the environment....so it's not a truly feasible solution with the current engine.

Cartman's idea is not bad IMHO since it only takes one more render pass instead a dozen - and while the current decal code is quite fast, it still can't handle the massive ammounts of damage a capship can soak up.

The basic idea is good though - use a mape to store where the ship has been damaged. The problem is the hit of a new render pass.
There are a number of things that can be done, though the best for the whole fade-in would be to use a 1-bit texture. The nice thing could be that given the average decal size it could be even smaller than the texture above - basicly a single pixel would be assigned to a bigger portion of the ship's surface. All that the map stores is where the decal was placed - Bobbau's code already has to monitor this right now.

Here comes the tricky part - after a while the system can't draw any more decals as they would take up too much memory and CPU time.
This is where a pattern-discerning algorythm could do wonders: Once a certain number of decals are grouped together it switches them for a bigger decal texture - cutting down on the number of decals. It could continously merge these decals into bigger and bigger textures.
You could say that that would take too many textures - though if we simply made a base decal texture to cover a sizable portion of a capships hull then let the mipmaps take care of the smaller maps we could circumvent the memory problem.

With the material system further tricks could be done:
-Strech the texture in different manners, flip it
-Apply different alpha blending routines for the decals
-Use the base map as a template and change the decals color accordingly (can be done with shaders AFAIK - check out the disco Arcadia)

Though the tricky part is the said patterning routine - may be too hard to code/take up too much CPU time.
The other alternative is to use a damage texture and alpha blend it into the main once enough decals accumulate.

A further trick is to create a new instance of the whole texture set - with the decals / damaged texture portions burned in. That would lessen the render passes as the decals would be drawn as part of the texture.
The problem is that it would make a new instance for each ship and therefore chew up memory.

[StratComm]

You could probably get "good enough" results simply by blending between the "normal" and "damaged" maps as the ship took damage.  In general though I'm against damage maps because they require more memory, more effort, and still have that annoying problem of every ship getting damaged in the exact same way.  And in reality, fighters rarely stick around long enough for you to even notice damage (and don't even try to damage map a tile-mapped capship) so there really isn't much need anyway.

[WMCoolmon]

I think this is vaguely like what someone is suggesting...

For each texture on a ship, make it possible to have a damaged version of that map (Say, "-dmg"). When the ship is hit, the impact effect of the alpha of the weapon is subtracted from a pure white bitmap generated for each texture with a damage map. Weapons without an impact effect would use a complex trigonometric formula to calculate the alpha,  involving the weapon radius.

When the textures on a ship are drawn, the damage textures are initially drawn. Then the alpha of the other texture passes (Shine, glow, normal) is multiplied by the greyscale map, and the result is used as the texture.

Problems: Extra memory usage. Quite a bit of work. Might not look for certain weapons.

MHO: Might be worth a try sometime, but it might be possible with Bobb's material system anyways.

[Nuke]

i wonder who that someone was 

[StratComm]

The only other problem is, of course, the extra map per ship.  Image count is going to become a serious issue sooner or later.

[Fineus]

I suppose it's a stupid question but... could LOD come into effect here? There's no point in having a damage map loaded on a fighter that's 6KM away. You quite simply won't be able to see it. When it's 2KM away however it's a different matter.

Also where capships are concerned - I assume the game already only renders what you can see rather than what's on the other side of each ship? No point in rendering what you can't see...

[StratComm]

Backface culling?  Yes, the FS engine does do backface culling.  But AFAIK, even faces that are fully obstructed but face the player get rendered (because the render is faster than the check).  That is, however, not the issue with the extra memory; it will be an issue no matter how effectively LODs are used or how rendering is done.  Extra art will always equal extra space.

[Fineus]

Fair enough. There must be a fairly plausable way of doing it though... I fail to believe that it's impossible.

[Nuke]

im curious if it would be possible to change freespace's rendering capabilities to function on a per material bases instead of a per object basis. it would make tieling more effetient and would also allow for better alpha blending. it would take better advantage of htl. because doesnt it take longer to shift gears between objects that use the same texture. like thje collossus used like 60 texture passes (more fi you count all the mapping effects) to render it and all its turrets. assuming all those turrets used the same texture, wouldnt it be better if the engine renders all of those triangles all at once?

[WMCoolmon]

I asked that question in the Internal once, IIRC Bobb said that in order for transparency to work you had to render everything in the order of the distance from the camera. I'm sort of skeptical from that, because of the zbuffer problems I ran into with the cockpit, but I've never run any tests (nor do I know if there's something else I'm missing).

[Nuke]

i read an article by john carmack awhile back about htl rendering engines. how best to implement them and in what order is best to render things in. it was rather informative really, but it was a long time,  way back when q3 came out. and i forgot where i read i t at. i think he mentioned something about a meathod for rendering every poly using a single texture while avoiding improper rendering order. i think it had to do with crosreferencing the render lists before sending them to the video card to cull out anything that shouldnt be rendered (in addition to your usual backface cull). then you render everything back to front, rendering the transparent materials last.  it probibly delt more with fps games, cause im sure there are shortcuts in games where there isnt a polygot no look at in every direction you point.

[Fineus]

If I'm understanding that correctly, it'd make sense... it would mean that issues such as transparency would be solved before the render as the cross reference would tell the engine not to render anything at all (IE: the transpareceny) and could therefore skip checking any other possible texture rendering it might need.