[zookeeper]

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.

[mjn.mixael]

Ah, got it. I misread.

[Pottuvoi]

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.)

[z64555]

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.

[Thaeris]

That said, Aardwolf began work on a code for something similar...

[Nuke]

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.

[Pottuvoi]

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

[Aardwolf]

@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.

[z64555]

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...

[Dragon]

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.

[Nuke]

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.

[z64555]

I'm wondering how that process would work, actually...

[Aardwolf]

Probably a set of various sized holes for each species.

[z64555]

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.

[Nuke]

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.

[Aardwolf]

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).

[z64555]

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.

[Nuke]

slicing bits off sounds like youd need another technique entirely.

[BengalTiger]

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...?

[Nuke]

thats probably all particle stuffs.