Why not use my snippet for now? It has the exact same effect, without the code duplication.
2 Likes
I thought that was the idea
My offer to automate builds still stands, just tell me what repository and what branch to build and it’ll update a nightly build on GraphicAll.
2 Likes
I would really appreciate that if you could. The branch that is most likely to be up to date is this one here:
This is where Troy pushes to when he is working and when I work I push to both here and to the branch of the same name on my account’s repo (called Smilebags/blender)
I’d point out that the actual branch is https://github.com/sobotka/blender/tree/spectral-cycles
The goal was to do periodic rebases there, not sure if that would impact the auto-builds.
Thanks for that, I hope the link I copied sends you to the branch. If the auto builds just checkout the head of the branch it should be fine, I would think.
Daily updated branch build from troy’s github is now available here
GPU kernels did not build, so they have not been included for now, this branch has the same issues i fixed earlier, uses [0] rather than .x
7 Likes
I’ll try to get them fixed soon, I appreciate that though.
1 Like
Nice! Thanks for this!
So awesome to see the progress with this! Would be great to test it with GPU rendering.
Here is a quick test i did:
Pretty big difference!
Left sphere is a 100% saturated blue, Monkey is 100% saturated green, Right sphere is 100% saturated red. Left emissive sphere is 100% saturated red, and right emissive sphere is 100% saturated blue. groundplane is mid grey.
A bit of a odd thing i noticed was that the left emissive sphere was blown out white in preview render, but orange in final render. How come?
2 Likes
Without drilling into it, I strongly suspect that’s a gamut clip issue. The base transforms are not nuanced in any manner.
in this one, at first glance, other than the light sources, there’s not much of a difference, but if you directly compare them (flip back and forth between them), you’ll find that the spectral render shows vastly more detail on the Suzannes. It really shows the range of differences to expect: Basically none in gray areas, very little in even saturated areas that aren’t just pure red, green, or blue, but quite substantial improvements in those extremes.
Also it’s not quite so simple as RGB being brighter than Spectral. If you look closely, you’ll find that the light on the bottom plane actually reaches farther in the Spectral version (the outer edge of the part of the image that isn’t black goes farther), despite being darker in the center. - I just can’t ever be sure in how far that’s simply a tone mapping difference. (This seems to be a pure brightness thing after all, so that could be due to tone mapping, right?) (there’s no tonemapping yet so this is nonsense)
RGB:
Spectral:
GIF comparison:
EDIT: I modified the scene to get rid of much of the direct same-color light by adding this cone:
That pronounced the effects quite a bit. Interestingly, perhaps due to relative darkness, the denoiser struggled more to denoise the RGB version of Green Suzanne’s eyes. You can also see how, on the Suzannes, the colors look quite different, as the diffuse portion of the shader is no longer entirely black for other light sources, and so mixes into the highlights. And the improved overall contrast is also still very much visible.
RGB:
Spectral:
1 Like
It really is more realistic, there’s no doubt about it. I understand it’s somewhat biased because these renders use solid colors but the difference is there.
1 Like
Thanks for all the tests, I’ll try to apply the fix so that GPU rendering can work today.
2 Likes
There is zero gamut mapping happening in the default configuration. It’s a literal dump of scene linear anchored around 0.18 to display linear output.
@LazyDodo would you be able to enable CUDA in the build which you have running? I’ve removed the array notation access from everywhere I can see it is necessary, wanted to see whether it would support GPU now.
Thanks again for setting that up, I really appreciate it.
2 Likes
Looks like you missed one, and there’s a few other errors as well
/kernel_color.h(562): error : no operator "[]" matches these operands operand types are: float4 [ int ]
/kernel_path_state.h(69): error : class "KernelGlobals" has no member "wavelength_low_bound"
/kernel_path_state.h(70): error : class "KernelGlobals" has no member "wavelength_high_bound"
/kernel_path_state.h(77): error : class "KernelGlobals" has no member "wavelength_low_bound"
/kernel_path_state.h(77): error : class "KernelGlobals" has no member "wavelength_high_bound"
/kernel_path_state.h(78): error : class "KernelGlobals" has no member "wavelength_low_bound"
/kernel_path_state.h(78): error : class "KernelGlobals" has no member "wavelength_high_bound"
/kernel_path_state.h(79): error : class "KernelGlobals" has no member "wavelength_low_bound"
/kernel_path_state.h(79): error : class "KernelGlobals" has no member "wavelength_high_bound"
1 Like
Whoops! Fixing it now. I wonder why I could build 
Anyway I don’t need the bounds yet so I’ll remove them.
1 Like
@LazyDodo please try again now, I’ve addressed those errors. Still confused why I wasn’t encountering the ones about KernelGlobals since they do exist 
1 Like
From a quick test they seem to build now, i enabled them on the builder, which is scheduled to start in the next hour or so
3 Likes