WHOO! Now we’re talking! This looks excellent!
1 Like
Huge props to @pembem22! Here’s to hoping more Stealth Lurkers come out of the woodwork and contribute to shape this into a fully finished facet.
7 Likes
@pembem22 is looking more and more like a god each day. He spotted the bug I had written in the volume code and I think everything is working predictably now. The next daily build should be feature-complete for path-tracing Cycles. 
The same scene as above - I might have changed the settings since the previous test, I can’t remember.
The same scene with a lower scattering density.
20 Likes
amazing. Thank you @pembem22 and @smilebags and everyone who has tested. Looking forward to this 
5 Likes
That means it’s time to start testing on existing scenes for performance comparisons, and time for me to start working on the missing migrations such as in BPT, material previews and baking
13 Likes
Sorry guys this might have been a false alarm, I’m still seeing some issues in scattering which are really difficult to pinpoint.
6 Likes
Looks like we’re getting closer for this to be relevant now: @troy_s is there any update on the horizon concerning a “Spectral Filmic”?
1 Like
Been in a bit of a holding pattern waiting to see the direction that some other gamut mapping discussions evolve toward.
It’s not an easy problem to solve in a way that generates stellar looking imagery by default, and anything less would be problematic.
4 Likes
I can only imagine that it’s difficult. Other discussions? What are the options so far?
It’s wide open, with as many gotchas as there are options.
I always side with the image maker, which means that the display rendering transform bundle should produce a decent image, no matter how hard the image maker pushes the material. Similar to the sort of output you can expect from other mediums such as emulsion film stocks.
Not everyone has the same goals though, so there are a plethora of different contexts.
2 Likes
I can only imagine the funky results you’d get exposing film to pure wavelengths of light. I guess film emulation would be one way of approaching this but as Troy said, there are a lot of different contexts in which ‘best’ could be defined so it’s a very difficult problem.
There seems to be another bug with volume lighting: Apparently, for emission volumes, you need a regular non-black light source with non-zero emission somewhere in the scene or else the color won’t work.
Both of these are rendered in the spectral branch. Exact same scene with a single difference. The white one is when the default light source is either removed, set to 0 power, or set to black.
The material is purely volume emission.
Here is my material, applied to a cube scaled up 10x in object mode. The camera is above it looking straight down.
3 Likes
Ok there are some big differences here. I’m pretty sure there must be some sort of bug but I’m not sure what it is.
I made this scene in Spectral branch first so it’s made to look good there.
Rendered to 1024 samples (adaptive on), and denoised
Spectral: Rendertime a little over an hour:
RGB: Rendertime a little under 11min:
Now obviously the spectral version looks way better.
I noticed a few things there:
Using blackbody temperatures under about 223K (should simply appear black or, for volume emitters, fully transparent), things appear to go wonky. Like, big chunks of the volume go black. Even stuff that’s well above that limit. I’m not quite sure but it seems as if maybe cooler blackbody radiation suddenly just blocks light?
This does not happen in the RGB version. However, there I get this red glow. Which is weird because I also have a gradient on the emission strength. That stuff should render black/transparent there as well!
And as said, huge discrepancies in rendertimes. Like, to an absurd degree.
I honestly feel like something is wrong in the RGB version and something different is wrong in the Spectral version? I’m not sure.
The scene is barely different from the shown node setup. That should already suffice to get these results.
I will say that I did some probably suboptimal things such as cranking light bounces to 1024 and such, so I’m confident that hour long render time could have been a lot shorter. But even so, this seems a bit absurd. Especially seeing as to how I also did that on the RGB version.
3 Likes
Yeah there’s definitely still issues in the Volume rendering. The hard thing is firstly specifying exactly what the correct behaviour should be in the context of spectral rendering, then being able to test that is actually occurring. Thanks for the test. I’m curious to know what’s causing the huge difference in render time, it could just be un-optimised code in my branch, but I wonder if the adaptive sampling threshold meant a lot more samples were used on the spectral one, given that there’s more detail in a lot of the image.
3 Likes
I suppose that’s possible. That in the Spectral version the actual threshold of 1024 samples is necessary whereas the RGB version very quickly finds that nothing would change. In which case I wonder why that same node setup gives such huge differences in appearance.
And as said, something seems to go wrong when you go below about 223K in blackbody in volumes in the spectral version. In RGB you can go to 0 without that issue.
Yep, I wouldn’t at all be surprised if there was some issues with Blackbody still, that was only recently converted and not really tested yet. It seems to behave logically in the ‘normal’ range of a few thousand K.
Hold on, scratch one part of that. I figured out why the colors are so extreme. It’s just due to what blend mode I used. Although the colors still seem strangely extreme in the RGB version. I think the Spectral version might actually be more correct here.
By the way, for the future, I’d love to have an energy output for the blackbody node. Like, what I’d imagine is roughly this:
- Spectral Output: The spectrum corresponding to that temperature, normalized such that the peak (within the visible spectrum) is at 1. (Or maybe the integral below the curve in that range is 1?)
- Energy / Brightness Output: Gives the correct factor, given the temperature, to multiply the spectrum by such that the relative energy output is physically accurate. I.e. if you heated something to the given temperature, it’d glow as brightly as given by the energy output. (Maybe normalized such that the standard whitepoint at, what is it, 6500K? gets assigned an energy output of 1? - what matters is that the relative brightness would be correct)
Because right now I have to fudge it and I think that’s part of what leads to this crazy bright red situation which happens for very cool objects that are somehow still glowing extremely brightly.
Anyway, if you want the file for testing, here it is:
2 Likes
Yeah I can imagine a few different modes for blackbody, having a ‘this is the spectral output of an object at this temperature’ mode would be nice but I can see the utility in a normalised mode too. The problem with the normalised mode is that it leads to nonsensical colours for cold objects. That could be what’s going on for you.
After fiddling with the gradient a bit more, it’s still not great but it’s at least slightly better on the RGB front. Spectral is definitely far better behaved in that sense.
Also this time it took nearly 20min to render this with the same settings. So I think the adaptive sampling hypothesis is very likely correct and it’s actually a great showcase of just how helpful adaptive sampling can be.
3 Likes
Looks like blackbody node is outputting -inf due to precision issues so it just absorbs all visible light. I’ll fix that.
1 Like