2
$\begingroup$

I am trying to render the Normal output of the geometry node, and then bring that back as a window projected texture. But when I do, the image is very different from the original socket output: enter image description here

Why is my image different, when its literally just a render of the same thing? I am aware of color management distorting the render. I have tried rendering with different Display Devices, View Transforms, both .png and .exr, different color spaces on the texture node, disabling Save as Render, etc.

From my understanding, being in Display Device: sRGB, Standard view transform, and then setting the texture node to Linear or Non-Color Data ought to work, but it doesn't. What else could be going on?

Improve this question
$\endgroup$
2
  • $\begingroup$ What is your node setup when rendering normals? just normal plugged as surface in the material output? $\endgroup$
    – lemon
    Commented Sep 5, 2020 at 8:27
  • $\begingroup$ Yes, nothing special to the setup. $\endgroup$
    – Ascalon
    Commented Sep 5, 2020 at 19:36

1 Answer 1

Reset to default
2
+50
$\begingroup$

I think the main cause of the differences is the way data is encoded when the normals were rendered initially.

If you save that in jpg or png, colors are encoded as integers. So that leads to some rounded values that cannot be converted to the exact initial normal values.

So you can save this rendered file with OpenExr format to keep things as float values:

enter image description here

(codec can be "none" or "zip looseless" for accuracy, if needed... give a try to the codecs depending on what you want, file size vs. accuracy).

The result can be this (not perfect though):

enter image description here

Instead of this using png:

enter image description here

Additionally, keep the image texture as "non color" or "raw", and as you said in the question, set "raw" and "non color" in the color management part.

Edit: other thing that alter the rendering is anti aliasing. If using Cycles, set the pixel filter to box in the film section. Rendered back using the image texture projected on the window should give a better result.

Improve this answer
$\endgroup$
9
  • $\begingroup$ Sample the normal and it will become very clear why this answer suggesting to save to EXR is correct; the values will have negative components, which display referred image encodings will have extremely limited support, if any. Perhaps this can be reflected in this answer to provide more information as to why the encoding to those formats fails? $\endgroup$
    – troy_s
    Commented Sep 5, 2020 at 19:02
  • $\begingroup$ I have tried .exr and while the results were better, they were not close enough to use without getting distortions. If I bake object normals to textures, I don't get these problems, even with PNG. Why is baking fine, but rendering not? $\endgroup$
    – Ascalon
    Commented Sep 5, 2020 at 19:38
  • $\begingroup$ @troy_s, effectively, but as I asked below the question I did not know if the normals where rendered directly or corrected to be positive. @ Ascalon: if normals are rendered straightly, negative values (so black). Is that the rendering you want? $\endgroup$
    – lemon
    Commented Sep 6, 2020 at 6:23
  • $\begingroup$ @Ascalon, could you complete the question providing the exact way normals are rendered to generate the texture? and also if possible a sample mesh. $\endgroup$
    – lemon
    Commented Sep 6, 2020 at 6:30
  • $\begingroup$ @Ascalon, have tried to bake instead of rendering and still have differences. Could you show what you have experimented editing your question? Thanks. $\endgroup$
    – lemon
    Commented Sep 6, 2020 at 7:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .