Hi, I started updating the branch to the latest version of blender 2 weeks ago. Spectral rendering already works, but there are issues such as only with 4 wavelengths per ray can be used.
I’m planning to improve the state of the branch to be compatible with all the latest additions and changes, like path guiding and fix bugs. When it’s done, the branch should be easy to keep up to date and I can start submitting changes for review.
it’s not yet that interesting until we get proper spectrum input support (alongside corresponding math nodes), and Path Guiding support, but I’m glad to finally have a working version of the spectral branch again
Nope, all of these rooms are diffuse only, using pure RGB values (so the top row has a diffuse material with the color RGB 1 0 0, etc.)
Each column also features a pure RGB light source (so the left-most row is lit by a light source of RGB 1 00 etc.)
No volumetrics anywhere. The blown-out results in the RGB version are due to these extreme colors: Light doesn’t go darker as it bounces (unless it escapes into the black abyss outside behind the camera), nor does it go more saturated (as these colors are already as saturated as they could possibly get in a 3-channel RGB setting using sRGB as the rendering colorspace)
In contrast, in the spectral scene these same colors are defined by broad spectra and thus can change saturation and lightness over time, allowing these rooms to show somewhat more definition.
This also means, that there is cross-talk between color channels, so you get, say, green rooms lit by red lights appearing brownish, rather than pure black. This is much more realistic.
Note that this scene is hand-crafted to show the effect as clearly as possible. In most scenes you aren’t gonna see differences even remotely this drastic. The biggest effects are gonna happen with highly saturated scenes like this.
That’s probably related to the other issue where using 8 wavelengths per ray gives strange results. Likely a memory-related issue, but I haven’t found the culprit yet.
That’s exactly the same issue as the last time – multiple importance sampling for background not working on GPU. My previous solution doesn’t seem to work, though. I’m getting mysterious crashes from within the CUDA libraries, which are closed-source.
Note on AgX: The Spectral branch uses a different whitepoint to render images. It’s based on I-E rather than I-D65.
The reason for that is, that we want the default conversion of an sRGB Red 1 0 0 plus Green 0 1 0 plus Blue 0 0 1 to add up to a completely uniformly flat spectrum (so that, say, a color of 1 1 1 means 100% reflection) which implies that the whitepoint needs to be I-E. (That illuminant is literally defined to be the flat equal energy spectrum)
As a result, by default, the config is going to be slightly off.
To fix this, you have to
go into the config.ocio file (just open it up in notepad),
find the roles section (line 10 and onwards) and
locate the line XYZ (line 23)
change that line to XYZ: Linear CIE-XYZ I-E
(so just change the last bit to I-E)
Then the colors will end up looking a bit more comparable
An easy check if you did it right:
Does the default scene in Cycles look kinda yellowish or pinkish? You’re still on the wrong whitepoint.
If it looks the same grey as regular Cycles, you did it right.
You’ll have to restart Blender each time you change the config though. It only gets loaded at launch
I am curious if this is something that can eventually be changed so that one does not have to restart Blender. Would it be possible to eventually have a dropdown in rendering preferences that tells Blender to use I-E or I-D65 without restarting (likely with a note specifying that I-E is for spectral and I-65 for non-spectral)? I would suppose that if the spectral branch replaces the non-spectral Cycles, this might be unnecessary.
EDIT: Please bear with me if such a question reveals the great depth of my ignorance on the topic. I am simply a curious bystander.