Page MenuHome

Baking tearing normals (Both cycles and BI)
Closed, ResolvedPublic

Description

There seams to be a bug that normal are teared sometimes this happens with both Cycles (with or without cage) and BI.
Here is the scene setup:


This is tangent normal map I got by baking in Cycles with cage, you can see that middle row of bolts is teared sometimes:


I thought there might be a problem with my geometry, but I checked in xNormal it doesn't happen:

Event Timeline

Andrej Ivanis (aivanis) raised the priority of this task from to Needs Triage by Developer.
Andrej Ivanis (aivanis) updated the task description. (Show Details)
Andrej Ivanis (aivanis) set Type to Bug.
Sergey Sharybin (sergey) lowered the priority of this task from Needs Triage by Developer to Normal.Feb 17 2015, 10:16 AM
Julian Eisel (Severin) triaged this task as Needs Information from User priority.Feb 19 2015, 3:31 PM

Tried to recreate but getting an error: Error: Uninitialized image "test" from object "fence2_LOD0.008_Circle.009". I'm a noob when it comes to baking, but seems like you didn't pack some images?
Also, could you test if the issue still appears in the latest buildbot builds? Some information about your OS and graphics card might be interesting as well.

Hi,
I just tested with 2.73.8 version (I downloaded few days ago) and it still appears. Sorry about the error either change image source to generated or here is fixed file

, just open it and press bake.

OS is Mac OS 10.9.5, graphic card NVIDIA GeForce GT 650M 1024 MB

I get tearing when I bake with either CPU or GPU and also it doesn't appear just on normal map, but on other maps too.

Julian Eisel (Severin) raised the priority of this task from Needs Information from User to Confirmed, Medium.EditedFeb 21 2015, 8:15 PM

Need @Dalai Felinto (dfelinto)'s brain here! Maybe there's something wrong in the file?

@Andy Davies (metalliandy) I haven't tested/checked the file, but if BI has this issue as well I think you could possibly help with other tests (xnormal, ...). Thanks ;)

Interesting. I will take a look tomorrow

From an artists perspective this is easy enough to deal with until a code solution presents itself.

Add some control loops so the geometry is not as long and thin.

To delete the loops afterwards:

(i) Select them all,

(ii) Use 'x' then 'g' to remove them.

Keeping the quads closer to being square shaped also helps to eliminate the oval shaped stretching that can be seen on the end bolts.

You should rebuild the cage since it looks like adding loops can invalidate the cage. Maybe indices are no longer in the proper order?

Forgot to check this. Sorry!

Marc is correct that adding extra loops can control the projection of the bake, though I must say that tearing is a very unusual symptom as normally the geometry skews when the rays are averaged across the surface.
In addition the centre of an object is usually projected correctly with the ends skewing, so the tearing is quite worrying as is definitely a bug. The tearing doesn't appear in xNormal using unmodified geometry.


I just wanted to point out that while Marc is totally correct about the add/remove loops trick, it should be noted that people shouldn't really be doing it when baking directly to tangent space maps. It's an extremely destructive process and will break your normal map as it encodes data based on the geometry present at the time of the bake and once that geometry is gone it will still try to compensate for it resulting in broken shading.
You can however add extra loops, bake to an object space normal map, remove the loops and then convert back to tangent space without such worries (following Marc's steps)

Andy makes a good point about baking to Object Space maps first.

Here's more detail on how to prepare a model for texture baking when using Blender's Selected to Active Tool. I posted it to B-Stack Exchange since it's more user-help then debugging. ;)

http://blender.stackexchange.com/questions/27042/how-can-i-bake-textures-without-artifacts-until-the-time-that-the-following-baki/27043#27043

Andy, feel free to comment on any mistakes or omissions I may have made in that post so they can be corrected.


I think it's often better to work with geometry that is made up of proportional, evenly spaced quads just as we'd do for curved animation models in regards to polygon flow.

It seems as if evenly spaced and proportional geometry is able to guide the rays in a way that reduces floating precision errors.

  • We can see a weird little unit-circle 'math black hole' in action by squaring a series of numbers when their values are greater than 1.0; then comparing the results against what happens when that series of numbers is then squared using their less than 1.0 counterparts. (x > 1.0 versus x < 1.0)

an example:

  • 5.0 x 5.0 = 25.0 <-this moves away from 0.0 (and is 5 times larger)
  • 0.5 x 0.5 = 0.25 <-this moves towards 0.0 (and is 50% smaller)

(i) Small numbers collapse down to zero when multiplied against other small numbers, the smaller they are, the faster it happens.

(ii) Large numbers can cause the small decimal numbers to become truncated because of floating point round-off which is biased towards preserving the larger numbers. The larger the spread between the high and low values, the worse it gets.

(iii) Multiplying large numbers against small numbers exaggerates the problem further because the very small numbers can quickly collapse the large numbers down to near zero.

If barycentric coordinates are being used to map ray/position hits over to the UV coordinates; long thin triangles may prove to be especially susceptible to floating point round-off errors along one axis more than the other.

I have no idea if that's the case here, and no solid idea how to fix it even if this is part of the problem. :(

Hey guys, @marc dion (marcclintdion) was partly right (it's about floating point precision). Took a while to find and fix it though... I hope I've done it right (D1207) :) Any idea who could do review??