So the new sky model is soon going to be in Blender proper. How hard, do you think, would it be to make it output proper spectral values? As I understand it, it already uses spectral data in the code but then turns it into an RGB color before rendering.
It seems likely that was just a recommendation out of practicality. You see very little difference between colours with 5nm VS 1nm resolution.
Yes, I will attempt a merge from master, converting it to spectral should simply be a matter of removing the conversion to RGB that is happening, and instead sampling the sky model directly.
There are multiple other benefits with sampling it spectrally, such as removing the need for a precomputation stage (allowing node-based control of sun location) and perfect colour accuracy instead of a tradeoff between colour accuracy and speed.
4 Likes
I suspect it’s possible to have spectra where sub 5nm resolution really does matter to their appearance, but I suspect these are extremely rare. 5nm is usually gonna be enough.
And on a practical side, Blender’s curves try to simplify points that are close together. Going below 5nm actually makes it very likely that it just collapses points together and you can’t put it in anyway.
1 Like
I’d love to have some of the fancy tests from that thread be rerun with spectra. I really liked the tea, lemon, and leaves scene by @rbx775 and would love to see if it could be meaningfully improved using spectral data for some sort of black tea, leaves, and lemon skin. If all that can be located. Even without, though, the spectral sky colors are going to play nicely, I suspect.
Direct lighting should look almost identical, but I imagine you’ll get some more rich looking sunsets with spectral.
The absorption material of the tea might be affected even under direct lighting. You’re right that otherwise it probably wouldn’t actually matter that much…
You’re right, absorption is essentially indirect lighting since the colour of the light in the middle of the substance depends on the absorption spectrum itself - similar to self-reflection.
Seems like my assumptions about the sky model weren’t quite right and it won’t be so straightforward, but I’m still keen to give it a shot
3 Likes
It wasn’t managed last I checked.
Should never have been integrated into master. Dumb, but expected.
I’m hoping that by using the sky model directly in spectral, we’ll avoid what’s going on getting it to RGB. I don’t think there’s anything wrong with the sky model itself.
“Think” and “confirming” would be two different things. Judging from the random “slap it up and try” design process, I’m exactly zero confident in the robustness.
Beyond that, it is 2020. All new things must be managed. Anything that isn’t is woefully broken, and adds to tech debt; it becomes legacy cruft.
isn’t this exactly what the code review process is for?
You’d think so, but it isn’t the case.
Ultimately pixel management is a cultural problem; if the majority doesn’t see it, doesn’t care about it, and doesn’t think it matters, so be it.
It takes more than one raving lunatic to bring up the same points over and over and over and over and over and over and over and over and over again.
That raving lunatic has passed the torch on, with hope.
1 Like
The sky texture is color managed, in that it converts from XYZ to RGB with the appropriate matrix depending on the OpenColorIO configuration. And this is something I pointed out to the developer before the patch was submitted to code review.
Removing the precomputation stage is not practical, rendering would be orders of magnitude slower without it. What would be possible is precomputing a table for many wavelengths, though memory usage would be quite bad if done naively.
8 Likes
There is some bug concerning SSS shaders right now.
Principled BSDF’s Subsurface slider makes materials behave exactly like in master.
(Default settings of both the SSS node in master and the Principled BSDF node in either master or Spectral branch with Subsurface slider cranked to 1)
But using the standalone Subsurface Scattering shader, the colors go all wrong:
(Subsurface Scattering node, default settings - they are identical to Principled BSDF’s defaults, and yet the color goes purple)
Worse, somehow the result depends on the Texture blur even if the input color is uniform:
(Texture Blur set to 1)
It might seem in this example that setting texture blur to 1 is identical to what Principled BSDF does, but that’s not the case. It’s still a different color.
1 Like
Good catch, thanks! I forgot to change “Radius” socket type to spectral. Should be fixed in the next build plus latest Blender.
4 Likes
Yes, I had incorrectly assumed the main speed up was from not having to compute 21 wavelengths per sample, but this is seemingly not where the inefficiencies are. My hope is that with some more targeted caching, we can save the recomputation of the expensive parts of the model (not sure what parts of it those are) but still retain good wavelength and spatial resolution.
2 Likes
How does the radius here work anyway? It doesn’t take a spectrum as input in either shader, so how are the three values translated?
Internally radius socket type is spectral because it takes 3 values for each RGB channel, just like any RGB input. You can connect any spectral output to it, otherwise, values are converted the same way as RGB colors.
2 Likes
Ah that’s good to know. That wasn’t obvious 'cause it supposedly takes a vector input.
(That doesn’t explain why the texture blur has an influence on this though)