Page MenuHome

Cycles: Use curve approximation for wavelength instead of lookup table
AcceptedPublic

Authored by Sergey Sharybin (sergey) on Apr 3 2015, 4:55 PM.

Details

Summary

Previously lookup table was used for the wavelength node, which was actually
hardcoded into the function. This could have either make compiler to require
having huge stack size or will put it into a texture memory. Either of those
ways is not good for the performance on GPU.

Replaced this lookup table with several 4-5 degree polynomial functions,
which seems to be accurate enough to give noticeable difference.

Also wavelength node without input connected is being converted to value
input at shader compile time.

Diff Detail

Repository
rB Blender
Branch
cycles_wavelength_approx

Event Timeline

Sergey Sharybin (sergey) retitled this revision from to Cycles: Use curve approximation for wavelength instead of lookup table.Apr 3 2015, 4:55 PM
Sergey Sharybin (sergey) updated this object.
Sergey Sharybin (sergey) updated this revision to Diff 3900.

Here's a comparison of original lookup-table based curves and fitted with the polynomials:

Martijn Berger (juicyfruit) edited edge metadata.

Outstanding idea and execution, Ill benchmark it this weekend.

Martijn Berger (juicyfruit) accepted this revision.

Looks good to me

This revision is now accepted and ready to land.Apr 4 2015, 12:49 PM

Made some checks with CUDA. Stack frames dropped a bit, translating to 468MB (unpatched) vs. 457MB (patched) GPU memory usage. Performance also seems much better on GPU now, it is 1min 38sec vs. 1min 23sec (with the link to wavelength connected, so comparison is valid even with the constant substitution).

Sergey Sharybin (sergey) edited edge metadata.EditedApr 6 2015, 1:56 PM
Sergey Sharybin (sergey) updated this revision to Diff 3914.

Increased accuracy of green and red channels at the end of spectrum

There's still some visible difference in results by OSL and curve approximation.

Seems we need to reduce absolute error from 0.01 to something order of magnitude better.

EDIT: On the other hand, there's visible difference with absolute error of 0.002 when actual color is quite dark (as in, comparing red channels of 0.018 and 0.016 side by side is visible). It's not so visible with brighter colors and probably not so visible in real production files. But still interesting to investigate this and try to improve the accuracy.

Any progress here? Maybe @Sv. Lockal (lockal) has some idea, as he did the Blackbody conversion.