Cloud noise

[WAS]

I did not expect that I would need such extreme values for a relatively simple scene like this, but now I know better. Thanks again for the help everyone!

Lighting really effects a scene substantially when it comes to atmosphere/cloud noise.

[D.A. Bentley (SuddenPlanet)]

One other setting you could turn down to speed up renders is under the Render GI settings.  Go to the 3rd tab and look for Cloud GI max ray depth.  I think you had it at 2 in your scene, so try setting it to 1 and see how much faster it renders.  Glad you figured out a solution for your scene!  I learned something new too thanks to WAS. 

-Derek

[Tangled-Universe]

Seems a few beat me to it with some advice, but I will share my findings anyway.

Attached is a collage of renders I did of this scene.
The text can be a bit cryptic, so please let me clarify:
PNT = pixel noise threshold for the AA sampler
vox = number of voxels in millions (M)
vsq = voxel scatter quality
crmq = cloud ray marching quality

Why the larger renders?

Being here for quite a few years many discussions about cloud noise are being guided/led by small crop renders with relatively small clouds compared to screen space and somehow those perceive way more noisy to me as when rendered at higher resolution.
I think with small crop renders we are literally "pixel peeping" at noise, similar to how photography forums are plagued by people judging lens' sharpness or microcontrast by zooming in at 200% or worse.
With larger renders you have more context and more information on how AA samples the gradients in the clouds.

Anyway, that's personal and a bit fact-free to some extent, let's have a look at those test-renders, because facts are facts.

As suggested voxel scattering quality is important. Very important!
I'd say or admit...I didn't know until now that it was that important in relation to performance and visual quality.
As far as I know the max setting of 400 is internally also the hard cap. Voxel scatter quality >400 will be clamped at 400.
Matt may correct me if I'm wrong, but this is what I remember from an alpha release note.

Edit: I was wrong!

But also voxel number can be important and increasing it can even reduce render times!
In a way it could make sense, as voxels are closer to each other and things like voxel shadows are defined in absolute distance in voxels.
Thus, increasing voxel number makes each voxel more similar to its neighbouring voxel and is easier to handle for AA. Something along those lines.

Apparently, with enough voxels and high enough voxel scatter quality the smoothness of the cloud isn't dictated by PNT very much anymore.
Shooting more rays it at, like with AA16 (bottom right) doesn't help much anymore and only increases render times unnecessarily.

[Matt]

There is

As far as I know the max setting of 400 is internally also the hard cap. Voxel scatter quality >400 will be clamped at 400.
Matt may correct me if I'm wrong, but this is what I remember from an alpha release note.

There is no limit on voxel scatter quality. In 4.5 alpha the slider range has changed, but you can still enter higher values by hand.

[Tangled-Universe]

Thanks Matt for the correction, it's important I do not cause confusion or the like!

[Kexikus]

Thanks for these detailed tests Tangled-Universe!

I'll definetly keep in mind how important the number of voxels is, especially since it seems to improve both render quality and render time.

[WAS]

I think it's very important to note RAM usage when fiddling with "VOX" (MOX seems more appropriate). For example, going from 10 to 300 results in a 9.25gb jump in RAM (on my system and scene with just made a v3 cloud layer). In fact it would be cool if this setting didn't go above 1000 unless you are stepping (arrows up and down) to prevent DIMM damage in case of system failure (even 1000 is high, and maybe this cap should be calculated based on available system ram).

The reason for this fail-safe is that it's easy to accidentally enter a stray number(s) and crash TG, and I've enter a couple strays before and had BSOD related to RAM failure (forget specific error).

Also not sure why this feature doesn't cache to disk like other stuff in TG. Maybe cause of how quick it inflates in RAM.

[Tangled-Universe]

Yeah I did not think about checking RAM usage, I was experiencing a kind of tunnel-vision for quality vs render-time.
Indeed, increasing voxelcount can dramatically increase memory usage. Honestly I don't know if 300M voxels use the same amount of RAM for every scene, or whether if there are others factors at play which may reduce or increase the amount being used.
The only beef I have with high voxel numbers is that if you save the .tgd with high voxel numbers then opening the project and getting started with it is usually considerably longer.

[WAS]

Honestly I don't know if 300M voxels use the same amount of RAM for every scene, or whether if there are others factors at play which may reduce or increase the amount being used.

Oh most certainly, though I can say mine was just a slap in v3 and less total coverage and complexity than this scene, and tighter edges, but the density probably place a big factor.

His scene starts at 2,999.0mb and inflated to 7,907.2mb, not bad, but this is prior to rendering, so something to keep in mind.

[Tangled-Universe]

I meant I wasn't sure whether if you can say/state for any given scene:
"For every X million voxels memory usage increases with Y gigabyte"

[WAS]

I meant I wasn't sure whether if you can say/state for any given scene:
"For every X million voxels memory usage increases with Y gigabyte"

Not sure what you mean. Of course any other scene would have different results. If you mean the same state of a scene being different on other systems with available RAM to use, that would be a concern for the stability of the software. For example, think render farms and pricing.

My initial point is that, for any scene, playing with Millions of Voxels will have a RAM impact. ANd this is before rendering, where TG will still hold on to what it's using for the software and previews itself (if not using a node)