Problem with Normal maps exported from photshop

DiscothunderX

Hello everyone.
i got a problem everytime i try to edit 2 normal maps togther in photoshop.
after i export my final normal map and view it in substance it shows with alot of artifacts and kinda pixilated

tried to export it with huge scale same problem
i also tried to disable sRGB in export settings also same problem.

Fabi_G

What do you mean by "edit 2 normal maps together"? Showing either one or the other based on a masks value? Is it not possible to do it inside Painter (e.g. set normal mixing to "replace", mask in other normal map)?

DiscothunderX

i mean fixing skew that happens due to average normals

poopipe

you really don't want to be painting into a normal map by hand 

the fix is to not bake with averaged normals, set up your hard edges/UV splits properly and you won't get the skewing

DiscothunderX

i think what i want to say is kinda not clear enough, ofc its my bad sry all.
but what i mean is that i combine 2 normal map layers
1st layer is the normal map baked with average normals

2nd layer is baked without average normals
to get the final normal map which i am using in the first (Model)picture

poopipe

I get what you're trying to do - I see this all the time. 

What you have after this process is a normal map that doesn't work with your mesh regardless of whether you use averaged normals or not . 


Bad practice aside though..
I don't think thats necessarily the root of the artefacts in your original  image - there's a better than zero chance that Photoshop is applying some sort of color transform to the image on import and/or export.  If you completely disable color management it should (in theory) not destroy your image

Fabi_G

Of course you could add support loops to the edges to control skewing. Assuming the shading between modified and original is consistent, could even apply textures to original. Adding support loops to an instance of the mesh using something Blenders Bevel Modifier would keep both in sync.

Eric Chadwick

Have you seen these tutorials yet?

• Of Bit Depths, Banding and Normal Maps
• Skew you buddy! Making sense of skewed normal map details.
• Understanding averaged normals and ray projection/Who put waviness in my normal map?

DiscothunderX

Well This i know this problem can be fixed easy with Marmoset toolbag using the Paint Skew put some times i want to used photoshop for simple and fast projects as marmoset needs some kinda of a setup to get a perfect bake

Eric Chadwick

Poopipe alluded to this but it should probably be stated more specifically… retouching a normal map that’s baked into a non-tiling UV is really bad workflow. 

The bake process creates normal map colors depending on the vertices of the model and which direction the vertex normals are pointing.

As soon as you start painting or masking or blending, you’re breaking that baked connection between the map and the vertices. Which means  you’re likely to see shading problems.

You can usually paint out small errors without much risk, but it’s a bad workflow that makes the process slower over time in actual production.

There are often changes required during a game, and those often require rebaking. Better to fix those projection errors at the source.

iam717

Too add, & i found the cage is not just to keep objects outside of the target object from being projected it actually matters, i learned this via switching bakers, xnormal created cage, vs, say marmoset/3dsmax/any other application. 

(cause for some reasons, xnormal almost always hates any cage it didn't create, or that has been my experience with it.) 

Also perhaps and including the application you use to bake, whatever math they used, unless they all bake the same way? 

Which i couldn't test, if there is some sort of test thread where information is shown, I'd be interested in looking it over.

  

(i do remember someone talking about it, but can't peg the year cause i can remember things from a very long time ago and that doesn't help.) edit:

To add more about the cage, i would say if someone could calculate or script up some sort of automated distance field algorithm to detect the cage edge (or vert to vert) and make the smallest push from the normals of the vert or custom (typed in) direction/angle. 

To calculate the "perfect" distance possible from the reference mesh (the high) to the source (the low) everyone's bakes would be "very nice".  I am almost sure someone already did this, or some studio. 

The distance i think matters because of the same lighting the mesh would receive, i got into the habit of expanding and going, i think the same "love" and time should be taken with the cage as it was to model the "low" or i might be mistaken and the cage doesn't matter as much as i think it does? 

I brought this up when trying to overlay normals baked from one onto another and saw some sort of shift in the lighting/angles of certain parts of the meshes i played with.  (i do a lot of testing on stuff and things/methods) perhaps others have seen this as well?

Example: like knalds version of a normal map, vs the original as a rough example to look at quickly. (not saying anything bout knald, it is an example to reference to see what i mean.)

gnoop

I suggest to check the topology and vertex normals of your model first.   Those  gradients  you see  there  exist most probably  because of vertex normals in corners of any surface supposed to be flat  having some random subtle inclination .   Ideally you model shading of such hard surface  things  should show  perfectly flat  , gradient-less shading BEFORE normal maps are baked.   Check it by applying  any reflective material . 

If it's the case you have a number of tools to work with vertex normals: copy /paste , project from  other geometry, clever use of split /hard edges, support edges, face weighted normals  etc.    It's a bad practice to fix  shading artifacts by a normal map.