Bad reading of normal map

[Acrom]

Hi,

I am rendering some test and i have a problem with the normal map and Octane. I attach 2 examples with red zones where Octane flips the normal map. Native render of lightwave works fine.

any idea?

thanks!

[juanjgon]

Hi,

The normals seem inverted or something like that. Do they come from an 8-bit file format, like a JPG or PNG? I ask because in this case the problem can be related to the gamma correction in the texture image node.

Thanks,
-Juanjo

[Acrom]

Hi,

I have rendered in EXR format and the problem is the same. I have set the gamma of texture image node to 1 but the problem continues...

Thanks!

[juanjgon]

Hmm, I'm not sure what could be the problem. Have you tried to invert the texture to see if it helps? If you want to share the scene, I could take a look at it here.

Thanks,
-Juanjo

[Acrom]

Ok Juanjo, i attach the content. In the scene, the two materials are ready (LW and Octane). I attach a JPG too.

Thanks!!

[juanjgon]

To be honest I don't know why the Octane normal mapping doesn't match the LW one. The texture flip works, but what I don't understand is why the map is good for some objects, the left ones, for example, and wrong for the other objects. I wonder if the problem is the object vertex map, or perhaps the way used by Octane to apply the normal maps using tangents or something like that.

If I find something I'll let you know, but meanwhile, you are going to need to use different materials for the left and right objects and use the texture flip to fix the objects that are wrong.

Thanks,
-Juanjo

[Lewis]

I think that goes way back to v3 or so, i had some similar problems on some older projects where sunny side of building wall looked wrong and shadow wall opposite to that looked right and they were using same materils/normal map.
I though it's just an illusion and i never checked in native but now when i see this topic i'm pretty sure it's octane BUG/issue.

[milanm]

Yes Lewis is right, actually this goes even further back than V3...

Long story short, there are two long standing issues with normal (& bump) maps in Octane:

1. They depend on UVs. If you mirrored your object, but kept UVs as they are, your normals will be flipped. To fix this you could create a copy of a material with a flipped (inverted green or red channel) normal map and assign it to the flipped part of the mesh. Or you could flip one of the channels of the normal map in your shading network. See this.

2. Depending on the camera angle, they might not render correctly. This can be solved (to some extent) by replacing the blue channel with a constant linear value of 1 (or 255 in 8bit) or by reducing the intensity of the normal map in the ImageTexture node. You could also use falloff to reduce intensity of the bump/normal on the edges. See this (apologies for the huge post, I hope those gifs help explain this).

Cheers
Milan

[Acrom]

Thanks for all answers.

Juanjo, can you report this problem to the Octane Team? I think that is a big issue they have to resolve.

Thank you very much.

[trogers]

Hi, I've been dealing with this same issue over the past week trying to get my normal textures to look right (not flipped) on a non UV'd geo using triplanar projection. I have had some luck in UV'ing the geo and flipping the individual UV islands, but not only does this not make any sense to have to do when using triplanar projection, it's a huge hassle to have to correct.

In researching this it seems that that this is a long standing issue not just with Octane, but with normal mapping (particularly in relation to triplanar mapping) in general across the industry. I came across this article on Medium by Ben Golus that addresses this issue directly: https://medium.com/@bgolus/normal-mappi ... bf39dca05a In the article he not only explains the reasons why this happens, but provides the code necessary to solve the issue: https://github.com/bgolus/Normal-Mappin ... nar-Shader The solution is written for Unity, but I'm sure could possibly lend some insight into how this problem could be solved within Octane.

I'm wondering as well, while we wait for a fix, if anyone here has enough familiarity with OSL to try and port over Ben's solution to create an Octane projection node that could be shared with the community.