I’m back at working on this, and would love to get some tips on a few things:
- I still can’t get to the bottom of the issues I’m facing with volumes. If I could have a chat/and or get some assistance from someone who knows Cycles somewhat well that will solve the last aspect of materials.
- I would like to start introducing some ways of using spectral data so someone who understands how nodes relate to Cycles, very keen to talk.
I appreciate all the support I’ve received so far and looking forward to chatting with some people. Hopefully can make some decent progress on this.
@StefanW I thought you might be a good person to talk to if you have some time. Let me know if so.
19 Likes
I’ve just merged from master (2.90) to incorporate the latest changes from master, so there should be an updated build soon.
9 Likes
Apart from volume scatter still being ‘unstable’ and not behaving predictably, volumes are working. Adaptive sampling worked a treat to cut down on render time here.
I’ll move on to getting custom spectra working, if anyone has worked with Cycles nodes before please let me know.
18 Likes
as a starting point, those volumes look really good! Looking forward to a fully working version. I think I like what I’m seeing in that scattereing cube if I take those noisy colors to be converging towards some smooth gradient.
Is this already in the build you mentioned? I’ll be sure to make some tests asap. (Although this is definitely where my computer is gonna be a problem. Volumes are very slow for me, even in regular Cycles)
@LazyDodo’s build doesn’t seem to have refreshed yet, but I think this behaviour is likely the same in this build anyway, just the 2.90 changes won’t be in there https://blender.community/c/graphicall/nkbbbc/
This is a denoised 16k sample render of the volume, so the ‘fully resolved’ result also seems to have some issues in it, but it is getting there for sure. I think the biggest issue is the massive amount of fireflies created, which would suggest to me some bad math going on. I just don’t have a good enough understanding of the scattering code to see what’s wrong.
Feel free to test, keen to see what results come out of it, but I’m pretty confident any odd behavior you find in scattering would be the result of a bug. This latest render took 1.5 hours and it’s only a few hundred pixels square, I feel your pain. I’ll hopefully upgrade my computer some time.
2 Likes
If you’re building from source then you’ll be up to date on either mine or Troy’s repositories.
have never tried building myself. I don’t have time right this instant anyway. I’ll get to it in a few days at the latest. Today is unlikely though
1 Like
Maybe I’ve been crazy all along, here’s the same scene in 2.90 spectral and 2.83. There are some subtle differences but I don’t see the instability in the scattering I did with a pure colour. Instead it seems like indirect light is missing something.
Spectral:
RGB:
512 samples denoised with [1, 0.4, 0.2] for the colour, and density at 5 for scatter and 1 for the other two.
4 Likes
The daily build got updated, thanks @LazyDodo for having this set up for me.
Big news!
Thanks to @pembem22 the render time of Spectral Cycles has gone from 151% of master, to just 111%, only 11% slower than master! Massive thank you to pembem22 for the PR, such a simple change but such a huge impact.
The LazyDodo build is up to date.
10 Likes
Thanks very much @LazyDodo
2 Likes
Interesting.
Emission looks practically identical.
Absorption ends up being quite a bit less saturated with the chosen color. However, it also looks more hue-constant if compared to the emitter version.
Scattering clearly has the biggest difference and I feel like there gotta be a bug there, but it still looks nice and not too noisy
That’s amazing! What exactly changed to make that work?
I have quickly redone one of my earliest tests wherein I tried out spectral absorption by faking it with nodes. Here’s the same thing with proper volume absorption. It’s not the most informative of tests and the conclusions don’t change from last time, but I figured why not redo something “properly” which I previously only could fake?
Also it just looks really pretty.
RGB:
Spectral:
You can clearly see how the spectral version preserves the hue of the absorption color (RGB 0.9 0.5 0.1) much better than the RGB version in which the blue contributions very quickly fade to 0 whereas the red contributions stay pretty intense.
__
One more I’d love to redo once proper spectral color input exists. In this one, the only light source is a plane light source which varies along the y-coordinate with a spectral color node which, of course, isn’t actually spectral color. It sits in a box which scatters light, fully white, density = 1.5.
Spectral looks more greenish which, I assume, is due to how strongly green spectrally overlaps with red and blue.
RGB:
Spectral:
1 Like
Yes there seems to be a bug in indirect light in volumes which leads to the lack of coloured shadows and introduces significant error in the scattering.
Some optimisations were made to the functions responsible for converting between spectral and RGB, removing some of my very inefficient code.
Thanks for those tests, I’ll definitely try to get more progress on the spectral input front - pembem22 actually mentioned he was experimenting with it, I’m excited to see how things go from here.
6 Likes
One more quick test: Something that might be Ametrine. For the most part, the RGB version looks brighter and more reddish than the Spectral version. But íf you look carefully, one of the biggest differences appears to be an internal reflection near the bottom right of the Gem, which doesn’t appear at all in Spectral version. Only in the RGB version is there a purple shine. Other spots nearby feature a blue region in the RGB version that should quite clearly be purple, which the Spectral version maintains.
RGB:
Spectral:
Other than the overall more pronounced reddishness, you’ll likely mostly just see these differences if you actually look at it at full resolution.
Honestly, the enhanced hue-stability of indirect or absorbtion-colored light is one of the biggest benefits of spectral rendering thus far. Because unless we’re talking about some really weird spectrum, deeper bounces in the purple region should definitely not become blue.
I’ll have to think about clearer volume rendering examples, probably ones including scattering, which don’t at the same time destroy my computer…
A massive thank you to @pembem22 for submitting a PR enabling spectral data transfer between nodes, and converting the Blackbody to output spectral data. This is a huge milestone. Hopefully some sort of custom spectrum input method will be coming soon, that’s where we’ll start to see the biggest differences, but already this is quite a stark difference. Images by @pembem22 from the PR.
Master
Spectral ‘RGB Blackbody’
Spectral Blackbody
14 Likes
