Page MenuHome

Cycles VDB Artifacts (EEVEE WORKING)
Confirmed, NormalPublicBUG

Description

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.

Event Timeline

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Confirmed.Mon, Jun 15, 5:36 PM
Philipp Oeser (lichtwerk) changed the subtype of this task from "Report" to "Bug".

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)?

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

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

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)

Hi,

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

Regards,
Kamil.

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

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.

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?

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?

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.