Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Nighteyes on February 28, 2012, 02:31:54 pm
-
I've been thinking of practical ways to add visible damage to ships as their health gets near 0, after reading a replay of Fury I can see I'm not alone in looking for something like this :yes:
I can think of 3 ways to do this, first is the obvious way of adding all sorts of sub objects that would break apart as they are destroyed, the big problem with this is it takes a lot of work, and most modellers won't have the strength to do this extra(big) step, and even when its done most of the ship still looks 100% clean.
another way would be to add burnt marks and such to the textures and use a script to replace the textures every % of hull damage, the problem with this is the need to have LOTS of textures, both diffuse as well as shine maps would need altering.
third way is probably the "best", I was thinking of having an invisible mesh, a tiny bit bigger then the base mesh, and applay burnt textures with an alpha map only to it, have maybe 3-4 degrees of burnt textures and applay them to this mesh as the hull % goes down.
main advantage of this method is the option to use only 1 texture for the whole ship(good for ships with 2+ textures), decide what resolution to use, as well as not needing to have shine maps.
as I said I would like opinions, maybe there is even a shader solution for this that I'm not aware of...
-
Didn't detail boxing come up with a solution for this a couple years back, or was that the subsystem method?
I'd like to use it in all our ships, but as you said it's very work intensive. Would be nice if PCS2 could auto-gen a damage model
as in your 3rd idea, based one of the existing LODs (probably 0).
-
What you're really looking for is decals. I think I heard a coder say it would be possible once the material system is up. Don't take my word on it though.
-
I've been thinking of practical ways to add visible damage to ships as their health gets near 0, after reading a replay of Fury I can see I'm not alone in looking for something like this :yes:
I can think of 3 ways to do this, first is the obvious way of adding all sorts of sub objects that would break apart as they are destroyed, the big problem with this is it takes a lot of work, and most modellers won't have the strength to do this extra(big) step, and even when its done most of the ship still looks 100% clean.
another way would be to add burnt marks and such to the textures and use a script to replace the textures every % of hull damage, the problem with this is the need to have LOTS of textures, both diffuse as well as shine maps would need altering.
third way is probably the "best", I was thinking of having an invisible mesh, a tiny bit bigger then the base mesh, and applay burnt textures with an alpha map only to it, have maybe 3-4 degrees of burnt textures and applay them to this mesh as the hull % goes down.
main advantage of this method is the option to use only 1 texture for the whole ship(good for ships with 2+ textures), decide what resolution to use, as well as not needing to have shine maps.
as I said I would like opinions, maybe there is even a shader solution for this that I'm not aware of...
hm, i'd love to have damage on ships, but i don't think doing it via texture is the best way to do it.
having 3-4 damage textures per ship would still add a lot of textures to BMPman and would look a bit odd, if you have 2 big ships broadsiding each other with their starboard sides and then see that each portside takes also damage.
plus, more then scorchmarks wouldn't be possible with the texture solution, maybe minor scratches, dents and small holes in the armor if one makes excessive use of normalmaps.
adding the damage to the model is imo, at this point anyway, the way to go. despite the ****load of work it adds to the modeling process.
@JGZinv: detailboxing is basically LODing small detail on the ship.
-
Decals once were in FSO, but got removed due to bugs. It'd be great to have them back, this time properly implemented.
Perhaps the material system will allow reimplementing them. Yet another reason I can't wait for it.
-
:wtf:
You were praying that someone would bring this up... again?
-
...i haven't been here long enough
-
I cannot offer any other ideas about how to acomplish this, but boy, if this gets in code some day it would be glorious indeed.
-
Decals were in the code twice and both times removed due to their propensity to severely break things.
-
I think he means geomodding.
-
Destroyable submodels = Can be done right now but uses up subsystems-per-mission count (if that is still an issue) and takes a lot of effort on the part of modelers.
Damage Decals = Has been implemented before with many drawbacks but has serious potential for the future, especially if normal maps can depress the scorched area to simulate hull damage.
Add Either of the above to persistent surface explosions. This would cause (for properly flagged weapons) continuous explosion effects to hug the hull near the damage point to give the appearance of fires burning from oxygen in the hull. The effect should look like damage effects seen in the Babylon 5 episode "Severed Dreams", on the Roanoke and Churchill. I suspect that something like this could be accomplished through scripting.
-
We already have mega glowing trails for beam impacts, though...they appeared in BP2, at least, didn't they?
-
I thought they were in MVPs now.
-
what about scorch maps?
essentially its a way to render decals directly to a texture, and then use that texture in the fragment shader to "burn" the underlying texture. these maps only need be updated during collision response. of course it will only look right if polygons all have unique (not shared) uv space.
1: fetch a list of all polygons that intersect a set radius around the point of collision
2: using the impacting object's flight path as a frame of reference, rotate vert positions of those polygons into its local space so that +z is the direction of impact. scale and translate the points so that the the impact location is at 0.5'0.5 in the x y and that the projected radius goes from 0 to 1 on both axes. store the x,y coords as uv data.
3: set the texture to the burn mark bitmap (which can be defined on a weapon by weapon basis. this should be transparent anywhere that isnt burned, and should be fairly dark in color. texture should be clamped))
4: set render target to the scortch map
5: draw polygons in uv space (use polygon's own uvs as vertex position and the uvs generated in step 2 as texture coords), they should blend properly with existing content in the scorthc map.
6: use scortch map in the fragment shader to "burn" (probibly multiply against) underlying textures
wheres valathil when you need em?
-
Battuta: glowing trails are indeed in mediavps right now, what I want is a way for the black burnt line they should leave to show up
Trivial Psychic: spewing particles from weapon impact points is possible, its also possible to have particles spewing from destroyed subsystems, the script M!M did gives you the option to do those things, this is not what this thread is about.
I was mainly speaking about black burnt places on the hull, something along the lines on what Nuke suggested, but IMO asking for every single polygon to have UV space is a bit much... as most ships are mirrored doubling texture efficiency
-
I was mainly speaking about black burnt places on the hull, something along the lines on what Nuke suggested, but IMO asking for every single polygon to have UV space is a bit much... as most ships are mirrored doubling texture efficiency
that is an issue. though ive always a proponent of having multiple uv channels, so that unique space mappings can co-exist with space efficient mapping. and many other mapping techniques (such as normal mapping) would benefit from that feature (also being able to generate normal maps for ships that have uv mapping which would make normal mapping problematic, like older models). of course aside from that limitation, the technique has promise.
-
I would love dynamic geometry, maybe using some new GPU function, but i m not tech savvy enough to understand if that is possible, just thinking, something like how tesellation adds more polygons and modifies geometry of stuff in real time assuming the GPU supports said function, also...
there was this old game i used to play a lot called carmageddon 2, it is pretty old yet when you collided or whatever, your car would get pretty wrecked and twisted, not sure how the game did it, but to me it always seemed to be the best ever car crashing modelling system ever, properly modded you could get crashes to be way more realistic than any other game. (albeit most people would actually mod indestructible bricks on their tables)
http://www.youtube.com/watch?v=ezhDwAbw6Co
-
carmageddon is awesome. i think they just used deformation matrices to accomplish that effect. this is likely limited by the same thing that prevents us from translating subobjects.
-
I'd also like to note that there's some underpinnings for -damaged submodels (just like -destroyed) in the engine, and it might be easy to finish said feature.
-
wut. -destroyed already works.
-
When I said "just like -destroyed", I didn't mean literally exactly the same as -destroyed. That'd be silly. I was referring to how -damaged is apparently meant to work similarly to -destroyed, except that it'd get used when the subsystem is damaged but not yet destroyed.
-
Ah, got it. I misread.
-
Damage Decals = Has been implemented before with many drawbacks but has serious potential for the future, especially if normal maps can depress the scorched area to simulate hull damage.
I wondered if anyone has thought about volume decals.
http://www.humus.name/index.php?page=3D&ID=83
http://www.slideshare.net/DICEStudio/siggraph10-arrdestruction-maskinginfrostbite2
It has a nice tendency of not needing any information about the surface outside the Z-buffer.
I know it was originally thought as technique for deferred rendering, but should work on forward renderer also, as long as you have the effect of decals stored in some where to use during actual rendering pass. (alpha channel or another buffer?)
1. Find hit locations and create volume hulls which project scorch marks. (basically cubes or cylinders which are partially inside the surface.)
2. Fill z-buffer with opaque polygons. (z-prepass)
3. Render decal convex hulls which fill screenspace buffer with scorch marks. (additive and/or max blending)
4. During actual scene rendering use information from decal buffer to make necessary changes. (color, normal, some strange multilayer damage parallax.)
Also simplified version is possible where you render scene and then use decals to darken surfaces.
No need to write anything fancy or change actual rendering pipeline. (but loses all the funky possibilities.)
-
Physical damage to ship hulls can be achieved by performing a volumetric subtraction of the hull and a damage volume. This therefore reduces the load on artists, because they do not have to model variations of the hull or have blow-out pieces that stick to the main model and vaporize when hit. Additionally, the subtraction method is "more realistic" in the sense that you can have unique combat damage per vehicle.
Main disadvantage I see to this is implementation into the current FSO engine. I guess one way to do it is to make all "damagable" objects copy their .pof vert data to a C++ object. This object is initialized to its .pof data, and whenever it receives major damage its vert data is subtracted by an incident damage volume and overwrites its initial "clean" state. Therefore, any successive damage could have more volumetric subtraction.
Of course, the easier way to accomplish this is to apply decals that have a normal map. :P
-
That said, Aardwolf began work on a code for something similar...
-
was that his deformable terrain engine? pretty impressive, but i think he had issues with speed.
anyway the main problem is this. in a game when you have an object like a ship, what you really have is a description of the ship, with all the parameters for that ship. the actual model is likely a reference to a single copy of a model, which is shared between all ships that use the same model. only thing that is different is the orientation matrix, the position, physics data, names, etc. so when you need to do any geomodding you now need to keep a copy of that model data for each instance of that object in the game instead of just using a model reference (since any changes to the model will affect every instance). so you have higher memory usage. to save memory, you can instead buffer all the deformation coomands, and apply them every frame, which is slow, but you only need to store the information for the object you are working on, once its rendered to the frame buffer it can be tossed and you can process the next one. this can get costly in cpu cycles if the list of commands gets long. this is like the carmageddon 2 example (only the deformation matrix for each object is updated, and it can be multiplied by new deformation matrix and stored for the next impact event, and used for rendering).
back to aardwolf's piece of code i should point out that modifying world geometry is way different from modifiying geometry of multiple objects. since only 1 instance of world geometry is ever used, so updates to that information is less costly than have to track of every instance's deformed geometry.
-
Physical damage to ship hulls can be achieved by performing a volumetric subtraction of the hull and a damage volume. This therefore reduces the load on artists, because they do not have to model variations of the hull or have blow-out pieces that stick to the main model and vaporize when hit. Additionally, the subtraction method is "more realistic" in the sense that you can have unique combat damage per vehicle.
Main disadvantage I see to this is implementation into the current FSO engine. I guess one way to do it is to make all "damagable" objects copy their .pof vert data to a C++ object. This object is initialized to its .pof data, and whenever it receives major damage its vert data is subtracted by an incident damage volume and overwrites its initial "clean" state. Therefore, any successive damage could have more volumetric subtraction.
You could do 'volumetric' substraction in pixel shaders as well and without changing the vertexes.
basically you describe what kind of interior you have and use raytracing in pixel shader to get proper intersection against the virtual geometry.
Basically it would be modified Parallax shader, which would be visible at placed which are marked as holes.
If one would use multilayer parallaxor distance fields one could do quite complex interiors with a self shadowing and glowmaps.
http://hall.org.ua/halls/wizzard/books/articles-cg/p55-policarpo.pdf
-
@Thaeris: I'm not sure whether you're referring to my C# CSG project of 2 years ago (which never actually worked in "real-time"), or my more recent C++ "destructible terrain" system which did?
Physical damage to ship hulls can be achieved by performing a volumetric subtraction of the hull and a damage volume. This therefore reduces the load on artists, because they do not have to model variations of the hull or have blow-out pieces that stick to the main model and vaporize when hit. Additionally, the subtraction method is "more realistic" in the sense that you can have unique combat damage per vehicle.
Main disadvantage I see to this is implementation into the current FSO engine. I guess one way to do it is to make all "damagable" objects copy their .pof vert data to a C++ object. This object is initialized to its .pof data, and whenever it receives major damage its vert data is subtracted by an incident damage volume and overwrites its initial "clean" state. Therefore, any successive damage could have more volumetric subtraction.
Actually there's a cheaper way, and I believe this is how geomod works: instead of storing a modified .pof for each ship, each ship would store a list of pre-modeled "holes". Rendering involves stencil-buffer magicks.
-
Actually there's a cheaper way, and I believe this is how geomod works: instead of storing a modified .pof for each ship, each ship would store a list of pre-modeled "holes". Rendering involves stencil-buffer magicks.
That would mean more work for the modelers though. :(
I like Nuke's idea over mine, since presumably you could save a bit of resources...
-
Couldn't be these pre-modeled holes universal for a certain group of ships? So that hole models used could be table-defined and use only a handful of actual model files.
-
as i understand it thats the way it would work. you could define holes by type, by species, etc. your essentially composting 2 models in the frame buffer as opposed to modifying the geometry directly. its actually the same way portals work.
-
I'm wondering how that process would work, actually...
-
Probably a set of various sized holes for each species.
-
No, i mean how the rendering process would go... I makes sense to me to make a hole with an inside texture based on species, but I don't know what happens after the hole is placed on/over the ship model.
-
render the ship, draw the gashes to the stencil buffer, then draw the hole models, using the stencil buffer to mask out non-hole areas.
couple of issues though. for holes that go all the way through, you probably have to scale the hole to stretch to both sides of the hull, or use a large hole and clip off the ends.
also i dont know how you can collision detect these holes, so that you can fly through the holes in your capships. probably when you collision detect the ship, you also collision detect against all the holes for that ship, except in reverse, because the holes are inside out so if you collide with a ship, but are within the hole model, then no collision has occurred, this of course would require sealed hole models.
-
Yeah, the holes should probably be manifold meshes.
Also, not sure what you mean by "holes that go all the way through"... beam piercing? That could probably be done "for real" by iteratively making small holes, although there would be a few issues with that. One, you'd have so many holes overlapping that it'd be inefficient... so maybe you would have to do something special. Two, if you did beam piercing that way and it modifies the collision detection, then you will have a lot of the extra damage from the beam be wasted (because it wouldn't be hitting the ship anymore).
-
Could make "slices" that would be children of the model. So that whenever a hit was detected on the hole, damage would be delt to the ship's hp....
Well crud, in that case, the deformation matrix may be better.
-
slicing bits off sounds like youd need another technique entirely.
-
Currently slashing beams leave a temporary glowing orange trail behind.
How does that work, in which .tbl is the info on it stored so I could play around with it and make it (semi-)permanent and available for all types of weapons...?
-
thats probably all particle stuffs.
-
not being biased i would personally love the deformation matrix, i have seen very high polygon models and several of them in carmageddon getting pretty messed up geo wise without a very big impact in perfomance.
tho question to nuke, in carmageddon models did had splicing while working i remember more than once getting half my car cut totally and i could still drive with just my forward section around, i dont know how they did to make it work like that O,o it was like a single model would get made 2 models in real time and the game inmediately updated they to be totally separate entities...
-
deformation matricies are kind of ugly unless your ship is a composite of submodels where each one has its own deform matrix. its really and old skool technique which probably isnt compatible with the way freespace works. youd also need to remodel everything as a collection of smaller subobjects. so i dont really think its practical for freespace. should also point out that carmageddon was about slamming your car into other cars/pedestrians, so the parimary source of damage is collision damage where in freespace collision damage is fairly rare, where most of the damage is weapons damage, beams cleaving off bits, punching holes through your ship, etc. i dont think its well suited at all.
-
talking about collision, I think one of the main problem with all those ideas isn't how to deformate the mesh, but how to update the collision mesh accordingly, in real time.
-
i think it would be fairly easy with the holes approach. if you collide with an object, then check to see if the point of collision is inside any of the holes for that ship, if it is then you can ignore the hull collision. you might then check the hole to see if you are going to collide with any of the inner surfaces, and do response if necessary.
it would also be fairly easy to do with deformation matrices as well, since a matrices allows you to convert between the 2 coordinate systems. might slow it down a little though.
i was thinking a little bit about implementing the hole system and thought it might mesh well with my scorch map idea. the hole models are just rendered in those places not masked by the stencil buffer. so i was considering how to render those places where the holes should go to the stincil buffer. my first idea was to use a sprite roughly where the hole is on the model. but this probibly wouldnt look right. so then i started thinking about my scortch map idea. what if there was a channel that got rendered as transparent to the stencil buffer to allow holes to be rendered beneath. this would also allow you to scar up those holes with scortch marks and provide nice transition between a clean hull and a massive gash. the two effects would complement eachother nicely.
-
well given the deformation dosnt sounds so good as an idea, the nuke idea looks fairly good as it gives both things, geometry modifications and visual enhancement.
if i could i would just like one more thing then, since i was told real time fractures are a NONO in freespace i was thinking maybe ships could be given a "spawn debris on hit" so they spawn some small debris parts when hit by powerfull weapons on the point the ship gets hit and a hole made as to show where the hole mass went to, and certainly, add a damage threshold for what kind of weapons or stuff will cause said holes.
-
can the powers that be move this thread to the scp board for review by coders for potential implementation?
-
I was thinking maybe ships could be given a "spawn debris on hit" so they spawn some small debris parts when hit by powerfull weapons on the point the ship gets hit and a hole made as to show where the hole mass went to, and certainly, add a damage threshold for what kind of weapons or stuff will cause said holes.
I think you would want to reserve that for blowthroughs and projectiles, since anything on the wrong end of a beam should be vaporised.
-
I was thinking maybe ships could be given a "spawn debris on hit" so they spawn some small debris parts when hit by powerfull weapons on the point the ship gets hit and a hole made as to show where the hole mass went to, and certainly, add a damage threshold for what kind of weapons or stuff will cause said holes.
I think you would want to reserve that for blowthroughs and projectiles, since anything on the wrong end of a beam should be vaporised.
Depends on the severity of the hit. The kinetic force of the beam or secondary explosions inside the ship could send debris flying.
-
debrits and particle spews are already in the game, i dont see why they cant be used to spice up the damage sequences.
also you consider that not all materials melt or vaporize at the same rate. i mean if you have tungsten conduits surrounded by aluminum structural elements then the the aluminum would vaporize first potentially providing rapid expansion necessary to sent bits of tungsten flying off into space before they can be seriously deformed. for like beams that go all the way through the hull you would definitely have ejecta coming out of the other side.
-
Who cares about what would really happen. Rule of cool, people. Flying debris ARE cool. That's all we need to know really.
-
Who cares about what would really happen. Rule of cool, people. Flying debris ARE cool. That's all we need to know really.
Yeah, but there will always be people that ask "why," so we gotta be prepared. ;)
So, what would be needed to get this puppy started?
-
Hey uh in terms of spawning random debris during combat, please give mission designers/mod designers control over that as that's a big balance change.
-
unless they don't do damage and are a purely visual effect
-
the debris is really just eye candy, and if your so close to bet hit by them you will likely get vaporized by the beam anyway.
-
It'd be fun if beams had a small 'cone' around them, where, if you're close enough, it knocks out the shield quadrant touching it + 50% hull if the hull touches it, and flings you back about 100m -- wait, beams pierce shields, so shields should stay up, but hull should still drop.
-
It'd be fun if beams had a small 'cone' around them, where, if you're close enough, it knocks out the shield quadrant touching it + 50% hull if the hull touches it, and flings you back about 100m -- wait, beams pierce shields, so shields should stay up, but hull should still drop.
'cept of course for the beams that dont pierce shields!
-
Does blast radius work on beams? Because that'd be what you're asking for, basically. Not a cone, but a sphere around the impact point, but the basic idea is the same.
-
i believe a satanas beams would cut a chunk big enough to be a menace to any fighter flying around and crashing with said debris
-
*ahem*
As far as feasibility, I reckon the pre-modeled holes technique is the easiest, both as far as graphics and physics. Here be wizards, etc.
-
debrits and particle spews are already in the game, i dont see why they cant be used to spice up the damage sequences.
Yeah, I think that upgrading particle spews would be the place to start. Remember, you can't really see the new asshole the Lucifer carves in the Legion until after the timeskip because it's on fire.
-
Yeah but how to do that for slash beams? If the whole half of the ship is alight it'd look like ass...
-
those would produce just a minor formation and a red glow map over the texture maybe?