I’m playing around with VDB’s in Unreal using heterogeneous volumes and in pathtracer and am having this pixelated and blocky gitch when previewing and after rendering.
I’ve tried using this command hoping it’d help but it doesn’t seem to:
r.PathTracing.HeterogeneousVolumes.RebuildEveryFrame
Any tips?
Hi. What you are showing is an out-of-memory condition when allocating voxels inside the path tracer. You need to twiddle some CVars to configure the setup code to allow for more allocation. I’ll reply separately for recommendations, specific to your problem:
r.PathTracing.HeterogeneousVolumes (default = 0)
Enables path tracing of heterogeneous volumes.
r.HeterogeneousVolumes.OrthoGrid (default = 1)
Enables the world-space voxel grid.
r.HeterogeneousVolumes.OrthoGrid.MaxBottomLevelMemoryInMegabytes (default = 128)
Determines the memory limit (in megabytes) for each bottom-level voxel grid used for voxelization (emission, extinction, and albedo). The recommended cinematic default is 512.
r.HeterogeneousVolumes.OrthoGrid.ShadingRate ([default = 4)
Determines the active shading rate of the world-space voxel grid, where the value roughly corresponds to pixel width. Lower shading rates creates a higher quality tessellation, but requires more memory. The recommended cinematic default is 1.
r.HeterogeneousVolumes.FrustumGrid (default = 1)
Enables the frustum-aligned voxel grid.
r.HeterogeneousVolumes.FrustumGrid.MaxBottomLevelMemoryInMegabytes (default = 128)
Determines the memory limit (in megabytes) for each bottom-level voxel grid used for voxelization (emission, extinction, and albedo). The recommended cinematic default is 512.
r.HeterogeneousVolumes.FrustumGrid.ShadingRate (default = 4)
Determines the active shading rate of the frustum-aligned voxel grid, where the value roughly corresponds to pixel width. Lower shading rates creates a higher quality tessellation, but requires more memory. The recommended cinematic default is 1.
r.HeterogeneousVolumes.FrustumGrid.DepthSliceCount (default = 512)
Determines the number of depth slices of the frustum-aligned voxel grid, when rendered with a shading rate of 1. Rendering with a shading rate of 2 will correspond to emitting a Depth Slice Count of 256. The recommended cinematic default is 512/1024.
r.HeterogeneousVolumes.Tessellation.FarPlaneAutoTransition (default = 1)
Truncates the far-plane of the frustum-aligned grid when the voxel size of the frustum-aligned voxel grid corresponds to the voxel size of the world-space voxel grid.
The out-of-memory condition you are witnessing in the path tracer usually stems from decreasing the shading rate without compensating for the bottom-level memory required to support the increase in quality. There is also some interplay with the ortho/frustum grid that can cause a few false negatives when debugging such an issue. I would begin by disabling this interplay:
r.HeterogeneousVolumes.Tessellation.FarPlaneAutoTransition 0
Applying this CVar forces the path tracer to use the frustum grid for all volumes within the view frustum. Now, all of the CVars affecting the primary-visible volume will be associated with the frustum grid. You will likely immediately notice coarser voxelization in the primary viewport when applying this CVar, if the volume is close to camera. This is expected.
As mentioned earlier, the problem is related to the amount of memory allocated versus what is actually required to render the voxelized dataset. This is my default pairing when beginning to increase quality of the frustum grid:
r.HeterogeneousVolumes.FrustumGrid.ShadingRate 2
r.HeterogeneousVolumes.FrustumGrid.MaxBottomLevelMemoryInMegabytes 512
You’ll see aliasing because the frustum voxels are typically 2x2 pixels big. To address this, you’ll need to lower the shading rate to 1, but this will require a significant increase in quality. Typically this also affects the interactivity of the shot in the path tracer, so I opt to use these controls with MRQ:
r.HeterogeneousVolumes.FrustumGrid.ShadingRate 1
r.HeterogeneousVolumes.FrustumGrid.MaxBottomLevelMemoryInMegabytes 1792
There is a hard-limit with resource allocation at 2GB, and I’ve hit some unexpected issues when attempting to allocate the resource cap. What I’ve listed here is my typical maximum value. We are ultimately limited by this resource maximum and cannot currently allocate more voxels without significant implementation changes to overcome this hardware/API limitation. We intend to address this issue in the future, but we have no immediate plans for the short term.
We do intend to address this weird relationship between shading rate and bottom-level memory, such that you are not forced into a condition that will drop voxels. The reasonable alternative is to adaptively adjust the shading rate to match what the user had determined is the appropriate maximum amount of bottom-level memory. This is our planned strategy, moving forward. This will cause a potentially sudden quality loss if the system is unable to render the full frustum at the desired shading rate, but we expect this is a better alternative than simply dropping voxels. In the meantime, you will have to adjust both CVars individually and re-render at a lower shading rate if you notice dropped voxels.
Thank you so much for this very detailed and informative response Patrick! This has been bugging me but seems to all make a lot more sense now. I will try these solutions out. Really appreciate all this info!
Hi, I had a similar problem and this command helped me:
r.HeterogeneousVolumes.Tessellation.MinimumVoxelSizeInFrustum 10
And this error also occurs if the material is too dense, you can try reducing the density.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.