Cycles: Change sun lamp to have uniform intensity at high angles #108996

Lukas Stockner · 2023-06-15T02:54:36+02:00

Lukas Stockner commented

2023-06-15 02:54:36 +02:00

This fixes the issue described in #108957.

Instead of modeling distant lights like a disk light at infinity, it models them as cones. This way, the radiance is constant across the entire range of directions that it covers.

For smaller angles, the difference is very subtle, but for very large angles it becomes obvious (here's the file from #108957, the angle is 179°):

Old	New

One notable detail is the sampling method: Using sample_uniform_cone can increase noise, since the sampling method no longer preserves the stratification of the samples. This is visible in the "light tree multi distant" test scene.
Turns out we can do better, and after a bit of testing I found a way to adapt the concentric Shirley mapping to uniform cone sampling. I hope the comment explains the logic behind it reasonably well.

Here's the result, note that even the noise distribution is the same when using the new sampling:

Method	Old	New, basic sampling	New, concentric sampling
Image
Render time (at higher spp)	9.03sec	8.79sec	8.96sec

I'm not sure if I got the light->normalized handling right, since I don't really know what the expectation from Hydra is here.

This fixes the issue described in https://projects.blender.org/blender/blender/issues/108957. Instead of modeling distant lights like a disk light at infinity, it models them as cones. This way, the radiance is constant across the entire range of directions that it covers. For smaller angles, the difference is very subtle, but for very large angles it becomes obvious (here's the file from #108957, the angle is 179°): | Old | New | | - | - | | ![old_bigsun.png](/attachments/4ef8e7a7-1a29-4bdf-a74c-3cfa103bf1e7) | ![new_bigsun.png](/attachments/d53c7749-2672-40b6-9048-ccf2fffceeb7) | One notable detail is the sampling method: Using `sample_uniform_cone` can increase noise, since the sampling method no longer preserves the stratification of the samples. This is visible in the "light tree multi distant" test scene. Turns out we can do better, and after a bit of testing I found a way to adapt the concentric Shirley mapping to uniform cone sampling. I hope the comment explains the logic behind it reasonably well. Here's the result, note that even the noise distribution is the same when using the new sampling: | Method | Old | New, basic sampling | New, concentric sampling | | - | - |- | - | | Image | ![old.png](/attachments/b3258a70-f015-4065-a774-193974cce439) | ![new_basic.png](/attachments/a9008576-0af6-4152-a687-c800fd958bbd) | ![new_concentric.png](/attachments/769b6c43-34bc-434e-a4fd-ce69addd1ba5) | | Render time (at higher spp)| 9.03sec | 8.79sec | 8.96sec | I'm not sure if I got the `light->normalized` handling right, since I don't really know what the expectation from Hydra is here.

old_bigsun.png

70 KiB

new_bigsun.png

57 KiB

old.png

52 KiB

new_basic.png

53 KiB

new_concentric.png

52 KiB

👍 1 🚀 2

Lukas Stockner added 1 commit 2023-06-15 02:54:45 +02:00

Cycles: Change sun lamp to have uniform intensity at high angles 49149f54d5

Lukas Stockner requested review from Brecht Van Lommel 2023-06-15 02:56:09 +02:00

Lukas Stockner added this to the Render & Cycles project 2023-06-15 02:56:12 +02:00

Brecht Van Lommel requested review from Weizhen Huang 2023-06-15 15:11:59 +02:00

Brecht Van Lommel approved these changes 2023-06-15 15:18:49 +02:00

Brecht Van Lommel left a comment

Thanks.

Weizhen Huang commented

2023-06-15 15:39:28 +02:00

I am unable to look into this patch properly this week because I am at a festival, but according to my experience cone sampling has severe numerical problems when the cone angle is small (is that the reason you are using if (angle > 1e-4f)?). I have a sample_uniform_cone_concentric() in #108506 that deals with small angles.

I am unable to look into this patch properly this week because I am at a festival, but according to my experience cone sampling has severe numerical problems when the cone angle is small (is that the reason you are using `if (angle > 1e-4f)`?). I have a sample_uniform_cone_concentric() in #108506 that deals with small angles.

Brecht Van Lommel added this to the 4.0 milestone 2023-06-15 15:43:42 +02:00

Lukas Stockner commented

2023-06-16 00:36:14 +02:00

I am unable to look into this patch properly this week because I am at a festival, but according to my experience cone sampling has severe numerical problems when the cone angle is small (is that the reason you are using if (angle > 1e-4f)?). I have a sample_uniform_cone_concentric() in #108506 that deals with small angles.

Ah, yeah, good catch - looks like we both ended up deriving the same method, but your implementation has the terms simplified further, and using 1-cos(x) directly helps with numerical issues of course.

In my version, I indeed noticed problems when the angle becomes too small (makes sense, since there's not that much resolution around 1.0), that's why I put the limit there. Using the 1-cos(x) trick together with precise_angle should make that unnecessary, I'll give it a try.

> I am unable to look into this patch properly this week because I am at a festival, but according to my experience cone sampling has severe numerical problems when the cone angle is small (is that the reason you are using if (angle > 1e-4f)?). I have a sample_uniform_cone_concentric() in #108506 that deals with small angles. Ah, yeah, good catch - looks like we both ended up deriving the same method, but your implementation has the terms simplified further, and using `1-cos(x)` directly helps with numerical issues of course. In my version, I indeed noticed problems when the angle becomes too small (makes sense, since there's not that much resolution around 1.0), that's why I put the limit there. Using the `1-cos(x)` trick together with `precise_angle` should make that unnecessary, I'll give it a try.

Lukas Stockner added 1 commit 2023-06-16 02:02:32 +02:00

Use more precise math for the cone angle 4a6b9c3b08

Lukas Stockner commented

2023-06-16 02:11:54 +02:00

Okay, I've updated the PR. As far as I can tell, it behaves correctly for small angles (on the order of 0.01°) now.

For those angles, the previous dot(a, b) < cos(angle) actually becomes an issue, it stops working properly around 0.1° (due to the same cancellation issue - both values are almost 1).
This can be avoided with precise_angle, but for performance reasons I added a variant using fast_atan2f which is still more than sufficient here.

Performance numbers (quick test, not super reliable):

without PR: 9.03sec
before angle fix: 8.96sec
with angle fix and simplified math (thanks @weizhen): 8.46sec
with precise_angle: 9.25sec
with fast_atan2f: 8.74sec

Still faster than the original state, and now it's more robust for small angles and more consistent for large ones.

Okay, I've updated the PR. As far as I can tell, it behaves correctly for small angles (on the order of 0.01°) now. For those angles, the previous `dot(a, b) < cos(angle)` actually becomes an issue, it stops working properly around 0.1° (due to the same cancellation issue - both values are *almost* 1). This can be avoided with `precise_angle`, but for performance reasons I added a variant using `fast_atan2f` which is still more than sufficient here. Performance numbers (quick test, not super reliable): - without PR: 9.03sec - before angle fix: 8.96sec - with angle fix and simplified math (thanks @weizhen): 8.46sec - with `precise_angle`: 9.25sec - with `fast_atan2f`: 8.74sec Still faster than the original state, and now it's more robust for small angles *and* more consistent for large ones.

Weizhen Huang added 1 commit 2023-06-19 22:15:14 +02:00

Fix wrong eval_fac ae948b271c

Weizhen Huang added 1 commit 2023-06-19 22:25:09 +02:00

Rename invarea -> eval_fac 388153cd05

Weizhen Huang commented

2023-06-19 22:34:05 +02:00

I changed the eval_fac so that it gives the same intensity regardless of the angular diameter. I will change the description here #108505.

How does it look like without precise_angle()/vector_angle()? For me comparing with dot product seems to behave properly even at 1e-7f, so I wonder if this is platform-related, because of fast math or something.

I changed the `eval_fac` so that it gives the same intensity regardless of the angular diameter. I will change the description here #108505. How does it look like without `precise_angle()`/`vector_angle()`? For me comparing with dot product seems to behave properly even at `1e-7f`, so I wonder if this is platform-related, because of fast math or something.

Weizhen Huang referenced this pull request

2023-06-20 13:23:38 +02:00

Cycles: make light UV available for Texture Coordinate node #108691

Weizhen Huang added 1 commit 2023-06-20 16:36:55 +02:00

Merge branch 'main' into uniform-distant-light 98d29d2285

Weizhen Huang added 1 commit 2023-06-20 16:40:43 +02:00

Resolve format issue caused by last merge 9bba741783

Weizhen Huang referenced this pull request

2023-06-26 15:41:59 +02:00

Fix wrong conversion from power to radiance of area lights #109153

Brecht Van Lommel referenced this pull request

2023-06-27 11:57:03 +02:00