Home Unreal Engine

(Solved) Faint seams with modular normal map in UE4 and SP

polycounter lvl 7
Offline / Send Message
Klawd polycounter lvl 7
Hello polycounters! This is the premise:
I'm trying this new workflow for medium/large props. In short, what I'm trying to do is bake the least amount of normal information from the highpoly to the lowpoly, and then stretch/duplicate/mirror the various pieces to form the desired mesh. I'm using separate id channels for normals and for tileable materials, sort of like the trimsheet workflow.

At first I didn't notice any problems, then I started seeing these faint seams at steep light angles:




Below are the modules with which I built this specific piece of door (left highlighted is lowpoly, left non-highlighted is highpoly, right is assembled mesh)

I thought the error might be caused by the baker, but I checked the bake normal map file and all faces at the converging point have the same RGB color value (#8080ff).

Does anyone have an idea on what might be causing this error, and how it could be fixed?


Replies

  • Obscura
    Options
    Offline / Send Message
    Obscura grand marshal polycounter
    Is the normal map applied using the second uv channel?
  • Klawd
    Options
    Offline / Send Message
    Klawd polycounter lvl 7
    Hello @Obscura. Normals are on the first channel. (I think I had problems in the past using normals on channels >0 and since then I always kept them on the first channel)
  • Obscura
    Options
    Offline / Send Message
    Obscura grand marshal polycounter
    Alright. The reason for the errors when its applied using the second channel, is that Unreal doesn't generate tangents for the second uv channel by default so you need some extra material nodes to get it working correctly. Can we see the uvmap? have you tried different normal and tangent import and export settings?
  • Klawd
    Options
    Offline / Send Message
    Klawd polycounter lvl 7
    Yes, I have tried the various options at import, but nothing. The UVs are in fact where I think the problem with this approach is.

  • Obscura
    Options
    Offline / Send Message
    Obscura grand marshal polycounter
    I'm unable to reproduce the error with the test mesh I made. Can you upload the fbx?
  • Obscura
    Options
    Offline / Send Message
    Obscura grand marshal polycounter
    Also, I can see that the roughness map isn't seamless there, due to the uv splits. What happens when you remove the roughness map and use constant roughness? If that fixes it, then you should consider changing the uvmap that is used for the roughness map or to use world aligned textures.
  • Klawd
    Options
    Offline / Send Message
    Klawd polycounter lvl 7
    Uploaded a simplified example that shows the error: https://drive.google.com/open?id=1sxHFMkT0soPTR1E6IvO1TyVBuk3ipb0R

    (thanks for the interest btw!)

    the FBX contains 3 meshes. Highpoly, lowpoly, and the assembled final mesh. I baked the hp on the lp with a cage, then I assembled the mesh by stretching/duplicating the pieces. Here's the seam visible in substance painter with 0.3 roughness (when rendered in UE4 it's a bit more evident than in SP but this was quicker)

  • Klawd
    Options
    Offline / Send Message
    Klawd polycounter lvl 7
    Obscura said:
    Also, I can see that the roughness map isn't seamless there, due to the uv splits. What happens when you remove the roughness map and use constant roughness? If that fixes it, then you should consider changing the uvmap that is used for the roughness map or to use world aligned textures.
    Yes, that material I put on at random just to showcase the error, sorry. As you can see from the SP screenshot the seam is there also with constant roughness.
  • Obscura
    Options
    Offline / Send Message
    Obscura grand marshal polycounter
    Ok I will check it out a bit later tonight.
  • Obscura
    Options
    Offline / Send Message
    Obscura grand marshal polycounter
    Hello. Sorry for the delay. I'm unable to reproduce the error with your mesh too. I used "import tangents and normals" when importing the mesh into Unreal.
  • Obscura
    Options
    Offline / Send Message
    Obscura grand marshal polycounter
    Oops. Accidental double post.
  • Klawd
    Options
    Offline / Send Message
    Klawd polycounter lvl 7


    This is the result when I try importing the same test file I sent you into UE4 with 'import normals and tangents'.
    I have uploaded my baked map and the test file, could you try importing these into ue4 on your end?

    https://drive.google.com/open?id=1tpZpfymqIP93kOXunFl1HE47-nK8LuYZ
  • Obscura
    Options
    Offline / Send Message
    Obscura grand marshal polycounter
    So... Without the normal map, this one didn't show the error either. But once I applied the normal map, the seam appeared. Then I tried some another normal map, and the error was showing again. Then I tried to adjust the value position of the normal map in the material, and it fixed it. It looks like the midpoint of it needs to be moved by 1 when the map is in 1,-1 range (normal map compression) so this is a precision issue with the texture, and would likely appear with any 8 bit normal map. In 8 bit range, this would be a difference of 0,5 which couldn't be stored. Without this adjustment, it was showing the same error as yours. Here are the results after the adjustments:


  • Klawd
    Options
    Offline / Send Message
    Klawd polycounter lvl 7
    Well there is something strange happening, or something I'm missing. With your workaround I still get the error:


  • Klawd
    Options
    Offline / Send Message
    Klawd polycounter lvl 7
    The example you showed above without the seams, was it using your own baked normal map or the one I sent you? Also the FBX did you import the one I sent or did you re-exported it from your 3d suite before going into ue4?

    I'm thinking maybe it's something in my 3d suite export options, or my baker?
  • Obscura
    Options
    Offline / Send Message
    Obscura grand marshal polycounter
    Remove the multiply by -1. I redid everything to see what could be possibly wrong, and it looks like I saved the test adjustments in Photoshop and the fix was made with that saved in the texture. Sorry. Now in the new test with the untouched files, the multiply by -1 isn't needed.


  • Obscura
    Options
    Offline / Send Message
    Obscura grand marshal polycounter
    Still a precision issue though and still appears with any normal map, without the value shift.

    Also, I had to disable mipmaps on your texture because it was showing another error too. The uv islands are too close to each other so the other parts of the texture were bleeding in causing lines (not seams). This error looks different, you will see once you fixed the seam. So I would recommend leaving more space between them.
  • Klawd
    Options
    Offline / Send Message
    Klawd polycounter lvl 7
    Well, while this is absolutely fantastic, and I'll pay you a beer or two if we ever meet. And it also retroactively solved this problems on all my recent meshes, I still feel like I don't entirely understand what is happening and what is causing the error in the first place. I know I always bake in 16bit, but I don't know what happens when I import these into UE4. Is the error because of the way the normal map gets compressed when imported into UE4?
  • Obscura
    Options
    Offline / Send Message
    Obscura grand marshal polycounter
    The error appears in Substance too on your side, so I'm not sure if this is a fault of Unreal. 

    This is what the normal map compression does:

    1. From these tests, I would assume that the input normal map gets pushed into 8 bit first - this is theoretical, I'm not entirely sure, but it looks like this happens.

    2. Remove blue channel - Surely
    3. Stretch red and green channel out to 1,-1 range - Surely
    4. Derive the new blue channel from the stretched red and green channel - Surely
    5. Remove alpha channel - Surely

    We can confirm step 2-3-4 and 5 by putting random things into the alpha and blue channel, and we still get a correct normal map in Unreal, plus we can see that a correct blue channel appears in the normal map compressed texture when viewing it in the texture preview. The 1,-1 range can be confirmed by feeding the red or green channel into an "if" and comparing it with negative values. Removed alpha channel is obvious.
  • Klawd
    Options
    Offline / Send Message
    Klawd polycounter lvl 7
    It's not always adding a value of .004 that solves it. With the other meshes it ranges between .001 and .008. With one I had to subtract .02 !
    I'm baffled by all this, but having a workaround is still a huge thing for me!
    Thanks again @Obscura ! :)

  • Obscura
    Options
    Offline / Send Message
    Obscura grand marshal polycounter
    1/255 is 0.003921568.....many decimals here. 

    Ok, your last observation is strange and confusing, I have no idea how could that be, but at least it can be solved with a fairly simple fix.

    Can you please try the same thing with a 8 bit bake, and see if the post-adjustment value becomes constant, or still changes with the different meshes?
  • Klawd
    Options
    Offline / Send Message
    Klawd polycounter lvl 7
    Two of the meshes I did weeks ago required a subtraction instead of addition to make these seams close to invisible. One required .02 the other .01.
    The workflow between these meshes is entirely the same, these seams were more evident at the intersection with their mirrored side though, I don't know if that might be relevant. 
    I will without a doubt pay more attention now that I know what to look for. If I find anything new I'll be sure to report back here!

    Obscura said:
    Can you please try the same thing with a 8 bit bake, and see if the post-adjustment value becomes constant, or still changes with the different meshes?

    Yes I absoluely can
  • Klawd
    Options
    Offline / Send Message
    Klawd polycounter lvl 7
    WIth 8 bit baked map a NEGATIVE value between .004 and .005 fixes it
  • Obscura
    Options
    Offline / Send Message
    Obscura grand marshal polycounter
    This is ridiculous   :D Alright, thanks for trying that. I have no idea why is that but clearly, everything gets slightly shifted compared to what Unreal would want. The error appears with a fully flat normal map too. 

    I have one more idea to try, but after all of these, I doubt that it will do much. Can you try enabling "high precision tangent basis" and "full precision uvs" on the meshes and see if it makes the value constant?
  • Klawd
    Options
    Offline / Send Message
    Klawd polycounter lvl 7
    Obscura said:
     The error appears with a fully flat normal map too. 

    Huh?

    Obscura said:
    I have one more idea to try, but after all of these, I doubt that it will do much. Can you try enabling "high precision tangent basis" and "full precision uvs" on the meshes and see if it makes the value constant?
    Neither did anything. Never found a valid use for these options...
  • Obscura
    Options
    Offline / Send Message
    Obscura grand marshal polycounter
    Klawd said:
    Obscura said:
     The error appears with a fully flat normal map too. 

    Huh?
    Normal map with no detail on it:
  • Klawd
    Options
    Offline / Send Message
    Klawd polycounter lvl 7
    Obscura said:
    Klawd said:
    Obscura said:
     The error appears with a fully flat normal map too. 

    Huh?
    Normal map with no detail on it: 
    Oh wow, just tried on my side too, so very weird. I'm giving up on trying to understand what's happening :D

  • Psychotic_Mike
    Options
    Offline / Send Message
    Psychotic_Mike polycounter lvl 11
    I reached the same conclusion. 
    Its a precision issue of the normal map. the Flat area of the normal is not 128,128,255 but fluctuates between that and 127,127,255
    Your solution did not work for me as add/subtracting didn't seem to do anything. 

    What end up working for me was flattening the normal with a value of 2 (1 flattens the normal value above inverts it) that inverted normal then goes through a saturate node to clamp it. Only caveat is normals are inverted now - multiplying the normal with a 1,-1,1 constant vector inverts the normal but brings the seams back. 

    Maybe if I bake my normals inverted and do the above will fix that? (flipping green channel did not work either they still appeared inverted). 

    Here are some test results.

Sign In or Register to comment.