[RELEASED] Sci-Fi Damage FX

For the last few months I have been working on a damage affects asset. It supports volumetric damage over a surface and can be used to create a variety of affects.

Original WIP thread: http://forum.unity3d.com/threads/released-sci-fi-damage-fx.345391/

Demo videos:

Webplayer Demo:
http://vectorforgegames.com/Sci Fi Damage FX Demo/

Features:
*Heat damage affect as shown in the demo videos
*Fade in damage gradient for damaged areas.
*Fade in heat damage gradient for heat damaged areas.
*Can adjust normal's based on damage, to add depth.
*Can adjust vertices based on damage, to add real depth
*Can customize gradients to make new affects.
*Multithreading to speed up performance (this is currently experimental)
*Includes transparent shaders; can be used to create a variety of affects including decent looking shields.

Limitations:
*Will not work well if at all on skinned mesh.
*Requires shader model 4.0 for normal modification and shader model 3.0 without it.
*Requires Texture3D support.

It is currently available at: https://www.cleansourcecode.com/index.php/sf-realistic-damage-fx.html#

And also: https://www.assetstore.unity3d.com/en/#!/content/45933

 

Looks great! Glad you were able to get multithreading in.

 

Very cool. Will keep an eye on this for future use.

 

Interesting. Planning on a web demo?

 

That's a good idea, when its up I'll post an update with the link.

Also, if there are any particular things (test cases/objects?) you would like to see there that aren't in the demo video, let me know and I'll try to include them if I can.

 

Usage on complex meshes would be good (like how it works when the mesh itself has a lot of detail). The skinned mesh note could be a bit more specific. Does it flat not work or could you describe the kinds of errors it produces?

 

It does not really matter how much detail the mesh has, unless you are using the vertex displace. (With vertex displace, generally the more vertices, the better the displacement affect will look).

The affect is local, but doesn't take into account mesh deformation.
Say for example you trigger the affect on a deformable mesh, and it is set to glow at the impact point. If a bone moves some of the previously glowing geometry away from the impact point, it will fade out as if the impact point was stationary relative to the bone controlled geometry.

One way to get around this would be to do all the calculations in vertex space, instead of local space. The issue with this is that you would need to use high poly models, with even vertex distribution. The other downside is that it will not be possible to distort the normals.

 

Webplayer is up at: http://vectorforgegames.com/Sci Fi Damage FX Demo/
Note that it will not run on chrome due to chrome discontinuing unity player support.

 

Got multi-threading working properly, works well enough to remove the experimental label. In my tests it improved performance by a factor of around 10 on my quad core 3rd gen i5. With 8k voxels being updated 3 times per frame (at 60 fps), there was a ~0.7 ms overhead, without multi-threading, there was a ~7.2 ms overhead on the main thread.

I had to resubmit to the unity asset store, as I found a few minor bugs and wanted to include the improved multithreading in the initial release.

 

The asset is now available in the unity asset store: https://www.assetstore.unity3d.com/en/#!/content/45933
In addition, I wrote a detailed explanation on how it was created, here: https://www.cleansourcecode.com/index.php/blog/how-i-created-a-volumetric-damage-model/

 

Are you generating the heatmap in the shader or on the CPU? I'm assuming it's the latter since you spoke of adding threading. And I'm curious what the performance difference would be between the two approaches.

 

The heatmap is currently generated on the cpu, this is because, at the time, I knew no other method that would support virtually infinite number of contact points. The cpu "bakes" each contact point into the heat map, where as if I sent a list of points to the shader, the fragment shader would have to take into account every single point, leading to a very, very expensive surface shader, that gets more expensive the more points sent to it. With the cpu method, it bakes each point once, and then forgets about it.

Its a bit of a trade-off, with the cpu method, you can draw beams of heat across surfaces, with the gpu method, only a few points would be supported before the pixel shader got too expensive to use.

 

Ahh, a very good point. i was only thinking in terms of your demos. but you were clearly thinking of the larger scale.

Last question: why does it require Texture3D support? Isn't it just making a heatmap, and performing a deformation of the mesh along the negative normal direction, using the UV coordinates and heatmap to determine deformation and color? I'm not sure I understand why a Texture3D is needed.

 

The reason 3DTextures are used, is for blending. This way you can get away with fewer pixels and still produce good results. For example, the 3dTexture is mapped to the bounds of the mesh. In the pixel shader, each fragments 3d position corresponds to a "voxel" on the 3dTexture. You can blend the results of the 3d texture, so that the heat amounts are interpolated across the boundaries between voxels.

In a seperate project, I use a 2x2x2 3dTexture (could probably use 4x4x4) and it still produces good enough results.

If I were to use a 2d heatmap, there would be no way to preserve spatial interpolation, because UV mapping is arbitrary, so there would be inconsistencies across seams.

As another bonus, using a 3DTexture also allows for really cool affects like this:

Spoiler

These affects use raymarching, they are in my dev version of the asset, but not yet released due to some bugs I haven't yet been able to solve. I am considering adding them as "experimental" shaders though.

 

Very cool. Thanks for answering my questions. I'll be buying when my project is ready for it.

 

@unityuser94 Would you be able to update the shaders to include sliders (or at least expose the fields) to control gains for normal, AO, emission, etc., like they have for the default Unity PBR shaders? My shader knowledge is pretty limited...

For my current project, enemies are robots and heat is a method of damaging them. Using HDR enabled rendering and a bloom effect, I've created a pretty neat glowing effect to represent temperature.



The damage effect in your package is nice because it can localize damage based on rays. I would love to be able to extend this and ramp the emission value of that material as the temperature rises.

 

@local306 Are you saying you wold like to control the global emission/ao etc independently of the scripts control? Currently you can set these through a preset texture, and then they are further modified in the shader based on the damage. The emission is already set based on the temperature.

 

If it's not too difficult to do, having control like the default shader Emission field would be nice in order to hook into the system I have developed.

 

@local306 That shouldn't be hard to do; it brings up a few questions though. Should that emission value control the global emission? What color should it emit? Should it emit the color of the emission texture, or should it act as a heat value direct scalar? (ie a sort of, global heat scalar?). There are several ways to combine the emission values. The way the standard shader does it (assumes a white emissions texture, multiplies by that, and sets the pixel color to the result+whatever the color was before) may not be what you want.

 

@unityuser94 for my situation, I've created my own emission textures that I ramp up.

I'm kind of split now because I really do like how your asset is a lot more localized, whereas my approach is to ramp the emission up for the entire texture.

I guess the thing I am looking for most is knowing the exact value of the emission value. Through my experience, I have found values that work best with the bloom effect I am using. When I use your asset, I'm not sure what the values are which makes it hard to control the amount of bloom.

 

@local306 Hmm your right, it is hard to tell the exact emission values; when I had created it originally I had assumed it would be simple enough to tweek the values and judge by eye, but if you already figured out the values you like, it would be better if you could just put them as numbers somewhere.

That's definitely something I could add. Not sure when I will have time, as I will need to walk through all the code and figure it out; not something simple. But yes I will definitely look into this.

 

Thanks for the reply @unityuser94. I'm in no rush at the moment so take your time

I haven't had a chance to peek at the code, but if you could somehow expose a scalar value for the emission value, I think that would be good enough. I'm assuming the max value at the moment it probably 1. However, for my application I am using HDR and in order for the bloom to start to show up as intended, my values range from 8 to 16 depending on how large the object is.