WIP: Cycles: Implement better ellipse sampling for area lights #122935

Lukas Stockner · 2024-06-09T04:06:22+02:00

Lukas Stockner commented

2024-06-09 04:06:22 +02:00

First step in implementing sampling of spherical ellipses.

Currently, the code only projects the ellipse to be tangent to the unit sphere around the shading point, then samples that as usual.
However, that is arguably the hard part - the remainder is described and implemented in "Area-Preserving Parameterizations for Spherical Ellipses", but unlike their projection step, this one also works for planar ellipses, not just disks.

The eigendecomposition code can probably be improved, I just used a function that was left over from the old denoiser.

Attached is a playground file with a Python implementation of the various methods and a basic visualization for debugging.

First step in implementing sampling of spherical ellipses. Currently, the code only projects the ellipse to be tangent to the unit sphere around the shading point, then samples that as usual. However, that is arguably the hard part - the remainder is described and implemented in "Area-Preserving Parameterizations for Spherical Ellipses", but unlike their projection step, this one also works for planar ellipses, not just disks. The eigendecomposition code can probably be improved, I just used a function that was left over from the old denoiser. Attached is a playground file with a Python implementation of the various methods and a basic visualization for debugging.

ellipse.blend

1.7 MiB

❤️ 2

Lukas Stockner added 1 commit 2024-06-09 04:06:29 +02:00

WIP: Cycles: Implement better ellipse sampling for area lights fe1ccf9458

Lukas Stockner added 2 commits 2024-06-10 02:02:01 +02:00

Implement solid-angle sampling e83fff9b82

Implement low-distortion mapping e6a7df2947

Lukas Stockner commented

2024-06-10 02:22:41 +02:00

Update: The code implements the numerical (non-lookup-based) solid angle sampling now.

TODOs:

