Cycles: Unknown seams appear on normal baking texture.
Closed, ArchivedPublic


System Information
Win8 64bit | GTX680

Blender Version
Broken: 2.72 a1d80b9

Short description of error
Unknown seams appear on normal baking texture. As far as I see, it is more obvious on 8-bit image texture when baking using Tangent space.

Exact steps for others to reproduce the error


Leon Cheung (leon_cheung) updated the task description. (Show Details)
Leon Cheung (leon_cheung) raised the priority of this task from to Needs Triage.
Leon Cheung (leon_cheung) set Type to Bug.

Update: After saving the baked image as an external file, all seams gone. But I'm still wondering what the problem is. :(

Could be color space issues. Will have a closer look later, or maybe @Dalai Felinto (dfelinto) will be faster than me :)

Sergey Sharybin (sergey) triaged this task as Normal priority.
Julian Eisel (Severin) lowered the priority of this task from Normal to Incomplete.Feb 19 2015, 5:14 PM

@Leon Cheung (leon_cheung), could you test again? There were some fixes regarding baking recently, so fingers crossed this has been fixed as well

@Julian Eisel (Severin), I just did a test with the latest build, I'm afraid it still occur, and one correction about this is: it occurs on 32bit image, too. I thought it was something about the color that holds the normal data at the outer border of the two UV islands, not so sure about this, just still wondering why it specifically happen with Cycles.

The problem here is: For the same normal map (exactlly the same one), the "seam" only occur in Cycles, not BI.

Julian Eisel (Severin) raised the priority of this task from Incomplete to Normal.Feb 23 2015, 12:17 AM

I can't reproduce the issue here. See the file:

I'm using Blender Internal, and not Cycles to preview the produced baked map.

If the problem is that a normal map produces different results in BI and Cycles than it's not a Baking problem, but a Cycles Node problem.

@Dalai Felinto (dfelinto), I also think it is something about Cycles only. Just tested with your file with Cycles, it still appears there (though not so obvious), but still different from what's in BI and BGE, not sure if something wrong with my setting?

(this time, the normal map is baked using BI, so I think it might not be something about baking)

If "this time the normal map [was] baked using BI" than the problem is not with Cycles Baking.
(we may have the problem there as well, but I would suggest isolating the problem from the Cycles Baking part of it, so it's easy to see what is going on)

Have you been alternating between CPU and GPU rendering? For me, with CPU baking, the error was almost imperceptible and it was only in one small area towards the bottom.

After several tests using both of our set-ups I saw nothing as bad as what you show.

Maybe the CPU is able to work with some double-floating point precision math so the bake turns out cleaner. I'm only guessing. :)

I was able to repair the UV coordinates and so the errors no longer appear in the baked result.

UV's should be sectioned off into roughly 90˚ quadrants to start off with. Pay attention to the polygon flow so the seams 'fit' the models polyflow.

Each UV island should be treated as if it were made of slightly stretchy paper; but still paper that will tear if you push it too far!

For a proper bake with no seam artifacts: A UV Island should closely match the shape and size of the 3D Viewport geometry polygon flow best as possible without making too many seams.

  • If you were to print out a UV map using a color printer and then attempt to wrap those real pictures around a real live 3D object, you would have to stretch the paper to make it fit around corners of the model if the whole island is one or two big blobs.

Trying to do things with UV's that you could not do with real printed images on paper will affect the quality of your baked maps. All bake-pass types will be affected.

Some of the problems that you will encounter when UV's are stretched is that texture resolution will vary across the map so that some of the texture looks high resolution and some of it looks very low resolution.
There may also be obvious stretching where the image appears to be mapped across the surface like it's made of partially melted plastic.

If you examine the shape and size of a quad on the 3D mesh, you should be able to recognize that same quad when you look at the UV coordinates. Each geometry component should look very similar for both 2D and 3D views as best as you can get them to.

Ideally, the UV islands should be marked with seams so that they are all flat and proportional to the 3D mesh components; but this has to be counter-balanced against having too many islands.

Island spacing reduces available texture resolution and so now, the seam problem becomes exaggerated and there are more seams to show off the errors caused by low-texture resolution.

  • If the UV's are stretched; the math which transfers the 3D model ray-hits over to the UV positions could start to break down with precision round-off errors quicker than they normally would if the polygons had been proportional, symmetrical, and evenly spaced.

I wonder if there has been a regression since the following report was resolved.

I don't think it's anything to do with the baking at all, you can set image colors to (0.5, 0.5, 1.0) and you'll still see the seam.

Not entirely sure why exactly it happens, needs some closer look.

Ok, @Andy Davies (metalliandy) @Morten Mikkelsen (mmikkelsen) solved the mystery :)

The issue is neither in baking nor in mapping itself, it's in the nature of 8bit textures which can't really represent "middle" point of (0.5, 0.5, 1.0) due to lack of precision and gives 0.50196 for red and green channels. Sure enough this distorts normals a bit and because of discontinuity in the tangent space it causes visible seam.

Proper solution is to use 32bit textures, nothing really we can solve from the code side. And so far i can not see issues with 32bit textures in this report. Please correct me if i'm wrong.

So thanks for the report, but closing it now.

Sergey Sharybin (sergey) closed this task as Archived.Aug 27 2015, 1:50 AM

Thanks a lot for targeting it finally!

I just wanted to chime in and say that while 32bit float does fix this problem, unfortunately it isn't really a workable solution for the purposes of most production (realtime at least) as 32bit float textures are a massive overkill for normal maps in terms of wasted memory and other resources. This is especially true for things such as games as the texture is going to be compressed down to DXT1/5 or at best BC5 anyway.

16bit Integer textures are the best bet when baking normals as they give an excellent increase in unique values per channel which solves 99% of visual aberrations such as banding etc.

@Andy Davies (metalliandy), yeah but there's no 16bit support in blender, textures are getting converted from 16 to 32 bits on load. Wile using 16bit textures helps reduce overall size of your assets it doesn't really help runtime-memory-wise.