Thoughts on making Cycles into a spectral renderer

Is there a road map or something showing where the progress is currently at?
I am really interested in this project but don’t find any information of how far you guys have come over the years

Thank you in advance & Thank you for everyone involved with this!

1 Like

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.

25 Likes

Is there a branch build we can test now?

7 Likes

Awesome, is there a MacOS build?

I don’t have any Apple devices, so I can’t make a macOS build.

Hmm ok, I’m super anxious to test this out.

1 Like

image

these reddish artifacts at the bottom do disappear over time but initially they are really prominent and clearly affect the render result. I’m assuming that’s some sort of bug

It’s not consistent tho - second time rendering it, it didn’t happen

Edit: It may just be happening on first render? Seems fine ever after, or that’s my conclusion right now

Here is the finished result (using AgX)

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

12 Likes

Bug when turning off scene world in GPU mode:

EDIT:
Actually, enviornmental texture is unable to work in GPU mode at all…

Interestingly sky texture works:

Hmm no, bugged again after tweaking the settings

2 Likes

This is currently roughly the most extreme thing to expect to come out of this branch (until further features are added)

RGB:


Spectral:

29 Likes

is this a volumetric scene ? Also what color management is used ?

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.

The color management is a recent version of AgX

7 Likes

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.

I am seeing huge difference between CPU and GPU results, here is BT.709 blue light shed on BT.709 blue cube:

(view transform is Guard Rail, so no de-abney flourish applied)

The GPU result seems to be bugged, it looks so much more cyan than it should be.

GPU final render seems to have some kind of scaning lines artifacts:

The artifacts keep changing during the sampling process, and stopped changing after sampling ends.

5 Likes

did you try it twice? Second time tends to work fine for me

1 Like

It keeps happening on my end.

Since there’s a new build and I was curious I thought I’ll join the fun.

RGB Cycles / sRGB Standard:

RGB Cycles / AgX:

Spectral Cycles / sRGB Standard:

Spectral Cycles / AgX:

Encountered bugs on the spectral build:

RGB input crashes build:

Map range outputs single “channel” scalars, gets rendered colorful:

The test scene is based on krams test images above. In case anyone wants to grab it, feel free:

19 Likes

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

7 Likes

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.

I’d very much love a more interactive/dynamic support for OCIO, yes. I think it’s on the radar in theory, but at a very low priority?
At any rate, it’s entirely independent on the Spectral branch

1 Like