Cycles VDB Artifacts (EEVEE WORKING) #77882

New Issue

Kamil Adamski · 2020-06-15T14:53:33+02:00

Kamil Adamski commented

2020-06-15 14:53:33 +02:00

System Information
Operating system: Windows 10 PRO
Graphics card: RTX 2070S

Blender Version
Broken: Official newest from Blender.org, also newest from builder.blender.org
Worked: None.
Short description of error
As shown on the image, Cycles VDB volume rendering, got some quad, boxy holes in the sim. Appeared mostly in Flames areas. Or only in flames areas.

Exact steps for others to reproduce the error
Import VDB from EmberGen sim, add volume shader, change temperature attribute to "flames", and run render (doesn't matter if from the viewport, or normal)
Attaching project files with blend, and VDB sequence.

VDB_Artifact.zip

**System Information** Operating system: Windows 10 PRO Graphics card: RTX 2070S **Blender Version** Broken: Official newest from Blender.org, also newest from builder.blender.org Worked: None. **Short description of error** As shown on the image, Cycles VDB volume rendering, got some quad, boxy holes in the sim. Appeared mostly in Flames areas. Or only in flames areas. **Exact steps for others to reproduce the error** Import VDB from EmberGen sim, add volume shader, change temperature attribute to "flames", and run render (doesn't matter if from the viewport, or normal) Attaching project files with blend, and VDB sequence. ![Artifact_comparison.jpg](https://archive.blender.org/developer/F8621086/Artifact_comparison.jpg) [VDB_Artifact.zip](https://archive.blender.org/developer/F8621074/VDB_Artifact.zip)

Kamil Adamski commented

2020-06-15 14:53:33 +02:00

Added subscriber: @adrian2608

blender-admin commented

2020-06-15 14:53:33 +02:00

#79718 was marked as duplicate of this issue

Philipp Oeser commented

2020-06-15 17:36:47 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-06-15 17:36:47 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2020-06-15 17:36:47 +02:00

This would need a bit more investigation, but yes, I can confirm the issue.
Also Eevee visualization disappears for me in perspective view (and shows in ortho)?

This would need a bit more investigation, but yes, I can confirm the issue. Also Eevee visualization disappears for me in perspective view (and shows in ortho)?

Kamil Adamski commented

2020-06-15 23:28:48 +02:00

Apologize for asking, because I know, it's not working like that. But sadly I really need that get to work for client job. Off course I can use Mantaflow, but it will take too much time to achieve the effect.
How can I expect this bug to be resolved?
Best Regards

Apologize for asking, because I know, it's not working like that. But sadly I really need that get to work for client job. Off course I can use Mantaflow, but it will take too much time to achieve the effect. How can I expect this bug to be resolved? Best Regards

Brecht Van Lommel commented

2020-06-17 13:44:05 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2020-06-17 13:44:05 +02:00

Setting Clipping to 0.0 on the volume object may work around this, at the cost of reduced performance.

Philipp Oeser commented

2020-06-17 13:59:19 +02:00

In #77882#955859, @brecht wrote:
Setting Clipping to 0.0 on the volume object may work around this, at the cost of reduced performance.

I tried that as well (with only minor improvements)

> In #77882#955859, @brecht wrote: > Setting Clipping to 0.0 on the volume object may work around this, at the cost of reduced performance. I tried that as well (with only minor improvements)

Kamil Adamski commented

2020-06-29 23:11:41 +02:00

Hi,

And how with this bug? When You estimate it can be handle?

Regards,
Kamil.

Hi, And how with this bug? When You estimate it can be handle? Regards, Kamil.

Brecht Van Lommel commented

2020-06-30 11:37:36 +02:00

We don't have time estimates for when bugs will be fixed.

Kévin Dietrich commented

2020-07-07 13:14:56 +02:00

Added subscriber: @kevindietrich

Kévin Dietrich self-assigned this 2020-07-07 13:14:56 +02:00

Kévin Dietrich commented

2020-07-07 13:14:56 +02:00

So the bug is in the mesh generation algorithm I worked on, so I guess it's my duty to fix it. Judging from the topology of the VDB grid vs the mesh we generate, it seems as though some nodes that only have a few active voxels are not properly accounted for (their coordinates seem to be clamped to nearest neighbour node, despite adding some padding). I am not sure what the solution would be; perhaps a more robust approach would be to simply downsample each grid, and then run the mesh generation on the downsampled grids. The weighing function for downsampling would then also need to be aware of padding. To save some memory, we could have a single grid to accumulate the downsampling of every other grid, this should still work for clipping.

Also in this file, with a clipping of 0.0, the generated mesh is not watertight at all, a lot of triangles are missing.

So the bug is in the mesh generation algorithm I worked on, so I guess it's my duty to fix it. Judging from the topology of the VDB grid vs the mesh we generate, it seems as though some nodes that only have a few active voxels are not properly accounted for (their coordinates seem to be clamped to nearest neighbour node, despite adding some padding). I am not sure what the solution would be; perhaps a more robust approach would be to simply downsample each grid, and then run the mesh generation on the downsampled grids. The weighing function for downsampling would then also need to be aware of padding. To save some memory, we could have a single grid to accumulate the downsampling of every other grid, this should still work for clipping. Also in this file, with a clipping of 0.0, the generated mesh is not watertight at all, a lot of triangles are missing.

Brecht Van Lommel commented

2020-07-07 14:35:19 +02:00

The issue may be that we are only building the mesh for the smoke grid, not the fire grid?

It would be good to change the mesh generation to be done directly from OpenVDB grids and their leaf nodes (and for non-OpenVDB grids, we could build one). This could be fast since we can look at leaf nodes and ignore individual voxel values.

For multiple grids with potentially different transforms, we can merge grids into one using the various OpenVDB utility functions (also ignoring individual voxels).

The issue may be that we are only building the mesh for the smoke grid, not the fire grid? It would be good to change the mesh generation to be done directly from OpenVDB grids and their leaf nodes (and for non-OpenVDB grids, we could build one). This could be fast since we can look at leaf nodes and ignore individual voxel values. For multiple grids with potentially different transforms, we can merge grids into one using the various OpenVDB utility functions (also ignoring individual voxels).

Kévin Dietrich commented

2020-07-07 15:19:59 +02:00

The issue may be that we are only building the mesh for the smoke grid, not the fire grid?

I did not consider that a grid was missing because there was a loop over voxel_grids, but yeah apparently the flames grid is skipped because of differences in resolution. So the best fix would be to use OpenVDB, with a topological merge of all the grids. For that we would need to have access to the VDB grids, and looking at the code the best place seem to be ImageHandle, which could give us access to the VDBImageLoader, and if there is not one, it would mean we don't have a VDB grid, so we would have to create one from the dense buffer. What do you think about that?

> The issue may be that we are only building the mesh for the smoke grid, not the fire grid? I did not consider that a grid was missing because there was a loop over `voxel_grids`, but yeah apparently the `flames` grid is skipped because of differences in resolution. So the best fix would be to use OpenVDB, with a topological merge of all the grids. For that we would need to have access to the VDB grids, and looking at the code the best place seem to be `ImageHandle`, which could give us access to the `VDBImageLoader`, and if there is not one, it would mean we don't have a VDB grid, so we would have to create one from the dense buffer. What do you think about that?

Brecht Van Lommel commented

2020-07-07 15:20:55 +02:00

In #77882#974578, @kevindietrich wrote:
I did not consider that a grid was missing because there was a loop over voxel_grids, but yeah apparently the flames grid is skipped because of differences in resolution. So the best fix would be to use OpenVDB, with a topological merge of all the grids. For that we would need to have access to the VDB grids, and looking at the code the best place seem to be ImageHandle, which could give us access to the VDBImageLoader, and if there is not one, it would mean we don't have a VDB grid, so we would have to create one from the dense buffer. What do you think about that?

All sounds good to me.

> In #77882#974578, @kevindietrich wrote: > I did not consider that a grid was missing because there was a loop over `voxel_grids`, but yeah apparently the `flames` grid is skipped because of differences in resolution. So the best fix would be to use OpenVDB, with a topological merge of all the grids. For that we would need to have access to the VDB grids, and looking at the code the best place seem to be `ImageHandle`, which could give us access to the `VDBImageLoader`, and if there is not one, it would mean we don't have a VDB grid, so we would have to create one from the dense buffer. What do you think about that? All sounds good to me.

Andrew Walsh commented

2020-07-19 12:36:08 +02:00

Added subscriber: @andywalshart

Andrew Walsh commented

2020-07-19 12:36:09 +02:00

Just to add some other examples of this bug. You can see the squares in the mist pass and then in another scene (circled in red) it's very subtle. Then I added some water (test002c) and you could faintly see the squares so I put some emission on the vdb just to really highlight the problem. Then I added a cube just to see if it was the water that was the issue (test002d) and what's odd is that I didn't touch the settings on the vdb material but it looks way different. The water is a cube with some volumetrics added. Let me know if you want the Blender file.

Just to add some other examples of this bug. You can see the squares in the mist pass and then in another scene (circled in red) it's very subtle. Then I added some water (test002c) and you could faintly see the squares so I put some emission on the vdb just to really highlight the problem. Then I added a cube just to see if it was the water that was the issue (test002d) and what's odd is that I didn't touch the settings on the vdb material but it looks way different. The water is a cube with some volumetrics added. Let me know if you want the Blender file. ![test002d.png](https://archive.blender.org/developer/F8706388/test002d.png) ![test002c.png](https://archive.blender.org/developer/F8706387/test002c.png) ![test002b.jpg](https://archive.blender.org/developer/F8706386/test002b.jpg) ![City-After_MAIN2_mist.jpg](https://archive.blender.org/developer/F8706385/City-After_MAIN2_mist.jpg)

Brecht Van Lommel commented

2020-08-10 16:24:55 +02:00

Marking as high prio since we plan to fix this for 2.90.

blender-admin commented

2020-08-11 17:34:34 +02:00

This issue was referenced by blender/cycles@d434741e75

This issue was referenced by blender/cycles@d434741e75f278097a275859fbf313ed82b8e47e

blender-admin commented

2020-08-11 17:34:34 +02:00

This issue was referenced by 9280fb19e4

This issue was referenced by 9280fb19e4ff5038734d9867d152c10d4daf03bb

Brecht Van Lommel commented

2020-08-12 12:07:29 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Brecht Van Lommel closed this issue

2020-08-12 12:07:29 +02:00

Brecht Van Lommel commented

2020-08-12 15:59:54 +02:00

Added subscriber: @WhitecloudFX

Korbinian Weber commented

2020-08-12 16:09:50 +02:00

As of right now a workaround for this goes as follows:

Import the OpenVDB-Files twice
Assign a Material with a Principled Volume Shader to the first OpenVDB-Object (this will become the smoke-shader). Don't use Blackbody Emission on this one.
Assign a second material to the second OpenVDB-Object with an emission shader using the Attribute node to access the "temperature" and "flame(s)" attributes. Use the "flame"-Attribute-Node as Input for Emission strength (maybe multiply it) and connect "temperature" to the Blackbody Node and use that as the Emission color. This will become the fire-shader.

IMPORTANT: Do NOT use Principled Volume Shader or "density"- Attribute in the fire-shader. Once you do so the bug will occur again. To fix that, delete the Principled Volume/Attribute-"density" in the fire-shader and restart blender.

As of right now a workaround for this goes as follows: - Import the OpenVDB-Files twice - Assign a Material with a Principled Volume Shader to the first OpenVDB-Object (this will become the smoke-shader). Don't use Blackbody Emission on this one. - Assign a second material to the second OpenVDB-Object with an emission shader using the Attribute node to access the "temperature" and "flame(s)" attributes. Use the "flame"-Attribute-Node as Input for Emission strength (maybe multiply it) and connect "temperature" to the Blackbody Node and use that as the Emission color. This will become the fire-shader. IMPORTANT: Do NOT use Principled Volume Shader or "density"- Attribute in the fire-shader. Once you do so the bug will occur again. To fix that, delete the Principled Volume/Attribute-"density" in the fire-shader and restart blender.

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

Cycles VDB Artifacts (EEVEE WORKING) #77882