Normalmap left/right Y flipped depend on point of view issue - help :)

Troubleshooting graphics
1

Hello, i hope someone will know/remember how to solve this issue. i would really apprecaiate.

Problem appear when looking at model from Left/Right side. (Camera light is ON)

  • screenshots from SDK 3.2.2 preview, in game 3.3 alpha also same issue
  • model was mirrored, but UV was generated on full mesh
  • normals were recalculated outside in blender, so are fine
  • same both results when baking normapmap in Materialize or in Blender nodes

from Left(default Y):
normalFromLeft

from Right(Y is flipped now for both sides):
normalFromRight

From Middle(it looks ok):
normalFromMiddle

in Blender evee(PBR mode) it looks fine:
normalBlender !

normalmap have seam there, but it have “bleed” 20 pixels, anyway problem is about left/right side have different Y.

2

In the second picture it looks like your normal map is inverted - going out instead of in. The PBR shader has a setting for this. I don’t know if blender lets you choose normal map formats or not.

1 Like
3

it dont help ;/

if you mean “flip option” then not, it totally breaks model. it looks like inverted like you say, but look at normalmap image, its not mirrored, its all mesh UV, all face.

i seen similar topics, where people were fixing TangentGenerator, but it was fixed in previous versions. so i trully dont know why i got this issue.

  • face normals are fine,
  • tangents generated(tried true param too)
  • baked normalmap in both Materialize and blender node system way, both have issues.
  • tried MikktspaceTangentGenerator, but had some issues. (java.lang.NullPointerException
    at com.jme3.scene.Mesh.prepareForAnim(Mesh.java:494)) - yes odd,
    like new animation dont work with MikktspaceTangentGenerator. (while TangentBinormalGenerator no problem)
  • verified UV grid, they are not flipped any direction. all have same.
4

also please note its not first time i had seam issue, so i belive its connected. (usually it was small seams, because normalmap had little effect, so i just made them in less visible places)

just now i see it show flipped normals for each seam side.(its strongly visible on this screenshots)

so if this would solve, then all normalmap seams would be solved.

JME should work with it, like Blender or other engines do.(as i read from other topics)

so please help to solve this.

i remember @thetoucher said:

My issue is not seam margins, its the fact the edges of the seam islands do not point the same way in the uv layout as the seams they join, so each edge has a completely different tangent =/

and i think its about the same, so its like common issue.

5

i just found odd thing:

raw head export from blender .gltf to JME(looks fine on both sides):

normalJustHeadGltfExportTangents

only thing i did was Apply JME PBRLighting material with same textures and similar parameters.

normalJustHeadGltfExportTangentsAppliedJMEMaterial

so now:

im curious whats the difference between JME material and .gltf imported material, because the only difference is Material…

can anyone explain me how is builded .gltf imported material?

6

i found how to “make ugly fix” for this.

but still, JME have some odd issue.

All i did was increase normalType from 0.1 to 0.5 and issue disappeared

seems like JME have some issue when normalType is low

im not happy if now i need re-generate all normalmaps to be prepared for normalType > 0.5

7

Are you sure that’s the only difference? So you also generated tangents in the second case?

What format were you importing before? Was it always gltf and the only different a setMaterial() call?

8

one moment, i will prepare some examples for you to show.

9

o_O

        //The type of normal map: -1.0 (DirectX), 1.0 (OpenGl)
        Float NormalType : -1.0

According to the docs, neither of your values really make sense.

Edit: looking at the PBR shader, if NormalType is something other than -1 or 1 you will get strange results.

10

yes, i thought i can give even -100 or 100, but would look ugly.

But look this examples, there is definetyle something wrong about low(not minus) values.

minus is wrong, ok, but why anything lower 0.5 is bad?

i mean, i thought i can use normalType for NormalScale. isnt it for this? if not then why its not boolean like “dx” or “opengl”

here examples:

bvc1mat
bvc1

bvc2mat
PNG

bvc3mat
PNG

bvc4mat
PNG

bvc5mat
PNG

bvc6mat
PNG

bvc7mat
PNG

bvc8mat
PNG

11

There is something wrong with your tangents is my guess.

But the normal type is correcting for normal maps that have their y channel inverted. That’s all. Only 1 or -1 make sense because in one case we are flipping the green value and the other we aren’t.

12

Edit: looking at the PBR shader, if NormalType is something other than -1 or 1 you will get strange results.

you are correct.

value 2 give same issue.

but why 0.4 too?

13

I mean, do the math and think about what the different y values might be in your normal… 0 to 1 gets translated into -1 to 1 normally. If you give normal type bad values then you will get strange normals. for 0.4 I think this would be 0.8 to 0.4 instead of 1 to -1.

Edit: sorry, I’m bad at math right now. 0.4 to -0.4 I guess.

1 Like
14

By the way, is there any reason that you split your forehead UVs down the middle like that? It seems an odd place to make seam… though I admit my knowledge of unwrapping is very limited.

15

you see, i probably just wrong underatand normalType param.

thought i can give basically -1 to 1 values, because it was said before by someone this are default values. and i remember this.

could you explain me what is normalType (if i am able to understand), because i thought i could use it to manipulate normalmap intensity.

i could use always value “1” and there would be no issues i understand?

so lets say i will always use value “1”, but is there some parameter, or some Shader change i could add to make “normalMap” have more "intensity"

16

By the way, is there any reason that you split your forehead UVs down the middle like that? It seems an odd place to make seam… though I admit my knowledge of unwrapping is very limited.

yes, i have reason. earlier i didnt do this way, but i found that UV grid looks much more better(is not so stretched) if people do seams this way. Some of youtubers say it give nice result and it trully give.

17

This doesn’t make any sense. What is the “intensity” of a 3D vector?

I already explained what normalType is doing. It’s allowing the use of two different kinds of normal maps. One with y inverted and other not.

18

This doesn’t make any sense. What is the “intensity” of a 3D vector?

in other words:

i would like to increase intensity from normalMap reflection (specular of normal map? or however name it).

reason?

i would like be able add in character customization something like “age” param, so if more, then more dark/light normalMap effect intensity, so wrinkles are more visible.

19

something like strength here:

ccccccccccccccccccccccccccccccc

20

Then probably what you really want is a not-physically-correct hacked PBR where you apply the RESULT of the normalmap + lighting calculation by blending different values.

You definitely can’t get what you want just by scaling the y of the normal map… because as you’ve discovered the y in the normal map isn’t always the y in the model (that’s what tangents are telling us… which way is ‘up’)… and that’s why you see seams when you use strange values.

You also can’t get it by just scaling the normal from the normal map as it can give strange lighting results. Just like if you took a 3D vector and scaled it down. I mean, your dot products with the light vector will be scaled but not in the linear way you’d probably want.

No matter what, you are going to have to hack the shader to get what you want.

1 Like