"Anormal" Map... bumping on inconsistencies


#1

Maybe I’m completely wrong, but it seems to have some inconsistencies with the rendering of the bump map in HF. I know this is a bit a “fake” effect, but is it not supposed to be coherent with the light direction?

In this picture for example where the shadows in the bump effect is completely in the wrong direction that the key light:

You would say, yes it can be tricky and bumped versus carved can make illusions…
but then how do you explain that one:

image

Same carving on the same parallel plans… One look good the other has the light coming from… the ground!?

It seems to vary based the orientation of our view… sometimes it becomes consistent:

I’m been checked if it was not my UV map who could have something inversed… it’s not that.

Here a piece of my normal map…
to prove you that what I pretend to be carved and bumped is the real thing.


#2

I think this is related to the direction of the UV map and id it was mirrored or latest of another.

This has been an absolutely long standing issue that I reported ages ago. I wish something was done about it

You should probably check the normals also using Luci (the materials debugger) maybe that will tell you how the client is doing it wrong.


#3

Sometimes I’ve had problems like that with normal maps just because I forgot to set them to OpenGL rather than DirectX maps. But then again, I seem to be wrong rather than right most of the time and it is probably something else.


#4

I checked with Luci (very useful).
It seems that for the 12 faces, only 1 have the normal map rendered not inverted.

Which doesn’t make sense since it’s 1 bump texture applied on 1 UV maps where the polygons fit as seen “normal up” (nothing is inverted).

I try with the default cube, I get the same thing… 1 face only works as expected over 6. This is even present in the blender preview.


#5

Where are you setting that? In blender ?


#6

He possibly means some of the normal map settngs there are in tools like Substance Designer. If the normal map works in Blender, it should work in Hifi (after all both are OpenGL Based) as the green channel between both is inverted.

While I think your center normal map is the wrong way around, but the other thing is having some issues that I experienced.

Generally however, this specific issue you are having is high fidelity specific.


#7

So, my map has probably an issue, since the bad behavior seems to not be the exception in that specific case. I will go deeper in my investigation about how exactly it’s structured in the map it self.


#8

I pushed a bit the investigation using the Luci script and validating the vector of some pixel to figure the simulated orientation of the surfaces that the light hits.

With a FBX (From Blender at least), I came to the conclusion that there is a problem with the orientation of the normal of some polygons. (which is I supposed, is used to with the vector of the normal map to calculate the surface orientation.


You can see the difference between the central pink area and the one on the left (that is the buggy one)
On the left one, the cyan is on the horizontal axis, and in the central one it’s on the vertical. This means that the map is the same, but the normal of the polygon is rotated!


Here it seems consistent, but if you calculate the vector of the pixels on the edge of the crosse it’s not pointing in the expected direction.

Then I tried with an OBJ. (Same .blend file but exported as obj.)
This is already more consistent.


The problem with the normal of the polygon of the left is not present.
If we calculate the vector of the pixels, this appears to point in the correct direction, which respects the normal map.


Same here… vector are also correct.

However, with that “normal vector consistent” .obj, the rendering is still incorrect:


it’s inverted vertically on some orientation. (here it’s inverted vertically)

So… I hate Blender’s FBX a bit more now :wink:
It’s just not trustable at all, except if you want to get corruption.