Uw opmerkingen

It's already reported, but yes, it's planned :)


Edit: This is now fixed in alpha 0.14

I see!

Ideally, the user shouldn't have to know about the whole Y/W thing, which is why I would prefer a DeriveNormalZ style node, which has a Vector2 input and a Vector3 normal. (Packed normals without Z goes in, unpacked normals with Z goes out)

Normal unpacking takes the Y and W channels of the texture, unpacks it to XYZ, calculating Z in the process.

A normal unpack node will most likely make things tricker for new users, as I don't think anyone would set up their nodes to generate an unpacked normal on the Green and Alpha channels. 


How about simply having a DeriveNormalZ node, as in UDK?

http://udn.epicgames.com/Three/MaterialsCompendium.html#DeriveNormalZ

The main difference being that it works on X and Y instead of Y and W


I'm a bit torn, what are your thoughts?

Got an example case where it would simplify things a lot?

The instruction counter has been broken for a long time; but it is now fixed in Alpha 0.14 :)

Not really, and it's most likely too expensive to calculate something like that in real-time in a shader, sadly. You'll have to do that offline/pre-render

The reflection node already acts that way, and there's another request already for real-time reflections, closing this :)

I'm not sure how the second shader was done! Seems quite advanced

Right - The reflection vector in UDK is the camera->normal reflection, which there is a node for in SF already :)

Have a look:


I'm a bit curious though - What exactly is the "Reflection texture" node in the center?