This fixes T43696. Problem was accumulation of floating point precision errors in zspan_scanconvert function.
Details
Details
- Reviewers
Sergey Sharybin (sergey) - Group Reviewers
Render Pipeline - Maniphest Tasks
- T43696: Baking tearing normals (Both cycles and BI)
Diff Detail
Diff Detail
Event Timeline
Comment Actions
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?
Comment Actions
- 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.