Hi! I made a material effect in UDK. It dissolves the mesh when it gets close to a certain plane. This is done by calculating the distance between the plane and each pixel in the material and using that data to gradually mask a dissolve effect. I wish I could upload a higher resolution video but it took quite a long time to upload even this one.
Thanks for looking 
EDIT: Here’s a quick explanation of the effect:
That’s really cool I’ve never used UDK What language does it support, or does it have it’s own language.
Thank you
UDK has a node based shader editor which is super easy to use. It is free to play around by the way.
Woaw, very cool effect you have here ! :):
Do you use regular node or HLSL to calculating the distance between the pixels and the plane ?
Thanks Froyok, there’s no HLSL. Just nodes, I made a video in which I explain how it works. The video is in 720p. I hope my English is understandable 
Ho ! Great !
Thank you for sharing this material effect, and don’t worry, you are totally understandable ! :D:
You are welcome, nice to hear it’s understandable 
That’s pretty cool, thanks for sharing.
Seen this before but I love it 
Wouldn’t this be done using the inverse values of depth-biased blending node plus an arbitrary mask, or did you use another method?
Edit:
NVM,just saw you posted a video about it, I’ll try to watching it this evening.
Nice work! Does the engine have a way to manage the material so that it’s not being used all the time? It seems like it would be most efficient to have a regular material applied most of the time, but then have the game switch to this one when the model is in-range of the dissolve plane.
That’s a nice suggestion, thanks It should be possible with some Kismet work. The distance of the object to the plane could be calculated in Kismet which can trigger a switch. This switch’s value then can be inserted into an instance of the shader as a parameter where it can activate an alternate path (through an IF node) which returns constant values like 1 for opacity and 0 for emissive.
Though I’m not sure if this really would keep the engine from making those calculations. I think it’s time I started playing around with kismet and profiling tools more seriously
If you use a staticSwitchParameter node, you can disable the expensive part of your material allowing you to make two instances of it. My understanding is that using a switch won’t calculate material nodes that it can’t reach. Then either in uScript, Kismet or a Matinee sequence you can swap to a different instance of the material, one with the switch turned on.
For performance, it won’t calculate those nodes. You will have twice as many shaders for each switch, which can be a problem for memory if you have a complex material with multiple switches that is usable on multiple mesh types.
If you don’t have a switch, and instead use the 0-1 method of flipping, you will absolutely still have to do those calculations.
And again, I must suggest you try to avoid additional IF statements in the material editor, especially if this is on a console (read: specifically PS3).
[QUOTE=Strobel;12045]You will have twice as many shaders for each switch, which can be a problem for memory if you have a complex material with multiple switches that is usable on multiple mesh types.[/QUOTE]
Just curious, are you speaking about material instances here? I might be interpreting your reply wrong. I was always under the impression that if you used a switch and made an instance from that material with the switch on (or any parameter change), the expense would be minimal as the data is already compiled just not used in the ‘off’ state.
Thanks for reminding me twice about the IF nodes Strobel. The sad thing is I failed to achieve the same result with LERP’s. However, I achieved the same result with a Constant Clamp-Floor setup. Here’s how it looks compared to an IF version:
I’m looking into the switch parameter now. Thanks for that one RyanT 
[QUOTE=RyanT;12047]Just curious, are you speaking about material instances here? I might be interpreting your reply wrong. I was always under the impression that if you used a switch and made an instance from that material with the switch on (or any parameter change), the expense would be minimal as the data is already compiled just not used in the ‘off’ state.[/QUOTE]
For every switch, a shader is written both with and without the information past the switch. The material instances will only reference the shader that is set as the parent, but if you use both sides of the switch in the same map on different material instances, you will infact incur the cost of both shaders. This can get really silly when you have multiple switches to turn off things like normal maps, specular, or cube maps in the master shaders.
This also holds true for the usage flags. If it’s marked to be used with Skeletal, static lighting, and foliage, you will have sets of shaders for EACH usage flag set.
It can add up really quickly when you have multiple master shaders set to multiple types of objects.
Material instances of materials are INCREDIBLY cheap. However, you must still eat the cost of each possible permutation (but only once, everything else is just the slight cost of the material instance).
I encourage people using switches to use them wisely. If you’re using a switch to turn off one node, such as a 3 vector colorization, I recommend eating the 1 instruction of performance over the wasted memory that comes from having a second copy of the shaders. If it’s for something complex like a cube map that has transforms with colorization which can add 15-20 instructions, then maybe it’s worth the memory.
You should definitely do an analysis locally using the dumpshaders commandlet to see just how much memory you’re using for all the iterations of the shaders. It can grow to 20MB+ on the consoles if you have a ton of master shaders used on multiple object types.
So to sum it all up, yes, you are saving on rendering cost on individual MaterialInstances by having switches, but shader cost in memory is made worse by the amount of switches
Ah, makes perfect sense! Thanks for taking the time to explain it a little more in depth.
No problemo, always happy to help.
If you ever visit the Dallas office of Rocket, tell Tall Ben (you’ll know who he is, he’s quite tall) hello for me, and we’ll call it even