Normal map "neutral" color

[speltrong]

Hi

I'm trying to build custom normal maps. I got most of the steps down, but I'm noticing that the Geometric Normal pass seems to be displaying "neutral" blue as R:87, G:82, B:240 (#5752FO). From what I've been reading, neutral blue in a normal map should be R:128, G:128, B:255.

I've tried setting up a parallel camera to make sure this isn't a result of distortion or something like that - same result.

Is this a bug, or is there something I'm doing wrong, or does it not matter if the color is 128/128/255?

EDIT: Looks like it's the same in Octane Standalone, which I always forget to check - I'll ask in that forum as well, but keep this here in case anyone has any ideas.

Win 10 Pro/C4D S24.111/Octane 2021.1/NVIDIA studio driver 471.68/GTX 1660Ti

The resulting normal map, saved from the live viewer

camera setup: plane is parented to the camera so it's being shown dead-on at all times.

[elsksa]

Hi, without going to deep in the math, the color encoding, normalization (etc...) behind it, I would like to highlight two important aspects:

• The "sampled values" via a "color picker" are "processed". In other words and simply said: they have been encoded to Linear-sRGB then conformed to sRGB (with "an" sRGB EOTF applied, mistakenly known as "̶G̶a̶m̶m̶a̶ corrected @ ~2.2").

• Contrary to a "bump map" that can be greyscale and single-channel, the normal map is an "R'G'B encoded data map" containing "angle information" and where R'G'B' color information values correspond to the X, Y and Z coordinates of the surface normal. The blue being the F0 (facing) information, Red for right direction information and green can be inverted due to the different interpretation (OpenGL vs DirectX) for the tangent space, for instance. This is what the "colors" represent. Nevermind this paragraph is this information was already acknowledged.

Here is an example below showing "neutral blue (...) R:128, G:128, B:255" (display referred) on a simple Octane's geometry primitive set to "cube" (works for "quad" as well) in Octane Standalone:

[roeland]

The Geometric normal pass gives normals in world space. For a normal map you probably need the normals in camera space, but Octane doesn't directly support that.

In 2021 you can create a global texture AOV with an OSL texture that outputs the normals:

• You will need to use the new Render AOV group
• create a Global texture AOV
• create an OSL texture for the Texture input and enter this shader:
  

  Code: Select all

  shader OslTexture(
      output vector c = 0)
  {
      c = transform("world", "camera", vector(N)) * 0.5 + 0.5;
  }
  

At this point you can save the resulting render pass as EXR without tonemapping.

At the moment the global texture AOVs are always interpreted as color but the normal map is non-color data. If you want to save it to PNG directly you need an extra step:

• In the AOV output group add a new AOV output.
• Disable imager and postprocessing in the output settings.
• Go to the settings under Layer 1, and then to Input, and change the combo box with the render pass to the global texture AOV created above

[speltrong]

Thank you @roeland!

Camera-space vs. World Space was the missing component in my thinking. When I zeroed out the camera and put the background plane straight up and down along Y, I got the neutral color I was expecting.

I'll give the OSL texture a shot next to see how that differs. Thanks again!

[speltrong]

Also thanks for the reply @elsksa - that's useful information as well

-s

[jobigoud]

Instead of the custom OSL it should also work with the new Normal texture node, setting Coordinate space to Camera and checking Normalize result.

[speltrong]

Instead of the custom OSL it should also work with the new Normal texture node, setting Coordinate space to Camera and checking Normalize result.

This is great - I had no idea this node existed because it's not in the list on the left in the node editor, and doesn't seem to show in any dropdowns in the C4D interface.

-s