Circular/radial bands in this hair scene (most noticeable in CPU) #48684

New Issue

YAFU · 2016-06-19T21:05:35+02:00

YAFU commented

2016-06-19 21:05:35 +02:00

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:
test file.blend

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.

**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: [test file.blend](https://archive.blender.org/developer/F317710/test_file.blend) 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: ![cpu.jpg](https://archive.blender.org/developer/F317711/cpu.jpg) ![gpu.jpg](https://archive.blender.org/developer/F317713/gpu.jpg) **Exact steps for others to reproduce the error** Open the scene, configure for CPU or GPU and render.

YAFU commented

2016-06-19 21:05:35 +02:00

Changed status to: 'Open'

YAFU commented

2016-06-19 21:05:35 +02:00

Added subscriber: @YAFU

Wolfgang Faehnle commented

2016-06-20 17:01:09 +02:00

Added subscriber: @mib2berlin

Wolfgang Faehnle commented

2016-06-20 17:01:09 +02:00

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

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

NikoLeopold commented

2016-06-21 20:39:25 +02:00

Added subscriber: @NikoLeopold

NikoLeopold commented

2016-06-21 20:39:25 +02:00

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 commented

2016-06-28 11:18:16 +02:00

Added subscriber: @Sergey

Sergey Sharybin self-assigned this 2016-06-28 11:18:27 +02:00

Sergey Sharybin commented

2016-06-29 14:39:04 +02:00

Developer note: After quite some investigation nailed this down to c45c472 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.

Developer note: After quite some investigation nailed this down to c45c472 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.

Sergey Sharybin commented

2016-07-01 13:22:10 +02:00

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.

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.

Alan Taylor commented

2017-07-18 17:10:29 +02:00

Added subscriber: @skororu

Alan Taylor commented

2017-07-18 17:10:29 +02:00

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.

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. ![cpu_66383ea206.png](https://archive.blender.org/developer/F670936/cpu_66383ea206.png)

YAFU commented

2017-09-10 14:44:54 +02:00

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 11a9434c2d

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

Sergey Sharybin removed their assignment 2020-03-13 16:17:43 +01:00

Sergey Sharybin commented

2020-03-13 16:17:43 +01:00

We are switching to an entirely new (Embree based) ray intersection. It will have different intersection code for curves, hopefully which will be free from this artifact.

So under the current state of the code this is considered a known issue.

We are switching to an entirely new (Embree based) ray intersection. It will have different intersection code for curves, hopefully which will be free from this artifact. So under the current state of the code this is considered a known issue.

Alaska commented

2020-08-31 05:32:53 +02:00

Added subscriber: @Alaska

Alaska commented

2020-08-31 05:32:53 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Alaska closed this issue

2020-08-31 05:32:53 +02:00

Alaska self-assigned this 2020-08-31 05:32:53 +02:00

Alaska commented

2020-08-31 05:32:53 +02:00

Testing with Embree shows this issue as resolved. @Sergey I'm marking this report as "resolved". Feel free to re-open it if you or others experience issues.

Sergey Sharybin commented

2020-08-31 09:39:01 +02:00

Just for the completeness: there might still be artefacts on GPU. The BVH builder is still old own implementation, as well as the node intersection. However, the hair primitive intersection has changed to match Embree.
Don't have machine with GPU handy at this moment, so can not double-check this.

There is some planned work to bring Embree builder for GPU as well, until then even if there are still artifacts there is not much we can do.

Just for the completeness: there might still be artefacts on GPU. The BVH builder is still old own implementation, as well as the node intersection. However, the hair primitive intersection has changed to match Embree. Don't have machine with GPU handy at this moment, so can not double-check this. There is some planned work to bring Embree builder for GPU as well, until then even if there are still artifacts there is not much we can do.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Circular/radial bands in this hair scene (most noticeable in CPU) #48684