I have been working on a new branch which just contains a type alias for scene colours. This won’t influence the operation of Cycles at all, but lays the groundwork for later replacing the implementation of this type with a representation of a spectrum.
It’s still failing to compile, but I’ve gone through a diff between master and the spectral branch and teased out what changes are relevant to the types, removing anything related to adding spectral functionality. I hope with a bit more work I can get this compiling, then start addressing some placeholder TODOs I have added, before submitting it for review.
This isn’t anything to do with spectra yet. This type represents a colour in the working space, which is used for representing things like diffuse/emission colour (pretty much anywhere you think of using a ‘colour’ in Cycles). Functionally it’ll be identical to how things already are, but this will later allow SceneLinearColor to be implemented as spectra (and renamed if necessary). This is just a lower risk way of making progress to having spectral Cycles.
Is the old version (before this restart) completely broken or could that be salvaged too? I’d really like a fresh build, ideally including the spectral nodes (not just spectral rendering as such) in order to properly test this stuff:
As far as I know there have been a bunch of color management fixes since, so a version working with Master would be great. And I currently only have the RGB version of the spectrum-to-color node which is not ideal for this purpose either.
I don’t think reviving the old code is a high priority for me at this point. I’m definitely looking to implement some core spectral nodes as the first ‘feature’ improvement over the core ‘render RGB data in the spectral domain’ change. These nodes would likely be spectrum curve and spectrum math nodes. These should give people a useful starting point to implement experiments like this, even if it does take a bit more work than it would be if there were dedicated nodes for these things.
The current ‘types only’ change still needs some changes before it compiles, but that is my focus at the moment. Once this change is in, adding spectral rendering should be a significantly smaller task.
The unfortunate downside to focussing on things which are intended to be merged means that we can’t just go off and build feature after feature - the impressive work that was done to develop all of the spectral features we had in the old branch would only really work if we maintained a fork. Rather than diverging and putting a lot of effort into things we think are cool, I think it’s important to align and work on what will benefit Blender overall.
glad to hear things are happening quietly in the background
I know it’s ways off for now, but aside of Spectrum Curve and Spectrum Math I’d also like to see the following as base feature set:
Map Range (could be done with Math in principle but it’s immensely useful for certain tasks including if-statements)
Wavelength (basically gives a single wavelength according to the input - I think in the old build we didn’t have that but, instead, got the Gaussian Spectrum node which could pretty much emulate it by selecting a really small variance?)
Blackbody (Spectral blackbody looks just so much better than the RGB version thereof)
And I’m really hoping the Spectral Math node will include trig functions. If you recall, those were necessary to construct Complex IoR shaders for instance.
Very much looking forward to getting new builds again, especially looking at all those shiny new Cycles features we are currently getting.
I think I also need a working spectral Cycles X based on the latest 3.3 to test AgX since pre 3.2 versions have OCIO bugs. I agree focusing on the patches to submit now is the correct thing to do, but is there just a 3.3 build or something available? If no it’s fine.
I think we have not met consensus with Brecht etc. about these features yet, if I remember correctly Brecht didn’t want to have wavelength related utility nodes, only BSDFs. So maybe focusing on individule patches first, and discuss these designs along the way…
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.
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.
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…
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.
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.
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.
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…