There are numerical issues are grazing angles (and sometimes domain exceptions in ellint_3)
We need a standalone ellint_3 implementation (probably just base on the GSL version - there are better approaches, but they're more complex from what I can see).
- Also look into whether a simpler approximation is good enough.
The eigendecomposition can probably be improved quite a bit (we have 3x3 symmetric matrices with a known zero element. This approach looks promising, for example.)
The numerical inversion is way too slow to be practical, it should be replaced with the LUT method. Seems easy, but I'd also like code to reproduce the table.

Update: The code implements the numerical (non-lookup-based) solid angle sampling now. TODOs: - There are numerical issues are grazing angles (and sometimes domain exceptions in `ellint_3`) - We need a standalone `ellint_3` implementation (probably just base on [the GSL version](https://github.com/ampl/gsl/blob/master/specfunc/ellint.c) - there are [better approaches](https://www.sciencedirect.com/science/article/pii/S037704271300201X), but they're more complex from what I can see). - Also look into whether a simpler approximation is good enough. - The eigendecomposition can probably be improved quite a bit (we have 3x3 symmetric matrices with a known zero element. [This approach](https://www.geometrictools.com/Documentation/RobustEigenSymmetric3x3.pdf) looks promising, for example.) - The numerical inversion is way too slow to be practical, it should be replaced with the LUT method. Seems easy, but I'd also like code to reproduce the table.

Lukas Stockner commented

2024-06-10 02:23:51 +02:00

Quick comparison is attached, note the artifacts in the solid-angle version.

ellipse_solidangle.png

6.5 KiB

ellipse_area.png

7.6 KiB

Lukas Stockner added 2 commits 2024-06-11 00:52:00 +02:00

Fix noise artifacts 0f2ed0a6e2

Use standalone 3x3 symmetric eigensolver 5dd19a54f0

Lukas Stockner commented

2024-06-11 00:58:53 +02:00

Update:

Axes are now consistent across samples to solve the noise boundary artifacts
Eigensolver is replaced with an efficient 3x3 symmetric implementation

I've also looked into implementing the linked comp_ellint_3 implementations. The GSL variant works, but is even slower than the stdlib version. The more efficient version works, but is very complex (it depends on piecewise fits with dozens of parameters each) and also iterative.

So, different idea: Just approximate the solid angle. We only need it for the pdf, so if we're off by e.g. 1% that's not that big of a deal. Tabulating the solid angle w.r.t alpha and beta/alpha looks fairly smooth, it seems like a numerical fit of the form a * (x*x*y) * (c+b*cos(x*pi/2)) gets within 2.5% and tabulating the residual by remapping the parameters as x**2 and y**2 with e.g. 32^2 resolution should be within 0.2% or so.

Update: - Axes are now consistent across samples to solve the noise boundary artifacts - Eigensolver is replaced with an efficient 3x3 symmetric implementation I've also looked into implementing the linked `comp_ellint_3` implementations. The GSL variant works, but is even slower than the stdlib version. The more efficient version works, but is very complex (it depends on piecewise fits with dozens of parameters each) and also iterative. So, different idea: Just approximate the solid angle. We only need it for the pdf, so if we're off by e.g. 1% that's not that big of a deal. Tabulating the solid angle w.r.t `alpha` and `beta/alpha` looks fairly smooth, it seems like a numerical fit of the form `a * (x*x*y) * (c+b*cos(x*pi/2))` gets within 2.5% and tabulating the residual by remapping the parameters as `x**2` and `y**2` with e.g. 32^2 resolution should be within 0.2% or so.

Lukas Stockner commented

2024-06-11 17:40:05 +02:00

After some tweaking, I got the approximation error down to 0.004% on average and 0.08% maximum (out of 10000 random inputs) using a 32x32 table.

This also behaves well in the limits from what I can see - for example, the bright pixel artifacts in the attached comparison are gone.

Analytical	Approximation

After some tweaking, I got the approximation error down to 0.004% on average and 0.08% maximum (out of 10000 random inputs) using a 32x32 table. This also behaves well in the limits from what I can see - for example, the bright pixel artifacts in the attached comparison are gone. | Analytical | Approximation | | - | - | | ![ellipse-numeric.png](/attachments/a6e76ac5-6e1c-45b3-bcd1-ab84e7ac5277) | ![ellipse-lookup.png](/attachments/012db723-d451-4a94-b739-d2e0b1ce2b7c) |

ellipse-lookup.png

286 KiB

ellipse-numeric.png

294 KiB

precompute_elliptic_S.py

2.5 KiB

Lukas Stockner added 2 commits 2024-06-12 01:33:58 +02:00

Use lookup table and numerical fit for ellipse solid angle 954d84ebad

Use lookup table to invert area CDF efa897d048

Lukas Stockner commented

2024-06-12 01:45:16 +02:00

Update: Here's a version with the CDF lookup table approach, as described in the paper. The LUT is generated by the attached script: precompute_sample_table.py

However, when plotting the LUT in 2D (see attachment), it becomes obvious that the axis encoding is hugely wasteful - the actual non-trivial part of the table is maybe a 4x4 or so region of the 256x256 table, everything else is just linear:

This explains why the paper uses a 1024x1024 table - you need that kind of size to get any proper detail there. However, that also means that with some coordinate remapping, we should be able to use a much smaller table (ideally 32x32 or so). I've got promising attempts (the currently best one is x **= 1/(0.4*(y + 5e-2)) and y **= 4), I'll look into it further.

Finally, note that there appears to be some remaining numerical issue. When making the lamp very small, you get very interesting patterns (this is supposed to be a smooth falloff from the center):

Update: Here's a version with the CDF lookup table approach, as described in the paper. The LUT is generated by the attached script: [precompute_sample_table.py](/attachments/ede23608-058c-44f4-b875-323fc40e0885) However, when plotting the LUT in 2D (see attachment), it becomes obvious that the axis encoding is hugely wasteful - the actual non-trivial part of the table is maybe a 4x4 or so region of the 256x256 table, everything else is just linear: ![lut.png](/attachments/d62bb632-6970-498b-a4ba-0a390436c69f) This explains why the paper uses a 1024x1024 table - you need that kind of size to get any proper detail there. However, that also means that with some coordinate remapping, we should be able to use a much smaller table (ideally 32x32 or so). I've got promising attempts (the currently best one is `x **= 1/(0.4*(y + 5e-2))` and `y **= 4`), I'll look into it further. Finally, note that there appears to be some remaining numerical issue. When making the lamp very small, you get very interesting patterns (this is supposed to be a smooth falloff from the center): ![ellipseglitch_lr.png](/attachments/68a75848-c627-45d7-8ac5-a46caa2d71fe)

lut.png

20 KiB

precompute_sample_table.py

1.1 KiB

ellipseglitch_lr.png

598 KiB

This pull request is marked as a work in progress.

View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u ellipse-sampling:LukasStockner-ellipse-sampling

git checkout LukasStockner-ellipse-sampling

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

WIP: Cycles: Implement better ellipse sampling for area lights #122935

Checkout