Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: MrBig101 on December 24, 2005, 08:32:14 am
-
Now, this came from kinda what I said over in the now-closed HTL thread in General Freespace.
My idea. Say, you're flying a herc, and you pummel an Argo transport. Say, when the hull gets down below 75%, the skin changes, to show more damage being done. It gets below 50%, and it looks like it's really taking a pounding. and 25%, and it's in deep ****. Now, add that to the already existing flame effects and the decals, and there's my idea.
Now, would having different skins to correspond to damage put too much of a load on machines like mine? Would loading times be horrible? Or would it just be a marginal change?
Thoughts?
-
Geomod of course.
-
Actually, that's not geomod, and it's not such a bad idea. Not sure if it's possible though, sounds like a lot of coding.
-
What about the damage decals thing? How finished is that piece of code?
I remember seeing it in X-Wing Alliance, but have not yet seen it in Freespace... :nod:
-
The trick of course is to get it working smoothly. Technically all you're doing is substituting one skin for another (which I believe can already be done via SEXP) - but to get it working on all ships? That could take a lot of juice.
Perhaps if the number of skins were specified depending on ships size... that could help. Fighters have two skins - fine and damaged. At 50% they swap "fine" for "damaged" untill the fighter is destroyed. Same with bombers. Cruisers could have 3 skins... Corvettes / Destroyers 4 and Jugganauts could have 4+ depending on what people want out of it. That way you're not having too many skins changes on screen at any one time.
-
i dont know, every game ive seen damage skins in it sorta looked cheap.
-
You've gotta watch it though, because every ship will get damaged in exactly the same way. Also, it might look kinda odd if you have a perfectly in health looking fighter, then you shoot it with a single laser and it all of a sudden looks horribly damaged all over.
-
The only way to not make it look stupid is to have Geomod, which is impossible.
Because let's face it, the purpose of the game is to destroy stuff and watch stuff being destroyed. The skin will always look the same, meaning ships get ripped up in the same way over and over again.
What Bob was doing with the damage showing on fighters etc. is probably best, but I have no idea how far along that code is and what it is capable of.
-
Damage decals will work.
A better idea is to make your ship nuilt op out of subobjects, and make all those destroyable. Don't go OTT there, though, since each subobject is heavy on rendering, but you can make some stuff destroyable that way.
-
i dont know, every game ive seen damage skins in it sorta looked cheap.
Damage decals will work.
A better idea is to make your ship nuilt op out of subobjects, and make all those destroyable. Don't go OTT there, though, since each subobject is heavy on rendering, but you can make some stuff destroyable that way.
At least IMHO.
-
i dont know, every game ive seen damage skins in it sorta looked cheap.
:nod:
Aaaaaannnnnnddd. I'm not gonna be the one to make damage maps. Nor will I ask lightspeed to do it. So... yeah. Have fun.
-
It would look good if you could apply a glowmap to the decals, making them glow red, or add animated ones to make it spark about. Since there are only 3 types of decal, maybe it wouldn't hurt FRs that bad.
-
In the early days of when Bob added the dammage decal system (not the first time, but when the current system was added), I was discussing ideas with him about how to do decals for beams and other heavy weapons. I thought that beams should be able to pierce the outer hull and cause melting of the dammaged section. I had an idea, where each ship would have a special dammage glowmap (perhaps animated), that would be rendered behind the main map. Whenever the ship was hit by a heavy weapon, it would apply a large dammage decal, but the center of that would be an alpha map, and reveal the section of the dammaged glowmap beneath. The problems with beam dammage decals, is how to display dammage for type 1 beams, or glancing hits from other times, where the hit point isn't one, but a series of impact points along a path. Since the frequency of beam hits differs depending on the speed of the machine (and the strain its undergoing at the time), a type 1 (slash) hit would look like a varying number of single hits in a line along the hull, rather than the swath of destruction we'd want to see. There'd need to be a special method of calculating the path of the hit, rather than the individual beam hits of one volley.
-
you can sorta do that already with the burn feature and some art skills. ive been using decals for a bullet hole effect with my gatling guns. im not really satisfied with the way they render though, might jkust have something to do with the pis poor quality of my effects (they were rush jobs). if the decals supported glow and shine maps you could make realistic looking melting effects, all be it 2d but from a distance it would apear normal. another feature id like to see is spiecies or armor type specific decals, cause disintegrated vasudan bioarmor will look different than melted teran metal armor. perhaps define the different decals in spiecies defs, each spiecies would get a number of different decal effects. like for beams, missiles, lasers, ballistic. then in the weapon you specify a type and radius, and it will use the decal for the spicies hit and the decal type. it gives some more variation. i think the decal system is sorta still in experimental stage, thats where the feature toggle is. im already using them in my mod so im kinda hoping their rendering will be improved sometime in the near future. also the ability to set decal prioritys would be cool, you want your beam damage on capships to linger, but burn marks on fighters woud fade sooner. the engine, when it needs to clear some decals, will clear the ones with low priority first, allowing more importand decals to linger.
-
I think having three sets of full-size maps for each ship is too much. I think it might actually look nice and I love to create stuff for high-end systems, but this isn't worth the addional memory usage.
We got damage decals. That's just fine. I've disabled them, cause the always drained too much performance for my taste.
And now to all the Geomod fans out there:
I don't think the engine will support this ever.
But maybe bumpmapping will make you happy. Damage decals with bumpmaps should be enough to simulate holes in the hull.
I already have a concept for this. ;) Just in case...
-
Heh, I was wrong.
You're right... having the ship map randomly change at 50% would look terrible if it happened right infront of the player. Much better to have decals coresponding to where weapons fire have hit the ship.
The trick would be to have the weapons fire decals correctly represent what weapon has hit the ship. If a beam has slashed a Deimos then it should leave a scar across where it has moved. However if the beam is of the straight-firing variety (BFGreen for example) then it should leave a much more damaged but centralised scar where it hit the ship. Other fire like player guns (Kayser, Subach etc.) should leave a different mark again.
The problem there is that it quickly mounts up to a lot of decals. Very CPU intensive even if there are only between 15 and 50 types of different damage decal.
-
Heh, I was wrong.
You're right... having the ship map randomly change at 50% would look terrible if it happened right infront of the player. Much better to have decals coresponding to where weapons fire have hit the ship.
The trick would be to have the weapons fire decals correctly represent what weapon has hit the ship. If a beam has slashed a Deimos then it should leave a scar across where it has moved. However if the beam is of the straight-firing variety (BFGreen for example) then it should leave a much more damaged but centralised scar where it hit the ship. Other fire like player guns (Kayser, Subach etc.) should leave a different mark again.
The problem there is that it quickly mounts up to a lot of decals. Very CPU intensive even if there are only between 15 and 50 types of different damage decal.
Why not just have the slash beam use a single decal map, instead of several decals in a row? Some coding would be needing to make sure the 'orientation' of the Decal matched the direction of slash, but after that, it'd work, I think.
-
As long as the graphic was good, and the computer worked out that it should draw the length of the decal to be the correct length of the slash - yeah - it could well work.
-
do it the samew way racing games do skidmarks. cept instead of burnt rubber, its molten metal bliss. perhaps for looks terminate the ends with scorchmarks and maybe a few along the slash for good measure.
-
perhaps for looks terminate the ends with scorchmarks and maybe a few along the slash for good measure.
Needlessly stacking multiple decals is a big nono. Takes system resources...
BTW. I vote for some kind of slider in the laucher that could be used to limit the amout of decals. Or that only everyother decal is draw. Or something. So that those low-end users might enjoy damage. Or that those who want to run dc++ on the background (not me, not enough power :( ) might also enjoy damage.
-
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.
-
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.
-
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.
-
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.
-
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.:D
-
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.
-
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.
-
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.
-
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.
-
i wonder who that someone was :rolleyes:
-
The only other problem is, of course, the extra map per ship. Image count is going to become a serious issue sooner or later.
-
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...
-
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.
-
Fair enough. There must be a fairly plausable way of doing it though... I fail to believe that it's impossible.
-
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?
-
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).
-
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.
-
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.