+1
Under review

Unpack Normal Node

cg magic 10 years ago updated by Alon Tako 8 years ago 8

Might be useful to have unpack normal node, instead have to select a normal map in the 2dtexture node, in order to do the correct calculation. 

The idea of this is user could create a procedural normal map by nodes, then use unpack normal to do normal map channel shuffle and conversion for unity to read it as standard normal map. 

Separated unpack normal process from the 2d texture node could make 2d texture node more generic and flexible.
Use to do this on Strumpy Shader Editor.


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?

There is an example of what I did before, I have a height map as sampler, then I procedurally calculated the height into vector, converted into normal map. At the last bit, I shuffled the channels, then used unpack normal node, so it will calculate Z correctly.


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)

The important for me is to not unpack normal in the 2d texture node, as long as it is separated process, your DeriveNormalZ should achieve the same result.


I stumbled upon this thread while looking for a way to "sneak in" a roughness texture through my normal map nodes.


I'm working on a shader that requires many texture nodes, and in order not to hit the cap I'm trying to use one of the normal map channels for roughness values.

I was trying to reconstruct the process of checking the "normal map" tick box on a texture node in order to have access to all the individual channels. I'm no expert so that lead me in many directions. In the end this is what I made:


The result is basically identical to simply using the tickbox. There are some extremely minor differences in intensity, but the normal appears to be accurate.


My original goal was to use the alpha channel of the normal map as my roughness channel. However after figuring this out, I realized the channel I end up not using is actually the blue channel. I understand why the blue channel is less critical for a tangent space normal map, however I'm not sure it's entirely useless and I'm not sure how much of an impact using it as a roughness channel would have on my normals.


Testing shows there's literally no difference, making it possible for me to simply use the tickbox instead of this workaround. But I wanted to make sure using the blue channel is safe.

Also I'm interested to know if my calculation above is indeed accurate or is it lacking in some way? since I do get slight differences in values in the final result.

EDIT:

After rethinking it, I guess I do have to use the workaround because ticking the box doesn't reveal the actual blue channel of the texture, but the reconstructed one of the unpacknormal function.

So the only question I have is regarding using the original blue. Doesn't it contain some important data?

+1

I wrote a guide for you, which should answer all the questions you outlined :)

If not, let me know!

http://neatcorporation.com/forums/viewtopic.php?f=4&t=277

Great guide! Helped me a lot! Thanks for all the extra details too, really clears things up.