The difference in the final image is subtle, sure, but how much does it change shader development? How much does it change lighting? Does anyone have spectral hdris out there?
It just seems like a can of worms, and no amount of suzanne in a nightclub renders really convinces me otherwise.
Is there no other way to do the toggle (as in, a smart kernel with modules that can modify various algorithms)?
I guess with path guding, MNEE, many-light sampling, better sampling in general, and some additional tonemap options, the devs. could theoretically just scrap the older RGB stuff altogether.
In my mind, the introduction of Eevee has freed Cycles to a path that pushes realism (along with its next big iteration underway as we speak). In addition, assets optimized for spectral rendering and more advanced tonemapping will never be created if no one is willing to break the ice in the first place. For instance, PBR forced changes in the way texture maps are made and it turned out okay.
I have heard about Mitsuba 2 being âretargetableâ in that it can be RGB and Spectral at the same time without much change in code. But for Cycles I donât think so.
Itâs not like people just need to engage a âspectralâ filter in photoshop when making assets.
it is a fundamentally different and significantly more complex issue that is way beyond the scope of blender or 3d rendering even.
I feel like for many users, they hear that spectral is more realistic and then they want it. Look at the glistening realism of colorfully illuminated suzanne above. itâs not a magic bullet, itâs an incredibly subtle effect in most real world cases.
It would be much better to build a spectral renderer from the ground up, rather than trying to shoehorn it into cycles.
Again for RGB textures they will be spectrally reconstructed. Not sure whatâs the problem for you?
That sounds like RGB kernel and Spectral kernel side-by-side, if you swap the word âkernelâ out with ârendererâ
I guess when I hear âspectral rendererâ I imagine that itâs spectral end to end. but if itâs 98% rgb with some spectral transforms in the middle and thereâs no major side effects, then whatever.
In terms of the steps being made to improve realism, even if it became common for everyone to engage in an end-to-end spectral workflow with tonemapping optimized for HDR monitors (to create incredibly photoreal imagery that makes todayâs work seem primitive), that still leaves the question of how to do the last step for some which is printing.
For instance, you canât break physics by making paper that reflects more light than it receives (unless you can find a way to power it which creates different issues), and spectral ink that can take on unlimited HSV values as it leaves the cartridge does not exist. Translating that in a decent manner will likely become more of a development focus in the future.
Print color is certainly as complex and difficult an issue and render color.
But print is also becoming less of a market. There are and always will be things that need to be printed, but a lot of stuff is moving digital. Printing is still an expensive endeavor, in some cases the price per square foot for a printed image on a substrate is more expensive than the equivalent square footage of a flatscreen tv. like all the menus in fast food restaurants that are digital now. especially for something that you are going to be changing seasonally.
Yeah Mitsuba 2 was designed from the ground up with this possibility in mind. Itâd probably require rather deep changes to get there in Cycles
Not whatâs going on.
You are conflating the ability to render with spectra (which is, in fact, end to end) with the direct use of spectral data (which is going to be more situational)
The RGB-to-spectrum upsampling is a fine approach to support both old and new workflows. Most materialâs spectra in the real world are pretty flat so you can actually rely fairly well on RGB-based spectra reconstructed that way. You still get much better appropriate color mixing and appearance of indirect light either way.
In principle you could also have multiple upsampling methods side by side (with a sensible default so itâs almost never a big deal) - in fact different models already exist in RGB Cycles (aside of directly picking RGB values you can also pick based on wavelength or based on black body radiation), except those are currently pretty poor approximations of the phenomena they try to capture. In Spectral rendering they could be native
And if having the actual exact spectrum really matters for your use case, thatâs precisely where the RGB approach would break down completely.
That said, if you have easy access to spectral data for a variety of materials (say, certain metals or water or glass etc), you can set up materials near-perfectly with very little hassle.
Use the spectrum if you have it, rely on upsampling if you donât. Itâs really not a big deal.
You are correct, though, that most scenes arenât gonna look vastly different. Mostly itâll be subtle.
The most obvious situations are gonna be
High saturation colors of different hues interacting directly (@Eary_Chowâs examples above are of that kind)
Scenes where indirect light or deep bounces matter a lot (correctly rendering facetted crystals with lots of internal reflections for instance, or highish density scattering materials)
Absorption - thatâs probably the single most obvious situation. Absorption is effectively the same as continuous bounces, so you arrive at the equivalent of deep bounces pretty quickly. RGB Cycles will have skewed far more to a primary color (pure red, green or blue as defined by the color space you use) by the time the tint becomes significant, than Spectral Cycles.
Itâs also the thing where itâs perhaps easiest to come by specific measured spectra. There is quite an abundance of freely available absorption spectral data.
Would spectral cycles also make it easier to facilitate things like refractive dispersion, iridescence, fluorescence, interference, Rayleigh scattering etc.
There are techniques to approximate this with RGB based rendering as well but yes, in a Spectral renderer this would be rather trivial. Just have a spectrum in the Fresnel node instead of a single constant and youâre set.
The approximations, afaik, amount to approximate a spectrum in just a single bounce, giving you a nice single bounce dispersion. It probably couldnât work the other way, combining a rainbow to get white.
There is a simple double prism setup to test this. It first splits white light into its spectrum and then, in a second prism, reverses that split. I donât think an RGB based version could do that.
Of course, for that to matter at all, you also need much more efficient caustics. Which it looks like Cycles might be getting now between MNEE, Path Guiding, and potentially* Many Lights Sampling. Those three together should really make that particular application much more relevant
(* I say potentially because Iâm not sure Many Lights actually helps with caustics in any way. It certainly seems to have big benefits with noise and fireflies though)
If you look at Luxcore Render, it is RGB-based, but uses spectral calculations for specific aspects, such as dispersion.
I believe that full spectral rendering is not usable for production because all assets, workflows, digital cameras and knowledge is using RGB. In this non-perfect world, it is best to work in RGB but have optional features to add spectral rendering.
My ideal would be that by default it works in ACEScg internally, sky, wavelength â rgb nodes converts ACEScg, there is spectral â RGB conversion in ACEScg node, sRGB textures are converted to ACEScg. I do this by custom setup and using python scripts. Not yet spectral rendering there.
But then it would be great if it is possible set multiple material IORs to different wavelengths and volume rendering works in different wavelengths because dispersion/photon mapping and some underwater scenes benefit when spectral calculations are done.
I was speaking for âmost of usâ, not âeveryoneâ. There will always be the outliers doing office spaces and then trying to battle realistic lighting from fluorescent lights looking bad. Photographers worst nightmare, worse than mixed regular light temperatures as at least those look natural. Same with chromatic aberration; photographers do everything in their power to hide it, render folk add it to âadd realismâ.
I think the point is there donât exist texture data for spectral absorption. Are there any special cases and data for this? I mean we could get the emission spectra for different quality LED sources, but probably not the absorption spectra for different materials under different light sources.
If it had zero to little cost attached I wouldnât hesitate. If RGB is swapped out for spectral with no other additional concerns, I donât really care. I.e. are AI denoisers as good on data originating from spectral compared to RGB where they were trained? Even if they work on final RGB output, spectral may cause pattern changes that denoisers fail to spot. But at the current cost, going spectral wouldnât be high on my priority list.
Yes thats pretty much it. Another thing is that more calculations have to be done during rendering, so another drawback is an increase in rendertime.
Thatâs somewhat of a misunderstanding of what spectral data provides. One big advantage of spectral data is that youâll only need to take it once and then, no matter the light conditions, itâll look correct. Thatâs kind of half the point of taking spectra in the first place.
Not quite sure what you mean here. In principle you can do spectral textures, though those would be enormous and impractical. You can still use RGB textures in spectral workflows though. The way to do that ends up being a guess of sorts, though, given sensible methods, a pretty darn good guess. Under a specific lighting condition (lit with âwhiteâ light from Illuminant E) it will look exactly like the RGB color, and otherwise itâll end up looking more like that color than in an RGB workflow, because there are plenty of, say, greenish wavelengths in your average red light source, but the green and red color channel are completely independent, so shining a red lamp on a green surface will look black rather than like yellow as itâs supposed to.
Effectively, spectral rendering would be 100% backwards compatible, though itâd give a slightly different appearance
I am not sure we are talking about the same thing? Does it make sense for if a person wearing red clothes standing under green light looking like they are wearing a black clothes? Does a blue car under red light looks like a black car in real life? Would a photographer deliberately grade their blue cars under red lights to black? Are we even talking about the same thing here?
First of all there actually are openly available databases for spectral absorption, @kram10321 had done some test against the 2.93 version of Spectral Branch back when spectral nodes were there.
But the important part is, again, you donât need to use spectral data if you donât want to. RGB textures will always be reconstructed into spectra under the hood before they are fed to Spectral Cycles, your user experience will basically be the same as before.
Actually with the help of Hero Wavelength Sampling, the performance impact has been minimized so it will not be that big of a deal.
Hi guys, Iâve split the extensive spectral Cycles subdiscussion from the regular Cycles Development Updates thread to this dedicated one. Please feel free to continue the spectral Cycles discussion here, thanks.
I canât imagine people would want a future where every piece of framed work in their household becomes a glorified TV that needs reliable power to enjoy. I will also note that physical media is also useful for creating a wider variety of items than just albums or wall displays,
In addition, printed media cannot be damaged or destroyed by computer viruses, by software bugs, or by not transferring the files to a new machine by accident. Physical media can be destroyed as well, but it is often the result of the owner being negligent in protecting it.
For media that changes frequently (ie. a restaurant menu), digital displays may be more practical. For something that has no need to change over the course of decades, not as much.