More then one Lerp blend Shader possible?

Autocon

So I wish to have a shader that blends 2 textures together based off a height map that is based on the vert colors I already painted on the model in Maya.

Which I was able to do.

I also want a shader that blends between lets say snow that is always pointing up and rock.

Which I was also able to do.



Problem I am having is combining them. I want to have all of this in one shader. Basically I want to have snow blending on top of the rocks that are being blended by my heightmap/vert colors. It seems like it should be possible since the snow is just blending into the rocks based on the Up Vector position where as the 2 rocks blending into each other are blending from vert colors/heightmap.

I figured I should be able to take the result of my Lerp blend between 2 rocks and plug that into the Lerp of my Snow and Up Vector. Problem is it seems to kill my rock blend and only use one of the textures to blend too.


Is something like this possible in UDK? If anyone knows a way to do it I would really appreciate to hear it

Thanks!

Ben Apuna

This sounds like the same problem in Ace-Angel's Vector Transform Node =/= Vertex Colors (As of August 2011) thread.

Check out Virtuosic's thread which I linked to there for a possible workaround.

Vailias

if that is the problem you could possibly get world up vector without a vector transform node by using a world position node, multiplying it by 0,0,1 and normalizing it.

Ace-Angel

If it is indeed the same problem as mine, then Vailias method works best. It's much easier to control in the long run on a complex shader.

The other cheap way to do is to add all your nodes which are going into your Vector Transform nodes by a empty Reflection node (subtract the Reflection node by itself and add/multi it to your other nodes going into the Vector Transform).

For some reason, inorder for Vertex Colors to work with the Vertex Transform node once you enable Pixel Camera, you need to have a Reflection vector going into the Transform node. I bugged and asked Epic about this issue, but still no reply.

Autocon

Thanks for the info guys. Well since its been forever since I used UDK and I am a bit rusty at it I think I might be missing something or doing something wrong.

Using what Vailias said (if I did it correctly) the World Position right now is only effectually my model by height. As in the the top most part of the model is covered completely in snow while the lower part is not. Instead of having faces that are angled upward having snow on top of them and those angled down just showing the rock.

Here is a SS of my node set up right now for controlling the snow effect. As visuals are always easier to understand than words haha The old Vector Transform was plugged into A of Dot before to get the falloff as expected.

Ace-Angel

I would plug in the Normal Map for the extra details if your model is a rock or such. Helps with the details.

Vailias

um ok odd shader setup.. you're getting the world up vector, then adding to it to make it point off to the upper right back, then taking the dot product of that with the up vector in tangent space?
Why would you do that?

.. Ok when I say normalize the vector I mean use the node "normalize" to get a vector of length one so you can get a predictable result out of the dot product.

To get snow falloff you need a world vector transformed into tangent space, and the tangent normal. By default everything in UDK's shader editor starts in tangent space (unless ortherwise specified by the node, like world position)

World position is in world space already, and should be passed in sort of "pre transformed" to the shader. If you simply normalize the world position, you'll get the direction the object is from the world origin, however, if you keep the absolute value of the Z part of world position, then normalize it, you get the world up vector.

Just feed that into the dot product with the tangent space normal (ie your 0,0,1 vector) and your falloff should be back to what it was.

Also your maths after the dot product are interesting... if it gives you the result you want, then super.

Autocon

Well I tried doing a Normalized World position plugged into my Dot product but this isnt giving the result I would expect. It blends the snow effect based on the height of the model, not its pole position/Zup direction. It seems no matter what I try it is always basing the way it blends off the Z height. So if its above the 0,0,0 grid plane it will have snow, and if its bellow it wont.

That is why I was using a Vector Transform as that gives me the the Z normal up direction so no matter what angle the rocks are rotated the snow will be on top. But doing this wont let me blend with my Lerp blend of 2 different rock textures


Unless I am doing something so totally wrong. All this math and shader stuff is quite confusing ha

d1ver

Thanks for the tips, guys.

