Unfortunately no, the branch with spectral nodes had a lot of changes and hacks to make it work, which made it more difficult to update each time. At some point, random bugs started to appear and I decided it was not worth the effort to maintain the branch.
3 Likes
I don’t think so. From what I could gather, Brecht meant a more technical thing about that. Certain manipulations of wavelength would be bad. But all those nodes were totally fine.
I think the problems happen if you directly, within nodes, change the current ray’s wavelength.
There actually is a situation where this would be valid, and that’s fluorescence and its variants. This currently is unsupported in any existing build.
Nope, that was kinda what I was hoping for. There hasn’t been a new build in a long while. And apparently, the current version of the branch, according to smilebags, doesn’t quite compile.
Dear author, I just came across a opensource library called MRF. Don’t know if that could help you on your project at any point?
MRF (Malia Rendering Framework) is an open source library for predictive, physically-realistic rendering. It comes with several applications, including a spectral path tracer, RGB-to-spectral conversion routines.
5 Likes
I remember he said those wavelength related utility nodes would impact the importance sampling, and BSDFs wouldn’t. I remember after we had the 2.93 build with all the nodes, Brecht made a negative comment about these nodes, and smilebags then said something like “do you mean the spectral blackbody node we have is already problematic?” or something. Let me find it…
Here:
As you can see, Brecht didn’t like our spectral nodes in 2.93 build.
What he meant was basically “instead of a blackbody spectra input node, let’s have a blackbody emission BSDF”
We should probably discuss the design more thoroughly first before making the move…
@pembem22 Congrats on the first (?) patch of the project !
Will you and @smilebags be able to spend more time on this ? Can we expect to have a working spectral branch anytime soon ?
11 Likes
Thanks! And also huge thanks to Brecht and Thomas who quickly fixed issues with platforms I cannot test myself.
Yes, this is the first patch towards having spectral rendering in Cycles. I’m planning to upload the next one tomorrow, it’s also pretty small. The third patch will be huge and will probably take the most time to review and polish before getting merged.
37 Likes
Wow Congrats 
I read through much of this thread (from the beginning), over the years…
Pretty facinating topic, even if I doesn’t always catch all the ins and outs.
4 Likes
Thank you so much for what you are doing for Blender, can’t wait, just can’t wait 
7 Likes
Just saw this and this is exciting
https://developer.blender.org/D15535
A question though
the number of channels and data type will depend on the CMake configuration where spectral rendering will be enabled or disabled.
Does it mean the switching of spectral and RGB will be a CMake build option instead of the runtime check box? Is this switch going to be kept?
This patch only adds support for choosing spectral or RGB as a build option, but the CMake configuration is the same one used in previous builds where runtime switching was possible. The only difference is that you need two compiled kernels, instead of one, with spectral rendering enabled or disabled, which should be straightforward to implement with this patch. So it’s not a problem to add it in the future. The only concern I have is nearly doubling increasing by almost 30% the size of Blender installation.
12 Likes
How can it nearly double?? It’s not like 90% of Blenders Filesize is Cycles Kernels right?..
You’re completely right, I went overboard with that number. An unpacked Blender 3.4 folder takes up 804Mb, 236Mb of which are Cycles kernels. Adding another kernel would result in an almost 30% size increase, which is definitely not double, but still a substantial amount.
3 Likes
People are using ACES and their LUTs, what doubles your blender install file size, but they do it for a reason.
Also wouldn’t be a big deal because you’re not downloading Blender every day. Even when compiling it, you download only the changes…
Luxcore is 185MB for example.
And since we have the choice of different builds…
1 Like
The current build times and size of kernels are already problematic, we’re not likely to double that for one feature, Additionally, 8 wavelengths add significant memory overhead to the GPU, and require more memory bandwidth. So before we consider this, it should be shown to decrease noise enough on production scenes, to make up for increased render times and memory usage.
3 Likes
I think 4 wavelengths has been shown to provide reasonable noise performance with the memory impact being much less significant, so unless there is much better noise performance with 8 in the majority in scenes (there will always be edge cases where 8 performs much better) I think 4 would be a better default choice.
1 Like
Why keep rgb and spectral side by side then? why not just scrap rgb when spectral is obviously the way forward? Is it too early to consider this? sorry if this has been answered before.
1 Like
From what I have seen in previous spectral branches, 8 wavelengths would give an almost color-noise-free render right from the start, 4 wavelengths seems to be faster but with some color noise present. Can this be a runtime setting with default set to 4?
Some people might be doing , say NPR etc., and thinking spectral to be overkill. I guess it depends on how much the community want to keep the RGB renderer. Think about it, replacing the RGB renderer is so much easier than having it side by side, not need to worry about installation size anymore, no need to worry about potential issue with RGB-incompatible spectral nodes anymore, etc. But there are people still want the RGB render, even just for backwards compatibility etc. And there are people don’t agree with the increase installation size on the side-by-side direction as well.
I am personally fine with both direction though, side by side or just spectral. It’s fine for me.
4 Likes
We need to see renders of our benchmark scenes with time/memory statistics, not anecdotal evidence.
We have a benchmark script to compare equal time renders. I’ll check that once there is a patch submitted with actual spectral rendering, and then we can decide from there.
24 Likes
Most of the benchmark scenes afaik are unlikely to benefit significantly from spectral rendering. I suspect the Sprite Fright scene might show some appreciable differences based on the relatively high saturation colors of that though…
I don’t think this necessarily is gonna do much for noise reduction. It’s gonna be better for correct hues in deeper bounces though, avoiding a bias towards the primaries, and allowing the correct handling of deeper saturated colors. It may therefore be more relevant together with recent in-progress additions that are better at capturing relatively complicated deeper paths to get more accurate indirect light…
The concern is not “what good will spectral bring” I believe, but the performance impact to have 8 wavelengths vs 4 wavelengths per ray. If 8 wavelength reduce color noise enough compared with 4 wavelength it might justify its performance overhead.
3 Likes