Visible density seen inside an overlapping volume with zero density value (Cycles) #107418

New Issue

Sebastien Larocque · 2023-04-28T01:56:41+02:00

2023-04-28 01:56:41 +02:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 528.49

Blender Version
Broken: version: 3.5.1, branch: blender-v3.5-release, commit date: 2023-04-24 18:11, hash: e1ccd9d4a1d3
Worked: Not tested on other versions.

Short description of error
Visible density seen inside an overlapping volume with zero value (Cycles)

Steps to reproduce
Open file and render.
The TestVolume_AllTransparent_Large_Test_1 object has 0 density, but it is visible in render

Note: There are 3 different test collections that may or may not be result of same issue. More info here

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 528.49 **Blender Version** Broken: version: 3.5.1, branch: blender-v3.5-release, commit date: 2023-04-24 18:11, hash: `e1ccd9d4a1d3` Worked: Not tested on other versions. **Short description of error** Visible density seen inside an overlapping volume with zero value (Cycles) **Steps to reproduce** Open file and render. The TestVolume_AllTransparent_Large_Test_1 object has 0 density, but it is visible in render Note: There are 3 different test collections that may or may not be result of same issue. More info [here](https://projects.blender.org/blender/blender/issues/107418#issuecomment-931613)

ZeroDensityVisibleOverlappingVolumes.blend

1.5 MiB

Test_2.jpg

63 KiB

Test_3_VolumeAbsorption_10_00.jpg

102 KiB

Test_3_VolumeAbsorption_1_00.jpg

93 KiB

Test_1.jpg

98 KiB

Sebastien Larocque added the

labels 2023-04-28 01:56:42 +02:00

Richard Antalik commented

2023-04-28 03:53:10 +02:00

@SebBlender I can reproduce this issue with provided file and test 1 collection. Other test collections I can see something perhaps, but it's very slight difference. Is it worth to include these other tests?

I am mainly asking, because I am also not sure if it is worth to keep all info in description as well. To me this is as simple as these instruction for developer:
Open file and render. The TestVolume_AllTransparent_Large_Test_1 object has 0 density, but it is visible in render.

I get, that test case may be tricky to setup, Just wanted to clarify whether I am missing something here.

@SebBlender I can reproduce this issue with provided file and test 1 collection. Other test collections I can see something perhaps, but it's very slight difference. Is it worth to include these other tests? I am mainly asking, because I am also not sure if it is worth to keep all info in description as well. To me this is as simple as these instruction for developer: Open file and render. The `TestVolume_AllTransparent_Large_Test_1` object has 0 density, but it is visible in render. I get, that test case may be tricky to setup, Just wanted to clarify whether I am missing something here.

Richard Antalik added

Status

Needs Information from User

and removed

Status

Needs Triage

labels 2023-04-28 03:53:22 +02:00

Sebastien Larocque commented

2023-04-28 15:25:56 +02:00

Thanks @iss for asking. Yes, it’s worth keeping all the tests, at least to me. I don’t know how they are connected exactly, but to me, they highlight different elements in Blender that influence the problem. The result seems the same at the end for the three tests and it’s all about the empty density value being visible in overlapping volumes, but each test highlights different aspects. I have some doubt that a developer might solve the problem for test 1, but not for tests 2 and 3 if they are not aware how the other factors affect the problem. Maybe.

It was a challenge to create the test project and the report too. Here’s more information about it to make it clearer.

Test 1: It highlights the basic problem where the step rate is a factor. The max steps is also a factor. You can experiment with these two factors.

Test 2: It highlights another factor, which is the step rate in the volume object that behaves as the container and also with the density values. If someone can work with the global step rate and max steps in the render properties to manage the problem, increasing the step rate in the volume with the density also creates that effect.

Test 3: If you managed to get the right numbers to avoid the problem, having a volume absorption node (with density higher than 1.00) in your volume with the density also triggers the problem. In my original project, I thought that I could overcome the problem with very low step rates and high max steps, but I found nothing to overcome the problem when adding the volume absorption node. I had to give up on this approach because of this problem.

Concerning your results, you mentioned that tests 2 and 3 were different. Were they different from the screenshots I included? With the same step rate and max steps, they should be the same.

Thanks @iss for asking. Yes, it’s worth keeping all the tests, at least to me. I don’t know how they are connected exactly, but to me, they highlight different elements in Blender that influence the problem. The result seems the same at the end for the three tests and it’s all about the empty density value being visible in overlapping volumes, but each test highlights different aspects. I have some doubt that a developer might solve the problem for test 1, but not for tests 2 and 3 if they are not aware how the other factors affect the problem. Maybe. It was a challenge to create the test project and the report too. Here’s more information about it to make it clearer. Test 1: It highlights the basic problem where the step rate is a factor. The max steps is also a factor. You can experiment with these two factors. Test 2: It highlights another factor, which is the step rate in the volume object that behaves as the container and also with the density values. If someone can work with the global step rate and max steps in the render properties to manage the problem, increasing the step rate in the volume with the density also creates that effect. Test 3: If you managed to get the right numbers to avoid the problem, having a volume absorption node (with density higher than 1.00) in your volume with the density also triggers the problem. In my original project, I thought that I could overcome the problem with very low step rates and high max steps, but I found nothing to overcome the problem when adding the volume absorption node. I had to give up on this approach because of this problem. Concerning your results, you mentioned that tests 2 and 3 were different. Were they different from the screenshots I included? With the same step rate and max steps, they should be the same.

Richard Antalik commented

2023-04-29 05:11:59 +02:00

Ok, so I will move more detailed info here to comments and mention to make sure all scenarios are covered.

Richard Antalik commented

2023-04-29 05:12:50 +02:00

Original report description:

General description
When creating a scene with cloud volumes inside an atmosphere volume for the haze, I noticed that sometimes the cloud volumes (the volumetric cube objects) had some density even within the empty areas where the density value was zero. I also confirmed that with a simple volumetric cube with zero density.

Added to that, I also ran other tests where creating the atmosphere volume with an absorption node created the same issue (some density visible) in scenarios where normally it would not be visible.

How is this a bug?
A volume with zero density inside another volume with some density should not increase the density value of the other volume.

Note about the difficulty of reproducing this bug
Testing that was difficult since this issue does not always happen. At least, the problem is not always visible. This is why I thoroughly created a test project to highlight the specific scenarios to see the problem. Based on my tests, it mainly depends on the following aspects.

The step rate in the “Render Properties”.
The max step in the “Render Properties”.
The step rate in the “Material Properties” of the volume having a density value everywhere (ex. the atmosphere).
The angle at which the camera is looking at the volume.
The density of the volume.
The light color, direction and other parameters that can affect the contrast to make the problem apparent.

As an example, having a cloud inside an atmosphere does not automatically make the problem apparent. The height of the cloud in relation with the density values of a height fog (haze) of the atmosphere can make the problem really noticeable or not noticeable.

Workaround or possible solution
I tested a scenario where the empty density is not visible. We need to have a step rate of 0.01 with max steps of 128 or higher (in general). It’s possible to have other numbers or close, but sometimes, the problem is barely visible. This only works for scenario 1 (and 2 in certain configurations). It does not work for volume absorption. In general, it’s possible to avoid the problems, but with more extreme parameters that make the rending time ridiculously high.

How to use the test project
I included three tests inside the same project. To active each test, please following these guidelines.

Update the parameters in the “Render Properties” tab.
Activate each collection with Test 1, 2 or 3 depending on which the three tests you want to test. Please, test all of them individually.
Select the camera within the test collection (ex. Camera_Test_1) and activate it.
The remaining objects in each test collection can be modified to expand your analysis of the situation.
There is a Nishita sky in the world shader with different light scenarios.

Test 1
Top-down view of the clouds and atmosphere. The ground has a motif to highlight the contrast. At the left, you can see clouds with the empty areas still having some visible density. At the right, you can see the same volume with absolute zero density in the parameters and having some visible density.

“Render Properties” tab.
Step Rate: 1.00
Max Steps: 128

Test 2
This test highlights the same problem but when the step rate of the material of the empty volume is higher than 1. To reproduce the problem, you can use the two following configurations.

Configuration 1:
“Render Properties” tab.
Step Rate: 1.00
Max Steps: 128

Modify the “Atmosphere_Large_Test_2” object:
Volume Step Rate: 5

Note: With a volume step rate of 1, the problem is not visible from that point of view. However, when seen from above, we have the same parameters as test 1 and the problem is also visible.

Configuration 2:
“Render Properties” tab.
Step Rate: 0.01
Max Steps: 128

Modify the “Atmosphere_Large_Test_2” object:
Volume Step Rate: 500

Test 3
In this test, the step rate has been lowered to 0.01 with max steps of 128 because it is a scenario where the extra density is usually not visible. The problem here is the “Volume Absorption” node with density higher than 1.00. This is necessary to crank up the density value above 1.0 to have a significant color tint in the atmosphere. This has the same visual effect on empty volumes than test 1 or 2, but with the step rate and the max steps parameters that usually work.

“Render Properties” tab.
Step Rate: 0.01
Max Steps: 128

Note
In the “Atmosphere_Large_Test2” and “Atmosphere_Large_Test3”, there are a noise texture and a color ramp node to overcome the density limitation value issue. This is not related to the specified problem in this report. Don’t be confused by this. This is just a workaround because for large volumes like an atmosphere, the lowest possible value we can enter in the “Principled Volume” node is still too high to create a light haze effect on a distance of many kilometers. As a workaround to create an atmosphere, I use a noise texture and a color ramp to render more or less sporadically. That creates empty spaces between the volume noise and the sum of all the values over the distance create a lighter haze effect. The “Atmosphere_Medium_Test_1” does use this technique and it still shows the problem. Without this, it’s harder to see the problem from the ground point of view because the haze is just too thick.

Conclusion
The rendering quality can be variable depending on the settings, but in no case I expect a zero density value to render a color in volumetric objects.

Here are a test project and the images giving a preview of each test.

Original report description: **General description** When creating a scene with cloud volumes inside an atmosphere volume for the haze, I noticed that sometimes the cloud volumes (the volumetric cube objects) had some density even within the empty areas where the density value was zero. I also confirmed that with a simple volumetric cube with zero density. Added to that, I also ran other tests where creating the atmosphere volume with an absorption node created the same issue (some density visible) in scenarios where normally it would not be visible. **How is this a bug?** A volume with zero density inside another volume with some density should not increase the density value of the other volume. **Note about the difficulty of reproducing this bug** Testing that was difficult since this issue does not always happen. At least, the problem is not always visible. This is why I thoroughly created a test project to highlight the specific scenarios to see the problem. Based on my tests, it mainly depends on the following aspects. * The step rate in the “Render Properties”. * The max step in the “Render Properties”. * The step rate in the “Material Properties” of the volume having a density value everywhere (ex. the atmosphere). * The angle at which the camera is looking at the volume. * The density of the volume. * The light color, direction and other parameters that can affect the contrast to make the problem apparent. As an example, having a cloud inside an atmosphere does not automatically make the problem apparent. The height of the cloud in relation with the density values of a height fog (haze) of the atmosphere can make the problem really noticeable or not noticeable. **Workaround or possible solution** I tested a scenario where the empty density is not visible. We need to have a step rate of 0.01 with max steps of 128 or higher (in general). It’s possible to have other numbers or close, but sometimes, the problem is barely visible. This only works for scenario 1 (and 2 in certain configurations). It does not work for volume absorption. In general, it’s possible to avoid the problems, but with more extreme parameters that make the rending time ridiculously high. **How to use the test project** I included three tests inside the same project. To active each test, please following these guidelines. * Update the parameters in the “Render Properties” tab. * Activate each collection with Test 1, 2 or 3 depending on which the three tests you want to test. Please, test all of them individually. * Select the camera within the test collection (ex. Camera_Test_1) and activate it. * The remaining objects in each test collection can be modified to expand your analysis of the situation. * There is a Nishita sky in the world shader with different light scenarios. **Test 1** Top-down view of the clouds and atmosphere. The ground has a motif to highlight the contrast. At the left, you can see clouds with the empty areas still having some visible density. At the right, you can see the same volume with absolute zero density in the parameters and having some visible density. “Render Properties” tab. Step Rate: 1.00 Max Steps: 128 **Test 2** This test highlights the same problem but when the step rate of the material of the empty volume is higher than 1. To reproduce the problem, you can use the two following configurations. Configuration 1: “Render Properties” tab. Step Rate: 1.00 Max Steps: 128 Modify the “Atmosphere_Large_Test_2” object: Volume Step Rate: 5 Note: With a volume step rate of 1, the problem is not visible from that point of view. However, when seen from above, we have the same parameters as test 1 and the problem is also visible. Configuration 2: “Render Properties” tab. Step Rate: 0.01 Max Steps: 128 Modify the “Atmosphere_Large_Test_2” object: Volume Step Rate: 500 **Test 3** In this test, the step rate has been lowered to 0.01 with max steps of 128 because it is a scenario where the extra density is usually not visible. The problem here is the “Volume Absorption” node with density higher than 1.00. This is necessary to crank up the density value above 1.0 to have a significant color tint in the atmosphere. This has the same visual effect on empty volumes than test 1 or 2, but with the step rate and the max steps parameters that usually work. “Render Properties” tab. Step Rate: 0.01 Max Steps: 128 **Note** In the “Atmosphere_Large_Test2” and “Atmosphere_Large_Test3”, there are a noise texture and a color ramp node to overcome the density limitation value issue. This is not related to the specified problem in this report. Don’t be confused by this. This is just a workaround because for large volumes like an atmosphere, the lowest possible value we can enter in the “Principled Volume” node is still too high to create a light haze effect on a distance of many kilometers. As a workaround to create an atmosphere, I use a noise texture and a color ramp to render more or less sporadically. That creates empty spaces between the volume noise and the sum of all the values over the distance create a lighter haze effect. The “Atmosphere_Medium_Test_1” does use this technique and it still shows the problem. Without this, it’s harder to see the problem from the ground point of view because the haze is just too thick. **Conclusion** The rendering quality can be variable depending on the settings, but in no case I expect a zero density value to render a color in volumetric objects. Here are a test project and the images giving a preview of each test.

Richard Antalik added

and removed

Needs Information from User

labels 2023-04-29 05:16:52 +02:00

Germano Cavalcante referenced this issue

2023-08-23 21:55:22 +02:00

Volume overlap clipping #111434

Richard Traynor referenced this issue

2023-08-23 23:12:40 +02:00

Volume overlap clipping #111434

Sebastien Larocque commented

2023-09-18 21:14:56 +02:00

I have some new elements to add to this bug.

I thought it was mainly buggy with the “Volume Scatter” node and the “Volume Absorption” node, but the “Principled Volume” node also has this problem. I tested a scenario with this last node where it even created artifacts with the parameters of “step rate: 0.01” and “Max Steps: 128” that could hide the problems in many situations.

In this new test project that you will find below, I had the problem with the “step rate: 1”. By lowering the step rate, the artifacts tend to disappear completely (0.1 and lower for example). I didn’t include the original project as it is big and it uses more complex shaders.

I can tell the problem is apparent in very precise conditions: the angle of the light, the fog density and the camera angle.

Furthermore, I also tried to import VDB clouds. The problem is less apparent because the VDB objects are divided into voxels and not just one cubic shape. We can still see the extra density on the edge of the VDB clouds. Therefore, they also have the same issue.

Below, you will find three screenshots. The first and the second show the test project where the empty cubic shape is set with the “Transparent BSDF” node and the “Principled Volume” node. They show a difference in the tint of the artifacts. The third screenshot shows the main project that I’m working on with the “Principled Volume” node representing the haze. This is how this is problematic.

Question:
I have been working on this project for months. It’s quite a bummer to be stuck with this bug. At the moment, I simply cannot go into production because of this. I reported this bug several months ago and I can see that it’s not fixed yet. I understand that you have priorities for solving bugs and you cannot fix everything at once. On the other hand, as a professional who uses Blender to make a living, I’m really wondering what to do with this. I cannot spend months waiting for a probable fix. If this is not going to be fixed any time soon, I’ll have to move with some alternatives. Is it possible to have a calendar and an estimate when and how this is going to be handled?

Ideally, that would be nice to have this fixed in any alpha version 4.0 to have a solution the soonest possible.

I have some new elements to add to this bug. I thought it was mainly buggy with the “Volume Scatter” node and the “Volume Absorption” node, but the “Principled Volume” node also has this problem. I tested a scenario with this last node where it even created artifacts with the parameters of “step rate: 0.01” and “Max Steps: 128” that could hide the problems in many situations. In this new test project that you will find below, I had the problem with the “step rate: 1”. By lowering the step rate, the artifacts tend to disappear completely (0.1 and lower for example). I didn’t include the original project as it is big and it uses more complex shaders. I can tell the problem is apparent in very precise conditions: the angle of the light, the fog density and the camera angle. Furthermore, I also tried to import VDB clouds. The problem is less apparent because the VDB objects are divided into voxels and not just one cubic shape. We can still see the extra density on the edge of the VDB clouds. Therefore, they also have the same issue. Below, you will find three screenshots. The first and the second show the test project where the empty cubic shape is set with the “Transparent BSDF” node and the “Principled Volume” node. They show a difference in the tint of the artifacts. The third screenshot shows the main project that I’m working on with the “Principled Volume” node representing the haze. This is how this is problematic. Question: I have been working on this project for months. It’s quite a bummer to be stuck with this bug. At the moment, I simply cannot go into production because of this. I reported this bug several months ago and I can see that it’s not fixed yet. I understand that you have priorities for solving bugs and you cannot fix everything at once. On the other hand, as a professional who uses Blender to make a living, I’m really wondering what to do with this. I cannot spend months waiting for a probable fix. If this is not going to be fixed any time soon, I’ll have to move with some alternatives. Is it possible to have a calendar and an estimate when and how this is going to be handled? Ideally, that would be nice to have this fixed in any alpha version 4.0 to have a solution the soonest possible.

Test2_TransparentBSDF_Node.jpg

656 KiB

Test2_PrincipledVolume_Node.jpg

616 KiB

ZeroDensityVisibleOverlappingVolumes_Test2.blend

1.4 MiB

OriginalProject.jpg

17 KiB

Sebastien Larocque commented

2023-09-22 17:43:17 +02:00

I did a new test with the VDB clouds. After some new search on forums, I found people mentioning they had solved the same problem with VDB clouds by changing the “Render | Space” option from “Object” to “World”. I tried it, but without success in my case.

Below, I joined a new picture of my test with VDB clouds. Notice the selected cloud at the bottom near the ground. The closer to the ground, the higher the density. The problem is more visible at as we get closer to the ground. In that case, unlike the clouds made from a cube with a noise texture where the empty part of the cube is filled with some density, the VDB has problems only in very specific edge voxels.

I did a new test with the VDB clouds. After some new search on forums, I found people mentioning they had solved the same problem with VDB clouds by changing the “Render | Space” option from “Object” to “World”. I tried it, but without success in my case. Below, I joined a new picture of my test with VDB clouds. Notice the selected cloud at the bottom near the ground. The closer to the ground, the higher the density. The problem is more visible at as we get closer to the ground. In that case, unlike the clouds made from a cube with a noise texture where the empty part of the cube is filled with some density, the VDB has problems only in very specific edge voxels.

Test_VDB.jpg

21 KiB

Sebastien Larocque commented

2023-10-01 21:13:31 +02:00

I ran a few other extensive tests to discover something that might explain the real nature of the issue.

Context

I started creating an atmosphere shader by experimenting with different methods.

My original idea was to create a single volume for the height fog (haze) and to add cloud objects. This made the rendering exponentially slow because of the overlapping volumes. I decided to abandon this method because of speed performance.

After, I decided to use a single very large volume by combining the haze and the clouds within the same volume, but the cloud resolution was not good because of the very large size.

Then, I decided to divide the very large volume into a matrix (grid shape) of voxels with a minimal space between the voxels. This gave a better resolution for each voxel because of the smaller size. However, I ended up with artifacts between the voxels, which is what I’m representing here in this new test.

Why am I bringing this test?

Recently, after experimenting and posting my bug report concerning the overlapping volumes, I remembered this first experiment described above.

In my first bug report, I described the problem happening in the overlapping area between the volumes, but very similar artifacts appear for non-overlapping volumes. I decided to create a special test project attached here with the matrix of non-overlapping atmospheric voxels to demonstrate the issue and to allow you to run different tests on it. Maybe it will provide another way to understand the source of the issue.

The artifacts seem rather on the surface (edges) of the volume than inside the volume.

Observation 1

What I described in my original bug report as extra density is in reality a higher color value at the edge of a volumetric shader. Unless there is really extra density within the overlapping volumes, I would say that the higher value is created at the edge of a volumetric shader in particular conditions.

Observation 2

Changing the “Transparent” option in the “Render | Light Paths | Max Bounces” influence the color value at the edge of the voxels. From 0 to 5, there is a variety of artifacts. From 6 to 1024, the results are consistent with the artifacts as described above.

Observation 3

For a totally transparent volume and not touching the ground, if you move the camera in the viewport or change the point of view, you can still see the shape of the volume during the process. It looks like during the first frame (or sample), the noise pattern stays the same around but changes where the volume is. That allows you to see the volume position even when there is 0 density. For the next samples, it is not visible (except for the artifacts in special cases).

You can reproduce this by setting the Z position to 1 of the “Atmosphere_GN_Test_0_Density” in the “Test - 0 density” collection.

Observation 4

In cases where there is a surface from a volumetric shader object that is coplanar with another surface from either a volumetric shader object or surface shader object, Cycles seems to render dark opaque pixels. It is as if a conflict arose where it could not get any source of light to render the pixels. The problem is present when the two surfaces are at the same position or very close.

Probably black pixels are defined by all samples being in conflict while gray pixel patterns are defined by only a portion of the pixels being in conflict and result in an average.

Test 1

In this test, there are 3 different base scenarios with voxel matrices of different distances between the voxels. I also repeated the same scenarios with different “Step Rate” from the tab “Render | Volumes”.

The results are reproducible by enabling each object named “Atmosphere_GN_Test1[...]” individually and changing the “Step Rate” manually.

The distance between the voxels for each sub-test is:

Atmosphere_GN_Test1A: 1 meter
Atmosphere_GN_Test1B: 0.1 meter.
Atmosphere_GN_Test1B: 0.01 meter.

The “Max Steps” in “Render | Volumes” also has an influence that can change the appearance of the artifacts sometimes. I used 128 for all my tests.

Test 2

In Test 2, I decided to set the space between the voxels to 1500 meters to better see where the extra density was defined. It seems to confirm that the surfaces of the voxels are where the extra density seems to appear, but also as a darker color sometimes in the form of artifacts. I used a “Step Rate” of 0.01 for this test.

Test 3

In Test 3, I set the space between the voxels to 0. (I noted the same artifacts for 0 or a very small distance). Some conflicting edges appear very dark as if their opacity was high. As a result, I noted they were opaque in a certain way because they projected shadows in the corners. I verified that by changing the light direction and elevation in the World Shader. In the attached screenshot, I highlighted the closest shadow artifacts with red arrows.

Conflicting surfaces can be treated as more opaque and not in a predictable way because not all surfaces are darker and projecting shadows.

Test - 0 density

In this test, there are visible artifacts at the junction of the ground and the bottom of the volumes (0 meter in height). The artifacts remain visible where the bottom of the volumes is near the ground even if not exactly at the same position. In my test, that means within about 20 centimeters above or under the ground. It tends to fade away as the distance increases. The artifacts are getting more visible and very dark as the view is changed to a top-down view. You can try the camera “Camera_4_TopDownOrthographic” for a total black.

You can look at the screenshot “Test - 0 density_0 meter from the ground - Camera_3.jpg” for an example. It is rendered from the “Camera_3_FromAbove45Degrees”.

There is another screenshot rendered from the “Camera_Test - 0 density”. Instead of having darker pixels all the way, it shows pixels with the haze color in the distance as if there was density, but always at the conflicting zone where the ground is. Nearer to the camera, the volume is darker.

By changing the viewport view (angle and distance), you will get different results. Also, modifying the Z position of the “Atmosphere_GN_Test_0_Density” changes the results.

Other related note:
For a long time, people noticed that two volumes with their common edges at the exact same position produced a black opaque density. This problem seem well known by many developers.

Other point of importance

It has been noted that a volume inside of another volume renders a lot slower and several volumes increase the rendering exponentially. Although not a bug in appearance, could this issue be related and improved?

Conclusion

I found that Test 1 shows a lot about the problem when I modify the distance between the voxels. The problem also arises (or is apparent) in relation with a variety of parameters that makes the problem quite complex.

I noted:

Density of the volumes.
Max Steps.
Step Rate.
Number of “Transparent” “Max Bounces” in the “Light Paths”.
Angle of the camera.
Light direction.
If the camera is perspective or orthographic.
When two volumes overlap or not.

The problem has probably been present for years for a single volume, but has never been really visible because there was no contrast with other volumes aside. When compared with other volumes aside creating a continuity, like the voxel test here, it becomes apparent.

Solution?
I have one hypothesis to explain the artifacts, but it probably does not explain everything. I have this impression that there are calculations happening on the edges that are not consistent with all the other samples being calculated inside the volume and not adjacent to the edges. For example, a sample adjacent to the edge would not have the same size and would miss many rays or other information in general for being too small. That would lead to a different density projecting shadows sometimes. Also, depending on the position of the samples in the volume, with smaller values, we are more likely to see some offset that would lead to variable shadow patterns.

Otherwise, it really makes me wondering why a volumetric shader that sticks to a surface shader (with no space between) would create dark patterns on the surface since the samples calculated are supposed to be within the volume.

With this test of complex scenarios, it looks like a different perspective about the nature of the artifacts, since no volumes are overlapping to be able to reproduce it. Even when they are overlapping, I have this feeling that it is happening on the edge of the volume and not necessarily for all the overlapping samples inside.

I ran a few other extensive tests to discover something that might explain the real nature of the issue. **Context** I started creating an atmosphere shader by experimenting with different methods. My original idea was to create a single volume for the height fog (haze) and to add cloud objects. This made the rendering exponentially slow because of the overlapping volumes. I decided to abandon this method because of speed performance. After, I decided to use a single very large volume by combining the haze and the clouds within the same volume, but the cloud resolution was not good because of the very large size. Then, I decided to divide the very large volume into a matrix (grid shape) of voxels with a minimal space between the voxels. This gave a better resolution for each voxel because of the smaller size. However, I ended up with artifacts between the voxels, which is what I’m representing here in this new test. **Why am I bringing this test?** Recently, after experimenting and posting my bug report concerning the overlapping volumes, I remembered this first experiment described above. In my first bug report, I described the problem happening in the overlapping area between the volumes, but very similar artifacts appear for non-overlapping volumes. I decided to create a special test project attached here with the matrix of non-overlapping atmospheric voxels to demonstrate the issue and to allow you to run different tests on it. Maybe it will provide another way to understand the source of the issue. The artifacts seem rather on the surface (edges) of the volume than inside the volume. **Observation 1** What I described in my original bug report as extra density is in reality a higher color value at the edge of a volumetric shader. Unless there is really extra density within the overlapping volumes, I would say that the higher value is created at the edge of a volumetric shader in particular conditions. **Observation 2** Changing the “Transparent” option in the “Render | Light Paths | Max Bounces” influence the color value at the edge of the voxels. From 0 to 5, there is a variety of artifacts. From 6 to 1024, the results are consistent with the artifacts as described above. **Observation 3** For a totally transparent volume and not touching the ground, if you move the camera in the viewport or change the point of view, you can still see the shape of the volume during the process. It looks like during the first frame (or sample), the noise pattern stays the same around but changes where the volume is. That allows you to see the volume position even when there is 0 density. For the next samples, it is not visible (except for the artifacts in special cases). You can reproduce this by setting the Z position to 1 of the “Atmosphere_GN_Test_0_Density” in the “Test - 0 density” collection. **Observation 4** In cases where there is a surface from a volumetric shader object that is coplanar with another surface from either a volumetric shader object or surface shader object, Cycles seems to render dark opaque pixels. It is as if a conflict arose where it could not get any source of light to render the pixels. The problem is present when the two surfaces are at the same position or very close. Probably black pixels are defined by all samples being in conflict while gray pixel patterns are defined by only a portion of the pixels being in conflict and result in an average. **Test 1** In this test, there are 3 different base scenarios with voxel matrices of different distances between the voxels. I also repeated the same scenarios with different “Step Rate” from the tab “Render | Volumes”. The results are reproducible by enabling each object named “Atmosphere_GN_Test1[...]” individually and changing the “Step Rate” manually. The distance between the voxels for each sub-test is: Atmosphere_GN_Test1A: 1 meter Atmosphere_GN_Test1B: 0.1 meter. Atmosphere_GN_Test1B: 0.01 meter. The “Max Steps” in “Render | Volumes” also has an influence that can change the appearance of the artifacts sometimes. I used 128 for all my tests. **Test 2** In Test 2, I decided to set the space between the voxels to 1500 meters to better see where the extra density was defined. It seems to confirm that the surfaces of the voxels are where the extra density seems to appear, but also as a darker color sometimes in the form of artifacts. I used a “Step Rate” of 0.01 for this test. **Test 3** In Test 3, I set the space between the voxels to 0. (I noted the same artifacts for 0 or a very small distance). Some conflicting edges appear very dark as if their opacity was high. As a result, I noted they were opaque in a certain way because they projected shadows in the corners. I verified that by changing the light direction and elevation in the World Shader. In the attached screenshot, I highlighted the closest shadow artifacts with red arrows. Conflicting surfaces can be treated as more opaque and not in a predictable way because not all surfaces are darker and projecting shadows. **Test - 0 density** In this test, there are visible artifacts at the junction of the ground and the bottom of the volumes (0 meter in height). The artifacts remain visible where the bottom of the volumes is near the ground even if not exactly at the same position. In my test, that means within about 20 centimeters above or under the ground. It tends to fade away as the distance increases. The artifacts are getting more visible and very dark as the view is changed to a top-down view. You can try the camera “Camera_4_TopDownOrthographic” for a total black. You can look at the screenshot “Test - 0 density_0 meter from the ground - Camera_3.jpg” for an example. It is rendered from the “Camera_3_FromAbove45Degrees”. There is another screenshot rendered from the “Camera_Test - 0 density”. Instead of having darker pixels all the way, it shows pixels with the haze color in the distance as if there was density, but always at the conflicting zone where the ground is. Nearer to the camera, the volume is darker. By changing the viewport view (angle and distance), you will get different results. Also, modifying the Z position of the “Atmosphere_GN_Test_0_Density” changes the results. Other related note: For a long time, people noticed that two volumes with their common edges at the exact same position produced a black opaque density. This problem seem well known by many developers. **Other point of importance** It has been noted that a volume inside of another volume renders a lot slower and several volumes increase the rendering exponentially. Although not a bug in appearance, could this issue be related and improved? **Conclusion** I found that Test 1 shows a lot about the problem when I modify the distance between the voxels. The problem also arises (or is apparent) in relation with a variety of parameters that makes the problem quite complex. I noted: * Density of the volumes. * Max Steps. * Step Rate. * Number of “Transparent” “Max Bounces” in the “Light Paths”. * Angle of the camera. * Light direction. * If the camera is perspective or orthographic. * When two volumes overlap or not. The problem has probably been present for years for a single volume, but has never been really visible because there was no contrast with other volumes aside. When compared with other volumes aside creating a continuity, like the voxel test here, it becomes apparent. Solution? I have one hypothesis to explain the artifacts, but it probably does not explain everything. I have this impression that there are calculations happening on the edges that are not consistent with all the other samples being calculated inside the volume and not adjacent to the edges. For example, a sample adjacent to the edge would not have the same size and would miss many rays or other information in general for being too small. That would lead to a different density projecting shadows sometimes. Also, depending on the position of the samples in the volume, with smaller values, we are more likely to see some offset that would lead to variable shadow patterns. Otherwise, it really makes me wondering why a volumetric shader that sticks to a surface shader (with no space between) would create dark patterns on the surface since the samples calculated are supposed to be within the volume. With this test of complex scenarios, it looks like a different perspective about the nature of the artifacts, since no volumes are overlapping to be able to reproduce it. Even when they are overlapping, I have this feeling that it is happening on the edge of the volume and not necessarily for all the overlapping samples inside.

Test 2 - Step Rate 0.01.jpg

859 KiB

Test 1 - Atmosphere_GN_Test1B - Step Rate 0.1.jpg

795 KiB

Test 1 - Atmosphere_GN_Test1A - Step Rate 0.1.jpg

154 KiB

Test 3 - Step Rate 0.01.jpg

158 KiB

Test - 0 density_0 meter from the ground - Camera_3.jpg

779 KiB

Test 1 - Atmosphere_GN_Test1C - Step Rate 0.1.jpg

919 KiB

VolumeDensityVoxels_Test.blend

1.7 MiB

Test 1 - Atmosphere_GN_Test1C - Step Rate 1.00.jpg

929 KiB

Test - 0 density_0 meter from the ground - Camera_0 density.jpg

111 KiB

Test 1 - Atmosphere_GN_Test1A - Step Rate 1.00.jpg

164 KiB

Test 1 - Atmosphere_GN_Test1B - Step Rate 1.00.jpg

814 KiB

Test 1 - Atmosphere_GN_Test1A - Step Rate 0.01.jpg

159 KiB

Test 1 - Atmosphere_GN_Test1C - Step Rate 0.01.jpg

913 KiB

Test 1 - Atmosphere_GN_Test1B - Step Rate 0.1.jpg

Test 1 - Atmosphere_GN_Test1A - Step Rate 0.1.jpg

Test - 0 density_0 meter from the ground - Camera_3.jpg

Test 1 - Atmosphere_GN_Test1C - Step Rate 0.1.jpg

Test 1 - Atmosphere_GN_Test1C - Step Rate 1.00.jpg

Test - 0 density_0 meter from the ground - Camera_0 density.jpg

Test 1 - Atmosphere_GN_Test1A - Step Rate 1.00.jpg

Test 1 - Atmosphere_GN_Test1B - Step Rate 1.00.jpg

Test 1 - Atmosphere_GN_Test1A - Step Rate 0.01.jpg

Test 1 - Atmosphere_GN_Test1C - Step Rate 0.01.jpg

Sebastien Larocque referenced this issue

2023-10-02 02:44:24 +02:00

Volume overlap clipping #111434

Sebastien Larocque referenced this issue

2023-10-02 02:46:26 +02:00

Render issues when two VBD overlap if rendered with motion blur #105549

Sebastien Larocque referenced this issue

2023-10-02 02:47:06 +02:00

vdb still showing blocky artefacts #112778

Sebastien Larocque referenced this issue

2023-10-02 02:48:51 +02:00

Cycles: overlapping VDBs cause rendering artifacts #97094

Sebastien Larocque referenced this issue

2023-10-02 02:56:55 +02:00

Cycles Volume Anisotropy artifacts with intersecting volumes #96153

Sebastien Larocque referenced this issue

2023-10-02 02:57:25 +02:00

Overlapping Smoke Volume Cycles render bug #83604

Sebastien Larocque referenced this issue

2023-10-02 02:58:14 +02:00

Overlapping objects of different sizes with volumetric materials render incorrectly #79762

Lukas Stockner commented

2023-10-05 02:12:54 +02:00

I've looked into a few of the linked issues, and from what I saw so far, several have the same underlying issue: Overlapping boundary geometry.

To give the short version: When Cycles traces a path through overlapping volumes, what should happen is:

Ray hits surface of object 1, enters its volume
Ray is attenuated/scattered by volume 1
Ray hits surface of object 2, enters its volume
Ray is attenuated/scattered by both volumes
Ray hits surface of object 1 again, leaves its volume
Ray is attenuated/scattered by volume 2
Ray hits surface of object 2 again, leaves its volume

However, if the surfaces that define the volume happen to overlap, what can happen is that one of the two surfaces in the same spot is missed. Whether that happens comes down to numerical issues, which explains why it only appears in some places (therefore the blocky look).

Specifically:

The test 1 scenario here is quite extreme in its scale - floating point numbers can handle large numbers or small differences well, but not both at the same time. Expecting Cycles to differentiate between two surfaces 0.01m apart at a distance of 100000s of meters from the camera is just not practical. If you increase the voxel distance by just a tiny bit, it works perfectly fine.
The three smoke domains in #83604 are all at exactly the same X location. Shifting them by a tiny bit solves the issue.
In #97094, both domains are in the exact same location, so of course they overlap. And since the camera is pointing straight ahead, simply moving one around won't help, since it will remain at X=0. Shifting it towards the camera by just 0.0001 resolves the issue.

I've looked into a few of the linked issues, and from what I saw so far, several have the same underlying issue: Overlapping boundary geometry. To give the short version: When Cycles traces a path through overlapping volumes, what should happen is: 1. Ray hits surface of object 1, enters its volume 2. Ray is attenuated/scattered by volume 1 2. Ray hits surface of object 2, enters its volume 2. Ray is attenuated/scattered by both volumes 3. Ray hits surface of object 1 again, leaves its volume 2. Ray is attenuated/scattered by volume 2 3. Ray hits surface of object 2 again, leaves its volume However, if the surfaces that define the volume happen to overlap, what can happen is that one of the two surfaces in the same spot is missed. Whether that happens comes down to numerical issues, which explains why it only appears in some places (therefore the blocky look). Specifically: - The test 1 scenario here is quite extreme in its scale - floating point numbers can handle large numbers or small differences well, but not both at the same time. Expecting Cycles to differentiate between two surfaces 0.01m apart at a distance of 100000s of meters from the camera is just not practical. If you increase the voxel distance by just a tiny bit, it works perfectly fine. - The three smoke domains in #83604 are all at exactly the same X location. Shifting them by a tiny bit solves the issue. - In #97094, both domains are in the exact same location, so of course they overlap. And since the camera is pointing straight ahead, simply moving one around won't help, since it will remain at X=0. Shifting it towards the camera by just 0.0001 resolves the issue.

Sebastien Larocque commented

2023-10-10 17:38:51 +02:00

Thank you Lukas for the answer.

I understand that the nature of the problem is known and will probably not be fixed, or at least any time soon. So far, that provides explanations, but not a solution to aspects.

The new results
I have run several tests with my custom atmospheric volumetric shader separated in voxels (Geometry Node generated) and the overlapping clouds.

First, as you mentioned, increasing the space between the voxels tends to make the problem disappear. However, not completely. Depending on the angles, the problem might continue to be visible. I found that 10 meters between the voxels is a safe value. There are scenarios where it is still problematic. For example, if the camera is positioned between the voxels, we see no fog or if the sun light (or other lights) is aligned with the angle of the voxels, the light passes directly between. In general, for a ground position, the effect is good.

It is important to note that the voxel volume approach is a very costly workaround that I developed to overcome Blender’s limitations. From that point of view, the vast majority of people who want to create scenes with real atmosphere are more likely to be limited and have no solution than doing the same costly approach. I understand that it is a more extreme scenario, but there is certainly a need to be able to represent these kinds of scenes with accuracy.

Why we still need to address that issue

People will continue to report these problem as a bug because of the limitations. This problem and the undesirable visual effects are not even in the documentation. How are people supposed to know the right values to use before reaching Blender’s limitations? For me, it worked well until I changed (sometimes slightly) one parameter and then I started to see these artifacts.

There are other situations that are hard to fix, for example, the liquids are more likely to have the same surface position because of the contact.

For single image rendering, there is more room to fix the problem, but for animations where objects move quite a bit, it’s far easier to have artifacts, even if it’s just for a few frames.

Vextex displacements can also cause overlaps in animations.

What to do next

It would be very interesting to have a better documentation with examples. Although that I understand the influence of the step rate, it’s complicated to match all the parameters.
I looked at the all the parameters that work in together. Mainly, these are more obscure how they work together:

step rate in Render | Volumes.
volume step rate in the object material.

Would it be possible for all the cases open here with artifacts in volumes to validate a solution?

Although there might be some compromise and workarounds around the limitations, it seems buggy for other cases, like “Cycles Volume Anisotropy artifacts with intersecting volumes #96153” or “Volume overlap clipping #111434”.

Although the result is better with the Geometry Node strategy and the right space between the voxels, there are still problems. So far, the problem does not seem apparent for an atmosphere seen from the ground.

Because there is no threshold or step rate value table or information of this nature to evaluate if the problem is going to appear or not, many people come here reporting this as a bug. Depending on how you look at the problem, it is a bug or a limitation. Avoiding the problem depends a lot on costly experimentation to find the good configuration between all the elements and also a few hacks to render a realistic atmosphere, for example.

Looking at the documentation and trying to figure out how to achieve certain realism makes all these scenarios convoluted and are more likely to have people continuing reporting these issues as a bug. This is why these issues need to be addressed in a certain way.

Finally, I presume that case would be something as a new feature request for volume rendering improvement.

Thank you Lukas for the answer. I understand that the nature of the problem is known and will probably not be fixed, or at least any time soon. So far, that provides explanations, but not a solution to aspects. **The new results** I have run several tests with my custom atmospheric volumetric shader separated in voxels (Geometry Node generated) and the overlapping clouds. First, as you mentioned, increasing the space between the voxels tends to make the problem disappear. However, not completely. Depending on the angles, the problem might continue to be visible. I found that 10 meters between the voxels is a safe value. There are scenarios where it is still problematic. For example, if the camera is positioned between the voxels, we see no fog or if the sun light (or other lights) is aligned with the angle of the voxels, the light passes directly between. In general, for a ground position, the effect is good. It is important to note that the voxel volume approach is a very costly workaround that I developed to overcome Blender’s limitations. From that point of view, the vast majority of people who want to create scenes with real atmosphere are more likely to be limited and have no solution than doing the same costly approach. I understand that it is a more extreme scenario, but there is certainly a need to be able to represent these kinds of scenes with accuracy. **Why we still need to address that issue** People will continue to report these problem as a bug because of the limitations. This problem and the undesirable visual effects are not even in the documentation. How are people supposed to know the right values to use before reaching Blender’s limitations? For me, it worked well until I changed (sometimes slightly) one parameter and then I started to see these artifacts. There are other situations that are hard to fix, for example, the liquids are more likely to have the same surface position because of the contact. For single image rendering, there is more room to fix the problem, but for animations where objects move quite a bit, it’s far easier to have artifacts, even if it’s just for a few frames. Vextex displacements can also cause overlaps in animations. **What to do next** It would be very interesting to have a better documentation with examples. Although that I understand the influence of the step rate, it’s complicated to match all the parameters. I looked at the all the parameters that work in together. Mainly, these are more obscure how they work together: * step rate in Render | Volumes. * volume step rate in the object material. Would it be possible for all the cases open here with artifacts in volumes to validate a solution? Although there might be some compromise and workarounds around the limitations, it seems buggy for other cases, like “Cycles Volume Anisotropy artifacts with intersecting volumes https://projects.blender.org/blender/blender/issues/96153” or “Volume overlap clipping https://projects.blender.org/blender/blender/issues/111434”. Although the result is better with the Geometry Node strategy and the right space between the voxels, there are still problems. So far, the problem does not seem apparent for an atmosphere seen from the ground. Because there is no threshold or step rate value table or information of this nature to evaluate if the problem is going to appear or not, many people come here reporting this as a bug. Depending on how you look at the problem, it is a bug or a limitation. Avoiding the problem depends a lot on costly experimentation to find the good configuration between all the elements and also a few hacks to render a realistic atmosphere, for example. Looking at the documentation and trying to figure out how to achieve certain realism makes all these scenarios convoluted and are more likely to have people continuing reporting these issues as a bug. This is why these issues need to be addressed in a certain way. Finally, I presume that case would be something as a new feature request for volume rendering improvement.

Sebastien Larocque commented

2023-12-04 05:24:19 +01:00

@LukasStockner , I tried several other things to fix the artifact issues, but it’s pretty much a nightmare. Despite, your explanations, it’s far too complicated to match the right conditions to avoid the issues. Overlapping volumes can work, but the number of scenarios with the number of parameters affecting the problem makes it not very suitable, particularly for creating an overlapping atmosphere with clouds.

You mentioned, “If you increase the voxel distance by just a tiny bit, it works perfectly fine”, but this is under very specific conditions. In my test project, it seems to work when the Volumes step rate is 0.1 under the Render tab. With a step rate of 1.0, the artifacts are visible again (even with a distance of 10 or 100 meters between the atmosphere voxels).

Furthermore, if I have been able to hide the artifacts (between the atmosphere voxels) in my test project using very specific parameters, I’m really not able to achieve the same thing in my original project, whatever I try. It’s going nowhere.

Disappointing results:
You mentioned: “floating point numbers can handle large numbers or small differences well, but not both at the same time.” I understand that, it makes sense. I decided to test with a better ratio between the clouds and the atmosphere voxels.

In my original project, I set the:

Left cloud is 26,871 x 26,871 x 6,717 meters.
Right cloud is 8,000 x 8,000 x 2,000 meters.
Each atmosphere voxel is 50,000 x 50,000 x 13,000 meters.

Despite the low ratio between the clouds and each atmosphere voxel, the extra density is apparent in the clouds. I’m wondering if the ratio for the floating point numbers is between the clouds and the atmosphere. You can see from the screenshot that there’s nothing extreme.

The distance between the atmosphere voxels is 10 meters. Even with 1,000 meters, the problem is still there. There must be another factor causing this.

Below, I posted two pictures of the new results from my original projects. You can see the problem (viewport version) from the ground and also from above.

Debugging tip:
Under the “Object” tab of the atmosphere object in “Ray Visibility”, if you check/uncheck the options “Camera”, “Volume Scatter”, “Shadow” (mainly those), you can see different aspects of the artifacts. The results depend on the scenario.

Possible solution:
This is where there’s hope to find a fix to this issue.

You mentioned: “However, if the surfaces that define the volume happen to overlap, what can happen is that one of the two surfaces in the same spot is missed. Whether that happens comes down to numerical issues, which explains why it only appears in some places (therefore the blocky look).”

If what you said about the missed spot is true, do you think Blender would be able to detect if it misses the spot?

If you could write an extra function to verify this, Blender could output a transparent or empty value instead. It could also output the value of one of the overlapping volumes, like the atmosphere, for example. During my test, I either had something darker (especially overlapping surfaces) or extra light. I have this feeling that detecting when it misses the spot for overlapping volumes and outputting a more strategic value would fix this issue.

Does it look like a possible solution?

Conclusion:
Overlapping volumes don’t appear suitable in this context for outdoor real-scale scenes. The only suitable options are a volumetric atmosphere for the haze with billboard clouds or a single volumetric atmosphere that combine the haze and noise clouds in the same shader. If it is made of voxels for more precision, only the ground scene are suitable to avoid seeing the artifacts between the voxels.

@LukasStockner , I tried several other things to fix the artifact issues, but it’s pretty much a nightmare. Despite, your explanations, it’s far too complicated to match the right conditions to avoid the issues. Overlapping volumes can work, but the number of scenarios with the number of parameters affecting the problem makes it not very suitable, particularly for creating an overlapping atmosphere with clouds. You mentioned, “If you increase the voxel distance by just a tiny bit, it works perfectly fine”, but this is under very specific conditions. In my test project, it seems to work when the Volumes step rate is 0.1 under the Render tab. With a step rate of 1.0, the artifacts are visible again (even with a distance of 10 or 100 meters between the atmosphere voxels). Furthermore, if I have been able to hide the artifacts (between the atmosphere voxels) in my test project using very specific parameters, I’m really not able to achieve the same thing in my original project, whatever I try. It’s going nowhere. **Disappointing results:** You mentioned: “_floating point numbers can handle large numbers or small differences well, but not both at the same time._” I understand that, it makes sense. I decided to test with a better ratio between the clouds and the atmosphere voxels. In my original project, I set the: - Left cloud is 26,871 x 26,871 x 6,717 meters. - Right cloud is 8,000 x 8,000 x 2,000 meters. - Each atmosphere voxel is 50,000 x 50,000 x 13,000 meters. Despite the low ratio between the clouds and each atmosphere voxel, the extra density is apparent in the clouds. I’m wondering if the ratio for the floating point numbers is between the clouds and the atmosphere. You can see from the screenshot that there’s nothing extreme. The distance between the atmosphere voxels is 10 meters. Even with 1,000 meters, the problem is still there. There must be another factor causing this. Below, I posted two pictures of the new results from my original projects. You can see the problem (viewport version) from the ground and also from above. **Debugging tip:** Under the “Object” tab of the atmosphere object in “Ray Visibility”, if you check/uncheck the options “Camera”, “Volume Scatter”, “Shadow” (mainly those), you can see different aspects of the artifacts. The results depend on the scenario. **Possible solution:** This is where there’s hope to find a fix to this issue. You mentioned: “_However, if the surfaces that define the volume happen to overlap, what can happen is that one of the two surfaces in the same spot is missed. Whether that happens comes down to numerical issues, which explains why it only appears in some places (therefore the blocky look)._” If what you said about the missed spot is true, do you think Blender would be able to detect if it misses the spot? If you could write an extra function to verify this, Blender could output a transparent or empty value instead. It could also output the value of one of the overlapping volumes, like the atmosphere, for example. During my test, I either had something darker (especially overlapping surfaces) or extra light. I have this feeling that detecting when it misses the spot for overlapping volumes and outputting a more strategic value would fix this issue. Does it look like a possible solution? **Conclusion:** Overlapping volumes don’t appear suitable in this context for outdoor real-scale scenes. The only suitable options are a volumetric atmosphere for the haze with billboard clouds or a single volumetric atmosphere that combine the haze and noise clouds in the same shader. If it is made of voxels for more precision, only the ground scene are suitable to avoid seeing the artifacts between the voxels.

Original project - 1.jpg

127 KiB

Original project - 2.jpg

193 KiB

Sebastien Larocque referenced this issue

2023-12-07 05:09:00 +01:00

Overlapping volumes with variable density show artifacts #115871

Sebastien Larocque commented

2023-12-07 05:10:14 +01:00

I just created a new bug report named: “Overlapping volumes with variable density show artifacts”
Reference: #115871

Reason: During the last days after my post just above, I continued testing and I found the problematic aspect. In a nutshell, I have been able to reproduce the problem and to pinpoint one specific aspect to investigate. The new bug report is clearer and really focuses on this particular aspect. I discovered when the atmosphere had variable density values in several positions with the overlapping clouds, the cloud objects showed some artifacts on their faces.

To me, it appears a major milestone in the investigation, especially from the point of view that this kind of problem has been reported several times over the years.

I suggest concentrating the efforts on the new bug report and not on this one in the short term. However, this bug report on this page is still valid because it covers more problematic aspects with the overlapping volumetric objects. It should remain in the long term for improving this topic.

I just created a new bug report named: “Overlapping volumes with variable density show artifacts” Reference: https://projects.blender.org/blender/blender/issues/115871 Reason: During the last days after my post just above, I continued testing and I found the problematic aspect. In a nutshell, I have been able to reproduce the problem and to pinpoint one specific aspect to investigate. The new bug report is clearer and really focuses on this particular aspect. I discovered when the atmosphere had variable density values in several positions with the overlapping clouds, the cloud objects showed some artifacts on their faces. To me, it appears a major milestone in the investigation, especially from the point of view that this kind of problem has been reported several times over the years. I suggest concentrating the efforts on the new bug report and not on this one in the short term. However, this bug report on this page is still valid because it covers more problematic aspects with the overlapping volumetric objects. It should remain in the long term for improving this topic.

Sebastien Larocque commented

2024-04-06 23:18:41 +02:00

I’ve just updated the new bug report mentioned above with new information. The test project includes the same kind of setup with non-overlapping volumes than this one. Mainly, I explained how the Max Steps parameter affects the artifacts based on the distance (and some other parameters).

Reference: #115871

I’ve just updated the new bug report mentioned above with new information. The test project includes the same kind of setup with non-overlapping volumes than this one. Mainly, I explained how the Max Steps parameter affects the artifacts based on the distance (and some other parameters). Reference: https://projects.blender.org/blender/blender/issues/115871

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Visible density seen inside an overlapping volume with zero density value (Cycles) #107418