Circular/radial bands in this hair scene (most noticeable in CPU)
Open, ConfirmedPublic

Description

System Information
Kubuntu Linux 14.04 64 bits, GTX 960 nvidia 352, i7-3770

Blender Version
Broken: 2.77a, buildbot

Short description of error
In this scene:

circular/radial bands appear. I do not know if they should be there, but the point is that GPU/CPU render result do not match, and the bands are most noticeable with CPU:


Exact steps for others to reproduce the error
Open the scene, configure for CPU or GPU and render.

Details

Type
To Do
YAFU (YAFU) updated the task description. (Show Details)
YAFU (YAFU) raised the priority of this task from to Needs Triage.
YAFU (YAFU) added a project: BF Blender.
YAFU (YAFU) set Type to Bug.
YAFU (YAFU) added a subscriber: YAFU (YAFU).

Can verify on Blender 2.77a.

Opensuse Leap 42.1 x86_64
Intel i5 3570K
RAM 16 GB
GTX 760 4 GB /Display card
GTX 670 2 GB
Driver 367.27
opencl_runtime_16.1_x64_sles_5.2.0.10002

Have no graphics card, but can confirm identical strong circular bands on i5-2557M with 4 GB RAM running Blender 2.77a on Arch Linux.

Sergey Sharybin (sergey) triaged this task as Confirmed priority.Jun 28 2016, 11:18 AM
Sergey Sharybin (sergey) claimed this task.

Developer note: After quite some investigation nailed this down to rBc45c472 which happened between 2.70 and 2.71. Unfortunately, from a quick experiment with disabling SSE2 branches in current code the issue was not solved, so need to doublecheck all changed parts of non-SSE2 code in that commit. Currently looks like it's a distance cutoff which is not working very well. More investigation tomorrow.

Did much deeper investigation here, and unfortunately seems there's no simple solution here.

Root of the issue goes to the precision issues, which sometimes leads to a missing intersections. It kinda worked before, but some optimizations re-formulated some equations which introduced some machine precision issues. Internally it's all about td < 0.0f check. Currently in some cases it'll be really small negative value which leads to a missing intersection while old code was recording this intersection.

For non-SSE code this seems to be relatively easily worked around by going back to old equation for tc:

float tc = dot3(tdif, tdif) - (tdifz*tdifz + tdifz*tdifz*gd*gd + r1*r1 + 2*r1*tdifz*gd)

But unfortunately, i didn't find source of precision issue for SSE code, it might be a bit more tricky since it uses different math on CPU.

In any case, it's something we should look into (maybe investigate other ways of checking for intersections -- i.e. a while ago i've started playing around with 2D-projection based code similar to watertight triangle intersection, but didn't quite finish that yet). But it's not strictly speaking a bug.

Sergey Sharybin (sergey) changed Type from Bug to To Do.

macOS 10.12.5, MacBook Air, NVIDIA GeForce 320M 256 MB
Daily build 2017-07-18 02:14, Hash: 66383ea206

With the above configuration, the CPU render looks clean with no obvious banding.

Regarding the comment above, I'm not sure how this could be OS dependent. But I can still reproduce the problem in Linux, blender from buildbot 11a9434c2de