Cycles: Watertight rendering produces artifacts on a huge plane #43865

New Issue

Lukas Stockner · 2015-03-02T21:20:17+01:00

Lukas Stockner commented

2015-03-02 21:20:17 +01:00

System Information
Linux Mint 17
Intel i7-4500U (using AVX2 instruction set)

Blender Version
Broken: Current master (d2b6c6fd9b, if I remember correctly it appeared in f770bc4757
Worked: 2.73a release

When rendering the default scene with a huge plane added, there are artifacts in the top right area.

Exact steps for others to reproduce the error
Either:

Start Blender with the default scene
Switch to Cycles
Add a plane
Scale by 500
Hit F12
Or:
Render this file: watertight_artifact.blend

Expected (2.73a):
Received (master):

**System Information** Linux Mint 17 Intel i7-4500U (using AVX2 instruction set) **Blender Version** Broken: Current master (d2b6c6fd9b, if I remember correctly it appeared in f770bc4757 Worked: 2.73a release When rendering the default scene with a huge plane added, there are artifacts in the top right area. **Exact steps for others to reproduce the error** Either: - Start Blender with the default scene - Switch to Cycles - Add a plane - Scale by 500 - Hit F12 Or: Render this file: [watertight_artifact.blend](https://archive.blender.org/developer/F146789/watertight_artifact.blend) Expected (2.73a): ![noerr.png](https://archive.blender.org/developer/F146790/noerr.png) Received (master): ![Err.png](https://archive.blender.org/developer/F146792/Err.png)

Lukas Stockner commented

2015-03-02 21:20:17 +01:00

Changed status to: 'Open'

Sergey Sharybin was assigned by Lukas Stockner

2015-03-02 21:20:17 +01:00

Lukas Stockner commented

2015-03-02 21:20:17 +01:00

Added subscriber: @LukasStockner

blender-admin commented

2015-03-02 21:20:17 +01:00

#53192 was marked as duplicate of this issue

blender-admin commented

2015-03-02 21:20:17 +01:00

#46509 was marked as duplicate of this issue

blender-admin commented

2015-03-02 21:20:17 +01:00

#44207 was marked as duplicate of this issue

Sergey Sharybin commented

2015-03-03 15:36:21 +01:00

Just a quick update. It's some nasty precision issues, need to re-formulate some equations there at least, not totally trivial tho and not totally sure it's really solvable for all circumstances. Need some more time on that.

blender-admin commented

2015-03-05 14:55:30 +01:00

This issue was referenced by 9489205c5c

This issue was referenced by 9489205c5c0b9b432d02be4a3d0d15fc62ee6cb9

Sergey Sharybin commented

2015-03-05 15:00:47 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2015-03-05 15:00:47 +01:00

Sergey Sharybin commented

2015-03-05 15:00:47 +01:00

Closed by commit 9489205c5c.

Closed by commit 9489205c5c.

blender-admin commented

2015-03-12 14:24:53 +01:00

This issue was referenced by dce16d57dc

This issue was referenced by dce16d57dc928ead124dcde1d241727c4f2bbc24

Sergey Sharybin commented

2015-03-12 14:29:29 +01:00

Changed status from 'Resolved' to: 'Open'

Sergey Sharybin reopened this issue

2015-03-12 14:29:29 +01:00

Sergey Sharybin commented

2015-03-12 14:29:29 +01:00

Need to re-open.

Original fix caused really noticeable speed regression. I didn't notice it before committing because was having abort() statement in the fallback code which basically optimized out majority of the code. Without that statement the assembly code looks totally different. Seems somewhat related on optimized our dir from the callstack and so.

For a short time it's better to have production scenes rendering as fast as possible, plane could be subdivided anyway. Will look into alternative solutions now.

Idea could be to push ray a bit more forward on bounce from the huge triangle.

P.S. If someone can see how Woop code could be refactored it'll be also cool. So far i can't really get rid of basically cubical order of magnitutde of intermediate variables which kills precision in one cases or another ones.

Need to re-open. Original fix caused really noticeable speed regression. I didn't notice it before committing because was having `abort()` statement in the fallback code which basically optimized out majority of the code. Without that statement the assembly code looks totally different. Seems somewhat related on optimized our `dir` from the callstack and so. For a short time it's better to have production scenes rendering as fast as possible, plane could be subdivided anyway. Will look into alternative solutions now. Idea could be to push ray a bit more forward on bounce from the huge triangle. P.S. If someone can see how Woop code could be refactored it'll be also cool. So far i can't really get rid of basically cubical order of magnitutde of intermediate variables which kills precision in one cases or another ones.

blender-admin commented

2015-03-17 11:49:08 +01:00

This issue was referenced by 86b862ecc9

This issue was referenced by 86b862ecc90783750aec59e474cfa6973acbafef

Sergey Sharybin commented

2015-03-17 11:50:27 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2015-03-17 11:50:27 +01:00

Sergey Sharybin commented

2015-03-17 11:50:27 +01:00

Closed by commit 86b862ecc9.

Closed by commit 86b862ecc9.

Sergey Sharybin commented

2015-03-18 09:43:40 +01:00

Changed status from 'Resolved' to: 'Open'

Sergey Sharybin reopened this issue

2015-03-18 09:43:40 +01:00

Sergey Sharybin commented

2015-03-18 09:43:40 +01:00

Bummer, stupid phabricator scanned the tag and saw the commit from v2.74-rc2 tag and decided to close the report :S

blender-admin commented

2015-03-24 18:36:52 +01:00

This issue was referenced by blender/cycles@84b962ea82

This issue was referenced by blender/cycles@84b962ea82112b008fe2c8a178e2734a025b0bb3

blender-admin commented

2015-03-24 18:37:22 +01:00

This issue was referenced by blender/cycles@2541f5c8f8

This issue was referenced by blender/cycles@2541f5c8f825c517f2d0742149693b8be0750b19

Sergey Sharybin commented

2015-03-24 20:09:13 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2015-03-24 20:09:13 +01:00

Sergey Sharybin commented

2015-03-24 20:09:13 +01:00

Closed by commit blender/cycles@84b962ea82.

Sergey Sharybin commented

2015-03-24 20:11:07 +01:00

Changed status from 'Resolved' to: 'Open'

Sergey Sharybin reopened this issue

2015-03-24 20:11:07 +01:00

Sergey Sharybin commented

2015-03-31 15:42:12 +02:00

Added subscriber: @pafurijaz-4

Riccardo Giovanetti commented

2015-09-22 10:42:13 +02:00

Added subscriber: @Harvester

Riccardo Giovanetti commented

2015-09-22 10:42:13 +02:00

Hi Sergey, I'm not sure this could be of any help but, just for curiosity I tested this bug in Blender 2.76 RC1, Windows 64bit, zipped, and it's still there but I found that subdividing once the huge plane it seems to fix the problem, as you can see below.

Plane not subdivided

Plane subdivided one time

Hi Sergey, I'm not sure this could be of any help but, just for curiosity I tested this bug in Blender 2.76 RC1, Windows 64bit, zipped, and it's still there but I found that subdividing once the huge plane it seems to fix the problem, as you can see below. ![T43865_plane_not_subdivided.jpg](https://archive.blender.org/developer/F236889/T43865_plane_not_subdivided.jpg) Plane not subdivided ![T43865_plane_subdivided_one_time.jpg](https://archive.blender.org/developer/F236891/T43865_plane_subdivided_one_time.jpg) Plane subdivided one time

Sergey Sharybin commented

2015-10-17 20:16:11 +02:00

Added subscribers: @mont29, @ManuelMarino

Sergey Sharybin commented

2015-10-17 21:06:44 +02:00

Developer note:

While those two reports seems different -- one of them is caused by rather huge plane and other is caused by a small stretched triangles they're in fact quite the same from the math point of view. There are some instabilities in sign of determinant happening in the watertight intersection we're using.

I've talked to Sven about the huge triangle case and it's not really solvable. Any of the intersection algorithm will be affected by this problem in one way or another.

But the cases like F245475 we'd really better resolve, they aren't so crazy setup at all. Now, something like D1212 will help with cases like huge plane, but it's not really helping with the stretched triangles apparently. We might also switch to pleucker intersection test, but that was somewhat slower last time i've been experimenting with it.

Developer note: While those two reports seems different -- one of them is caused by rather huge plane and other is caused by a small stretched triangles they're in fact quite the same from the math point of view. There are some instabilities in sign of determinant happening in the watertight intersection we're using. I've talked to Sven about the huge triangle case and it's not really solvable. Any of the intersection algorithm will be affected by this problem in one way or another. But the cases like [F245475](https://archive.blender.org/developer/F245475/cycles_bug_black_faces.blend) we'd really better resolve, they aren't so crazy setup at all. Now, something like [D1212](https://archive.blender.org/developer/D1212) will help with cases like huge plane, but it's not really helping with the stretched triangles apparently. We might also switch to pleucker intersection test, but that was somewhat slower last time i've been experimenting with it.

Mohamed Sakr commented

2015-10-18 12:49:34 +02:00

Added subscriber: @MohamedSakr

Mohamed Sakr commented

2015-10-18 12:49:34 +02:00

hey Sergey, what about recursive splitting to this triangle? "depending on triangle size" , this would solve everything in the preprocess stage

Sergey Sharybin commented

2016-01-19 19:00:03 +01:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2016-01-19 19:00:03 +01:00

Sergey Sharybin commented

2016-01-19 19:00:03 +01:00

While it's kind of a regression, new behavior is more predictable for artists because only needs some extra subdivisions to made. Such cases will always be an issue for intersections, some formulas might work, some might not. There's a patch which implements Pluecker D1574 and seems to solve the issue. Would need to run some performance tests and maybe we'll just have to switch to a new intersection algorithm.

In any case, wouldn't really consider it a bug. Thanks for the report anyway.

While it's kind of a regression, new behavior is more predictable for artists because only needs some extra subdivisions to made. Such cases will always be an issue for intersections, some formulas might work, some might not. There's a patch which implements Pluecker [D1574](https://archive.blender.org/developer/D1574) and seems to solve the issue. Would need to run some performance tests and maybe we'll just have to switch to a new intersection algorithm. In any case, wouldn't really consider it a bug. Thanks for the report anyway.

Brecht Van Lommel commented

2017-11-03 10:35:37 +01:00

Added subscribers: @KaiKostack-3, @zeauro

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

Cycles: Watertight rendering produces artifacts on a huge plane #43865