Hey, Valias, your logic sounds pretty damn sound, buddy, but in my case it was exactly as Anthony describes it. Also the mask was in object space and rotated with the object. Makes you wonder...

Ace-Angels' "reflection" method works like a charm on the other hand. I guess 'cause when coming from the reflection vector it uses the reflection vector "interpolator" for which there is a free slot, instead of using vector transform's one, which is occupied with vertex colors. Though I must admit I have no idea what interpolators mean here:) if someone knows, I would greatly appreciate a little clarification.

So here's how I got it working, Anthony. I hope it work this way for you as well.





And just in case, the geneal idea is that you blend "snow" on top of any kind of rocks you have, and then you blend those snowy rocks like you would blend the regular ones. The good thing though is that you can make snow also vertex color dependent and git rid of it all together in some places.

Ace-Angel

Wish I knew why, I asked Epic several times (plus emails) about said issue when I was making my master vertex material, and what is the logic behind it, but they didn't answer. I'm guessing they don't consider it a bug, but it still raises the question as to why this 'method' isn't documented for Environment Artists if they wish to have a Transform node alongside Vertex Colors.

Vailias

Cheers all.
I've had precious little time to do anything 3d or udk related lately, but this is a really bizarre case. I'm sure my vector reasoning is good.. but it seems the way the actual data is getting handled by the shader and its UDK preprocessor isn't what I'm expecting. Been seeing if I can fuss with this some tonight and I'm getting identical results (which is good, if annoying). On the plus side it's forcing me to learn more about how UDK actually creates and compiles its shaders.

So Ace, as to the answer to your question of why you need a reflection node in there to get the effect to work is likely due to one of the many compiler options that are triggered based on what nodes are present. I've done some experimenting, and while I haven't been able to find the culprit for sure. I have verified that the reflection vector has to be used SOMEWHERE in the shader. It doesn't have to do anything at all, as you've effectively demonstrated.

I've even multiplied it by zero and plugged it into emissive (or transmission color... or anything really), while keeping the vector transform operating on just the regular 0,0,1 up vector and whatnot, and the vertex coloring effects stay.

It seems any other vector present other than the reflection vector doesn't trigger the correct compilation, even though the reflection vector is calculated from the camera vector.

Also the interpolators thing, if I remember right (and after some research yes I do remember right), is an actual hardware limitation of GPUs. There are a fixed number of slots that you can cram data into, memory registers.
10 of these are interpolated registers in sm 1-3.0 compliant hardware. So including all the interpolated data types needed for basic graphics stuff (like vertex position, normal, world to view matrix etc) only leaves so many.. so that's where the mutually exclusive restriction comes from in this case.

d1ver

Hey, Valias, thanks for the info, man.

The reflection vector is brought in in tangent space, though I think it's passed to the shader by the app in world space. Which means the transform matrix has to be there no matter what and that triggers the compilation that allows for one more interpolator. And then the matrix is reused with vector transform node. Must be something like this

Vailias

Nah, the reflection vector is calculated In shader by transforming the camera vector into tangent space then reflecting it about the normal. I found that piece of hlsl last night.

Also I'm not sure it's one more interpolator so much as it is using an interpolator with sufficient precision... Or it could simply be an assumption that if there is no reflection vector used, then you aren't environment mapping anything so the per-pixel camera vector switch doesn't get set to make a more efficient shader. :shrug: not sure, but it's been enlightening to say the least.

d1ver

Oh I see. But my point still was about the transform matrix applied under the hood:) but yeah, sure as hell educational)

d1ver

Had to recreate the shader and found that there was one thing I missed:
make sure you have this checked:



in addition to the reflection vector thing.

Autocon

Sorry never responded, work pulled me away. Just wanted to say thanks for all the great info guys, extremely helpful and informative. And d1ver that set up helped immensity, helped me figure out the blending a lot better but it still wasn't correct and was going to give up till your last post. That check box fixed the issue I was having and got everything working exactly as expected Without it I wasnt getting blending and slope to work at the same time but that fixed it!