Now that you mention this, I think I remember that volumetrics on GPU had some limitations compared to CPU. Even the .blend file of this old report of mine still gives problems with hybrid GPU+CPU render in 2.93 and 3.0 (Black tiles in 2.93 and Black bands in 3.0)
https://developer.blender.org/T52013
and now I see where the node configuration I was using came from
@YAFU and @slowburn
With regard to the volumetric situation and differences between Cycles in Blender 3.0 and 2.93 and GPU vs CPU and such, here’s some information that might be useful:
In Cycles there are two ways to sample a value. “Distance” sampling and “Equiangular” sampling. Cycles by default uses the “Multi-importance” sampling method which means it picks the sampling method that is believed to be the best for the object in this scene.
With Cycles in Blender 2.93 the CPU supported “Distance” and “Equiangular” sampling. The GPU only supported “Distance” sampling. This means you might render a scene in Blender 2.93 on the CPU and it’s relatively noise free at a low sample count due to “Equiangular” sampling. But if you render the same scene with the GPU which only supports “Distance” sampling, it might look noisier at the same sample count. (Note: Neither “Distance” or “Equiangular” sampling is better, they’re better in different situations)
In Blender 3.0 with the Cycles-X merge, both the CPU and GPU support “Distance” and “Equiangular” sampling, so now the difference of CPU vs GPU with different sampling methods shouldn’t be an issue (there still appears to be some small differences though). But, as @YAFU has pointed out, volumetric objects in Cycles with Blender 3.0 does appear to be noiser than 2.93. And it’s not because of the sampling method difference.
So hybrid GPU+CPU render with that “Volumetric World Texture.blend” file from that old report shouldn’t give problems in 3.0?
Can you reproduce that black bands in 3.0 with GPU+CPU in that file?
(it is the GPU that contributes the black part)
Yes I can.
GPU: RTX 3090
CPU: Ryzen 9 5950X
This should be reported as a bug.
Thanks, @leesonw @mib2berlin
Bug submitted: ⚓ T92015 Renders don't work, and viewport bug
For the record, it doesn’t render, but it also quits when switching from shading rendered mode to solid.
@YAFU I have made a bug report for the issue you talked about here: ⚓ T92036 Cycles: Certain Volumetric World Shaders render differently with the CPU and GPU
ShaderNodeLightPath not work properly.
result of (cycles-x.342cdb03ee06) and (master.a78d3c5261b5)
This should be reported as a bug on https://developer.blender.org/
Yes please report this, with a sample scene if possible 
A general info: Please report bugs to the bug tracker (Use Help → Report a Bug from within Blender). We cannot keep track of issues reported here.
OK, I will report this with a sample scene. And here is another thing, transparent bsdf seems have a fixed refract ior like 1.45 or 1.60 which is much higher than I wanted. Is this possible to reduce this value by using graph/node tree? If not possible, I may change the source code, but I only find blender\kernel\shaders\node_transparent_bsdf.osl.
#include “stdcycles.h”
shader node_transparent_bsdf(color Color = 0.8, normal Normal = N, output closure color BSDF = 0)
{
BSDF = Color * transparent();
}
No idea where transparent() function comes, it is not in stdcycles.h.
The transparent BSDF does NOT refract light. You are probably observing some other effect.
Thank you, my mistake.
Hi.
About defaults.
Since new AI denoisers handle fireflies correctly, is it worth it to continue clamping indirect light by default? I also think I remember reading that default Indirect Light clamping=10 was causing some problems with Nishita Sky Texture. (Edit: Default Clamp)
About Light Paths, I have noticed some times that for glass/transmission materials to look better it needs a bit more Glossy and Transmission bounces than the current default values.
I would personally be in favor of the indirect light clamp being increased. However, I believe setting the value to 0 (no clamping) is still a bad idea. From limited testing a value like 50 seems to be better. As it still reduces fireflies but doesn’t decrease the brightness as much as 10.
The reason I’m suggesting leaving clamping on is to continue to reduce fireflies is for people who do not wish to use denoising, or for people who wish to mix the noisy render result with the denoised result in compositing for “artistic effect”. And with adaptive sampling being the default, you can get some issues with fireflies that could potentially lead to denoising artifacts if no clamping was used.
Agree that the default light bounce can be higher, there can be some really obvious difference:
Probably also volume:
I have heard several times people complaining to me how Cycles volume scatter is dirty and heavy, then I asked them whether they set the light bounce higher, they would tell me they never touched it, didn’t even know it exists. So I think it makes sense to have the default be higher.
While I agree that 4 glossy bounces is not enough for rendering glass, 10 bounces is usually more then enough even for ill cases. It would be cool to make trapped rays escape glass after the last bounce by default, not just them being killed causing black areas around glass lips. So far I have to repeat the same shader setup over and over. Dispersion also would be welcome, but that requires either random per ray or spectral rendering =)
Is the dispersion parameter for transparent shaders planned for any future of Cycles, please?
Not Transparent shader I think. But generally speaking I imagine that will be the task of the future for the Spectral Cycles branch after it completes the initial merge (hopefully in 3.1 or 3.2) :
This is probably not related to the topic here so if we are to discuss more about dispersion we should better move on to the the spectral thread.
Hey, I have CyclesX crashing on so many scenes currently random.
How can I see the crash log? To report the bug
