Normal Baking precision problem

Here is a sample file:
Normal Baking Sample.blend (3.2 MB)


Within the file, a procedural texture nodes setup is used to modify the default cube’s normal.


As in the pic above, I use this setup to mimic glitter material. Then I took the modified normal into a default Diffuse shader to bake the normal, but the baked normal is not same as from the procedural texture :


In Glossy shader, this results in some parts are reflecting brighter/dimmer in which they shouldn’t.


And this comparison above is from Diffuse shader. Note the one using baked normal has a slightly paler color.


In some cases that if the similarity doesn’t really matter, this is fine. But when some further vector calculation are based on this normal map, the final result would differ a lot more. While in my case, despite of the inevitable quality deviation caused by texture resolution and image filter method, I prefer precision.

I wonder whether this is some limitation for baking or my baking process is wrong.

Set your color management space to Standard before baking

1 Like

Thanks. Tried and the result is still incorrect.
By the way I don’t think View Transform matters as long as “Save As Render” is not checked when saving the texture. In the sample I save the texture in Linear space (non-color for normal map).

Don’t save as linear, save as non color

I have tried Non-Color and besides that I also tried saving in XYZ / Raw colorspace, but none of these is correct.

I also tried saving in OpenEXR format, didn’t make it either.
And tried different rendering API / hardware (GPU/CPU, CUDA/Optix), still getting the wrong result.

Can’t ensure my baking process is 100% correct (checked Veiw Transform to Standard / shading nodes / image colorspace) and cover all the combinations , but in my practice for now these are as far as I get.

I found a workaround for this setup :

  1. Try generate a normal-map-like texture then bake it using “Emit” bake type. (as below)
    image
  2. When baking, make sure that the Color Depth is using 16-bit or higher. In my test, using 8-bit will have incorrect values even when the Color Space is set properly (for Color Space, Linear/Raw/Non-Color can be used without problem).

I call this “workaround” because if this method is used, you will lost your original texture outcome, while the baking will have no problem.
Here are the nodes I used to re-build the texture :


Instead the former nodes setup transforming the normal vector in object space, this method sets a normal-map-like basis then do the vector math upon, so that it can be baked using “Emit” bake type.

At this point I was sure this is a baking bug and reported it in T102782 (if someone want to know if the bug is fix or its states). If the bug would be fixed, then the former texture can be simply baked without issue.


Another reason I call it “workaround” is that I failed finding a way to transform the former texture from object normal space to tangent normal space without resulting in differences.

I followed this to convert the normal but the result is still inconsistent. I felt the math is correct in my head and I have no idea why it comes out wrong.


So as a brief conclusion, in my point of view, unless the bug is fix, to achieve the precisely baking of glitter, the workaround should take place.