we would like to gather feedback regarding the new volume rendering method in Cycles.
Previously Cycles was using ray marching, the problem is that ray marching is biased, so using different step sizes could make the volume look very differently, which becomes especially obvious for overlapping volumes and is difficult to tweak.
The new algorthim is based on null scattering, which automatically finds suitable step sizes, and removes the aforementioned artifacts. In our test, some scenes now render faster, some scenes render slower but better.
The original PR has been merged in main since two weeks. I would like to ask people to test out this new method, tell us how you feel about it, and share your scenes with us. We are especially interested in knowing which scenes see an improvement, which scenes have issues. If some scenes render a bit slower it’s expected, but if it’s more than 5x slower, there’s definitely something we need to fix.
Known issues that we are looking into improving:
Shaders that use Light Path Node could suffer from performance issues. We rely on pre-evaluating the volume density for computing the suitable step sizes, so if the density changes on the fly, things become more complicated.
First of all, let me thank you for investing such a lot of time and energy into adding this new feature.
I can say that I totally love it. I always hated having to tweak step sizes and max steps to get the best result in the shortest amount of render time. Now I know that I’ll get the correct result while only having to deal with adjusting the samples to clean up the noise in volumes basically.
Of course I hope that some speed improvements will be found and implemented, but after all I’m really liking the direction this is going.
this is very exciting, I am glad that volumes are more reliable now. However if “5x slower” (at equal noise level I assume?) is the cutoff to determine whether or not a fix is needed, I think that should be reconsidered. A 5x slowdown is really quite dramatic in a production context where rendertime and money are concerns. I am certain you are well aware of that being in the position that you’re in, at the Blender studio, but I feel it can’t hurt to stress it.
My use of volumes is mostly contained to homogeneous, low density volumes such as atmosphere scattering or water absorption for scenes like shown below, so going by what you said on the PR discussion, I don’t really expect problems. I will take a stab at 5.0 as soon as I can to assess the impact on my scenes (am on 3.6 LTS now) and report back.
Hi!
I have always been very enthusiastic about the volume effects in Blender, and Null Scattering is an update I have been looking forward to. However, I have encountered extremely severe performance issues with my commonly used procedural volume cloud shader.
I believe the performance issues I encountered are mainly caused by two reasons. First, as you have noticed, the light path node, which dynamically adjusts volume density based on ray depth, a common optimization method, has brought a significant performance loss.
Second, it is the more complex and difficult-to-calculate procedural volume cloud generation method that I am using. My method uses two 4D noise textures to displace two gradient texture nodes and blends them together using the maximum value. I am using an RTX 5080 for rendering, and below are some rendering tests.
As shown above, even after removing the light path node from the shader node tree, the overall rendering speed is still significantly lower than that of the ray marching algorithm. I will attach the Blender project file I used, which includes the complete shader nodes and the geometry nodes for procedurally generating volume fields and writing data. I will upload the entire project as is, but if you need a simplified version, please let me know, and I will try to simplify it. Google Drive link for the project file
Just a regular VBD and environment texture, 32 Volume bounces for both of them. 5.0 doesn’t have these some artifacts that 4.5.1 has, performs faster (in this scene).
It does feel like 5.0 “erodes” a bit the volume
Hey! I’ve been rendering a bunch of volumes with a bunch of noise textures controlling the density (Gleb Alexandrov’s nebula setup) and I’m hitting quite a few artefacts I can’t seem to avoid with unbiased rendering. Render times on this test seem to be about 3 times as long for unbiased.
Okay, but maybe we could keep the old method? That way, you would be able to switch to a biased model just to cut some render time if the visual difference in results doesn’t bother you too much.
Upd* Sorry, didn’t see that we already have this option.
I wanted to give my feedback on the new volume rendering in Blender 5.
All procedural volumes experiments I made in the past (which worked very fast in the viewport render preview ), now became extremely slow.
To the point that I can’t even navigate the viewport in render preview.
Once I re-activated the good old “biased”, the performance is back at being VERY fast.
Hope this helps.
Here some examples of volumes I tested it with, they are all mainly volumes coming from noise textures in the shader basicly:
