Page MenuHome

Fix T43696: Baking tearing normals (Both cycles and BI)

Authored by Campbell Barton (campbellbarton) on Mar 29 2015, 12:17 AM.



This fixes T43696. Problem was accumulation of floating point precision errors in zspan_scanconvert function.

Diff Detail

Event Timeline

Krzysztof Rećko (chrisr) retitled this revision from to Fix T43696: Baking tearing normals (Both cycles and BI).
Krzysztof Rećko (chrisr) updated this object.
Sergey Sharybin (sergey) edited edge metadata.EditedApr 3 2015, 11:21 AM

Couple of questions:

  • Would it help to just make u and v double?
  • Why exactly this code affects Cycles backing?

EDIT: Just making them doubles is not total solution (you still need to avoid accumulation of the problem), but making them double could avoid more precision issues?

@Sergey Sharybin (sergey),

  • Yes, it does help, and probably was done like this at some point (typecasting to double all over the place), but from the point of numerical stability, this is much better anyway - I don't know how extreme would the conditions have to be, but I can imagine the problem showing up with doubles too (it's like postponing the issue until there is more powerful hardware to do very large bakes). We can change to double anyway if you think so but I bet it's not necessary...
  • This function for some reason is used to compute barycentric UV for each triangle on the bake. In case of long triangles, and high resolution of the bake - the errors add up and UVs are not distributed uniformly, hence the tearing (see the bug).

BTW, I just noticed, MSVC2013 doesn't throw me any errors about typecasting int to float, but gcc probably would? Should probably fix that.