https://developer.blender.org/D7896
Patch is ready for review!!
25 Likes
Congratulations! 
2 Likes
Windows Build (Test it!)
Well done, @nacioss just tested the windows build, even with the issues mentioned here of the MIS (which is not your fault) I believe this patch is production quality worthy!!
Not sure if the devs will approve it without the Eevee support, but 5* for the cycles support so far.
Kudos
1 Like
Hi
I made a macOS build on GraphicAll if any macOS users want to give this a try.
1 Like
@nacioss thank you for your work and sorry for my comments on the review page. Actually I wasnât aware of this discussion here.
With precomputation do you still use 11 wavelengths model? It looks quite different than 81 one.
No problem 
Yes it still does, and you see a difference because iâve put the 2 images one below the other and this gives the illusion to the eyes that itâs quite different, try this, try to open them in a new browser tab and then switch between them to see that the difference is really subtle
1 Like
Did that already, but thatâs not the point. Problem is that lower part of the sky differs mostly (itâs more saturated and more towards cyan) and when rendering ground level views with focal lenght about 30mm and having camera leveled this part of the sky will be lot more pronounced. Need to do quick test to show this.
Ok, waiting to see the results, meanwhile we are doing the precomputation part multithreaded so that we could maybe make use of 21 wavelengths instead of 11
1 Like
Perhaps make it a variable? if people wanting to pay the extra time to compute let them select however many they want?
1 Like
Making the wavelengths selectable is tricky since the spectra are hardcoded as arrays.
Instead, Iâd prefer exposing the sky resolution and/or maybe the samples used by the precomputation as variables.
1 Like
Really hard coding the particular values needed for wavelength sampling seems like something that could fairly easily be solved (just by storing the whole spectrum and sampling it where necessary), then the wavelength sample count could be variable. Thereâs no need to increase samples per map pixel (since theyâll always return the same result) but map size could also be increased. I can imagine a simple âhigh qualityâ checkbox could do both simultaneously.
Ah, yeah, the âsamplesâ part was not clear - in the code, that refers to the number of steps taken through the volume as part of the single-scatter integrator, not samples in the usual MC sense.
As for the spectrum - yeah, we could use a denser representation (or some polynomial fit etc.), true.
1 Like
Ah got it, I had forgotten about the volumetric samples. True, this could also improve the quality of things, though I wonder how far its worth pushing single scatter before just jumping over to multi scatter (except that the math becomes harder).
The current implementation also seems like it might be tied to sRGB (though I havenât looked in detail, this might no longer be the case) which might become an issue, so a more generic ân wavelength samples then map to x colour spaceâ seems like a nice scalable approach
No itâs not, the algorithm is only transforming to XYZ color space and then makes use of the xyz_to_rgb Blender built in function to transform to linear sRGB.
1 Like
Absolutely not, think if this choice was decided for every node in Blender, wouldnât make sense at all, this is the part that the typical user donât need and shouldnât care about.
Another thing, those hardcoded arrays are just the output of some formula i have, but converted to hardcoded because using ccl_static_constant doesnât allow to store the results of a computed formula⌠but now you changed the code and⌠we have to talk about that in private chat.
I also donât think the sky should have any unnecessary technical parameters. It doesnât have them in other offline renderers, thereâs no reason Cycles should have them.
BUT:
This only applies as long as the performance is optimal. Given that sky models of comparable quality can be rendered in real time (60+ FPS) in modern game engines, the sky here should not have any noticeable amount of overhead compared to a simple solid color background (aside from the overhead by importance sampling of the sun disc of course).
So yeah, in a nutshell, no cryptic multipliers and knobs belong there, but at the same time, performance has to be on point.
1 Like
Apart the fact that this sky doesnât work in Eevee (and donât think i will implement it in Eevee anytime soon), and so in Cycles it can be acceptable to have a bit more of lag (lower than 60 fps), i agree with what you said, users donât need such parameters like wavelengths or samples, also a quality slider isnât necessary if the sky is already fast enough.
Iâve made a quick, dirty test using pngs from above, 30mm camera with some shift. The difference is not that pronounced but visible: 81w version is more saturated and hues are shifted towards cyan. I canât test other sun angles, but maybe you can generate some low-res HDRIs?
1 Like
Thank you for the test, the difference is still subtle, we for sure will consider using 21 wavelengths instead of 11
If thereâs an optimal balance between performance and quality, exposing no controls is the ideal case.
That being said, if the quality at an acceptable performance is visibly different from the âperfect caseâ, then I would consider exposing an option somewhere in the engine for using a higher quality mode. Any visible difference in a default render is going to be exacerbated by any post processing thatâs done to the render result.
3 Likes