Cycles: volume sampling improvements #92570

New Issue

Brecht Van Lommel · 2021-10-28T14:43:47+02:00

Brecht Van Lommel commented

2021-10-28 14:43:47 +02:00

Product importance sampling
Null scattering
Density bounds
Volume BVH
Motion blur: clamp/discard velocity vectors with too high magnitude

- [ ] [Product importance sampling ](https://graphics.pixar.com/library/CandidateSampling/) - [ ] [Null scattering ](https://cs.dartmouth.edu/wjarosz/publications/miller19null.html) - [ ] Density bounds - [ ] Volume BVH - [ ] Motion blur: clamp/discard velocity vectors with too high magnitude

Brecht Van Lommel commented

2021-10-28 14:43:47 +02:00

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

Brecht Van Lommel commented

2021-10-28 14:43:47 +02:00

Added subscriber: @brecht

Alaska commented

2021-10-28 14:54:44 +02:00

Added subscriber: @Alaska

Emi Martinez commented

2021-10-29 00:14:26 +02:00

Added subscriber: @Emi_Martinez

Paul Larson commented

2021-10-29 05:37:54 +02:00

Added subscriber: @GeorgiaPacific

Antoine Webanck commented

2021-12-04 10:02:23 +01:00

Added subscriber: @webanck

Garek commented

2022-01-26 06:10:52 +01:00

Added subscriber: @Garek

Brecht Van Lommel commented

2022-03-31 20:35:27 +02:00

Memory dump on the Volume BVH idea:

OpenVDB/NanoVDB by itself already stores the volume in a tree structure, with inner nodes that contain leaf nodes, and leaf nodes that contain voxels. NanoVDB also comes with a traversal function in nanovdb/util/HDDA.h that we may be able to use, or adapt.

However we need something on top of that, since a scene can contain multiple objects, and these may be rotated or scaled, or the same object may be instanced multiple times. This I think is the main problem to solve, to find which object instances (potentially) overlap a ray segment from point A to B. For that, we can use a fairly simple BVH structure based on bounding boxes of each object, it doesn't need to be super optimized. And then gather that list of objects in an array in the kernel before volume shading.

Then as a second step, that BVH could be made more fine grained. Instead of the full object bounding box, you could put inner or leaf node bounding boxes into the BVH, to avoid more false positives.

Making the BVH work all the way down to the voxel level (with an algorithm like HDDA) would be a good optimization too, however that's not a requirement for an initial implementation. In some ways this is an orthogonal problem, and would require some deeper rethinking of how we do volume stepping in the shade_volume kernel.

Memory dump on the Volume BVH idea: OpenVDB/NanoVDB by itself already stores the volume in a tree structure, with inner nodes that contain leaf nodes, and leaf nodes that contain voxels. NanoVDB also comes with a traversal function in `nanovdb/util/HDDA.h` that we may be able to use, or adapt. However we need something on top of that, since a scene can contain multiple objects, and these may be rotated or scaled, or the same object may be instanced multiple times. This I think is the main problem to solve, to find which object instances (potentially) overlap a ray segment from point A to B. For that, we can use a fairly simple BVH structure based on bounding boxes of each object, it doesn't need to be super optimized. And then gather that list of objects in an array in the kernel before volume shading. Then as a second step, that BVH could be made more fine grained. Instead of the full object bounding box, you could put inner or leaf node bounding boxes into the BVH, to avoid more false positives. Making the BVH work all the way down to the voxel level (with an algorithm like HDDA) would be a good optimization too, however that's not a requirement for an initial implementation. In some ways this is an orthogonal problem, and would require some deeper rethinking of how we do volume stepping in the `shade_volume` kernel.

San Rin commented

2022-04-13 10:52:58 +02:00

Added subscriber: @Rin-San

Kévin Dietrich commented

2022-04-13 18:05:19 +02:00

Added subscriber: @kevindietrich

Kévin Dietrich commented

2022-04-13 18:05:19 +02:00

I did not mention it during the last rendering meeting, but while working on Tangent's patch for volume motion blur, I also spent a bit of time updating their delta/residual tracking work to current master. I'll just put some notes from my observation of this work.

I managed to get some render out of it. Although it wasn't looking good: emission is not working, direct light is missing, and the volume mesh was visible. Then, even for Tangent, this was work in progress.

In there, they use an octree to encode the volumes topology as well as some extra data. The octree is supposed to replace both the volume meshes and the volume stack. I did not update the BVH traversal to also include the volume octree traversal; that could explain some of the volume mesh artifacts. To replace the volume stack, each leaf node in the octree has a list of active volumes. For now the list of volumes is fixed to 1024 volume objects, which is a bit much too much memory-wise to my liking, maybe it should be somehow more dynamic (e.g. the leaf nodes could store a pointer into some packed list).

The leaf nodes also store the min/max values for the volumes so null scattering probability is bounded by the actual volume density, however this is computed over the entire domain, so minimum is pretty much always 0. That should be more granular and done at the OpenVDB tile level, or maybe leaf level. The octree is built from the list of objects which have a volume geometry, so this could perhaps already handle instances. The octree is built from the volume bounding boxes though; it could be more fined grained.

I guess I could post a patch as some sort of proof of concept, or as a starting point or reference for me or someone else to continue this work. At least it is somewhat up to date with master.

I did not mention it during the last rendering meeting, but while working on Tangent's patch for volume motion blur, I also spent a bit of time updating their delta/residual tracking work to current master. I'll just put some notes from my observation of this work. I managed to get some render out of it. Although it wasn't looking good: emission is not working, direct light is missing, and the volume mesh was visible. Then, even for Tangent, this was work in progress. In there, they use an octree to encode the volumes topology as well as some extra data. The octree is supposed to replace both the volume meshes and the volume stack. I did not update the BVH traversal to also include the volume octree traversal; that could explain some of the volume mesh artifacts. To replace the volume stack, each leaf node in the octree has a list of active volumes. For now the list of volumes is fixed to 1024 volume objects, which is a bit much too much memory-wise to my liking, maybe it should be somehow more dynamic (e.g. the leaf nodes could store a pointer into some packed list). The leaf nodes also store the min/max values for the volumes so null scattering probability is bounded by the actual volume density, however this is computed over the entire domain, so minimum is pretty much always 0. That should be more granular and done at the OpenVDB tile level, or maybe leaf level. The octree is built from the list of objects which have a volume geometry, so this could perhaps already handle instances. The octree is built from the volume bounding boxes though; it could be more fined grained. I guess I could post a patch as some sort of proof of concept, or as a starting point or reference for me or someone else to continue this work. At least it is somewhat up to date with master.

Brecht Van Lommel commented

2022-04-14 19:51:52 +02:00

Thanks for the info, if you have a patch that applies to master that's always helpful, even if just as a reference.

I'm not exactly sure what you meant regarding including volume octree traversal in BVH traversal, but I think they should be separate. The way I would imagine it to work is that intersect_closest would check if there are any potential intersections after BVH traversal has determined the start/end, to see if there is a need to run the shade_volume kernel. And then in shade_volume we traverse the octree, updating the volume stack as it goes. Direct and indirect light sampling would then work on all volumes between the two surfaces at once.

With null scattering it's also possible to handle each volume separately, but still you'd want to do shading for potentially multiple ray segments of that volume between surfaces in one go.

Thanks for the info, if you have a patch that applies to master that's always helpful, even if just as a reference. I'm not exactly sure what you meant regarding including volume octree traversal in BVH traversal, but I think they should be separate. The way I would imagine it to work is that `intersect_closest` would check if there are any potential intersections after BVH traversal has determined the start/end, to see if there is a need to run the `shade_volume` kernel. And then in `shade_volume` we traverse the octree, updating the volume stack as it goes. Direct and indirect light sampling would then work on all volumes between the two surfaces at once. With null scattering it's also possible to handle each volume separately, but still you'd want to do shading for potentially multiple ray segments of that volume between surfaces in one go.

Kévin Dietrich commented

2022-04-14 23:46:40 +02:00

In #92570#1341274, @brecht wrote:
Thanks for the info, if you have a patch that applies to master that's always helpful, even if just as a reference.

I created a draft revision: D14656: Cycles: ratio tracking for volume rendering [WIP]

I'm not exactly sure what you meant regarding including volume octree traversal in BVH traversal, but I think they should be separate. The way I would imagine it to work is that intersect_closest would check if there are any potential intersections after BVH traversal has determined the start/end, to see if there is a need to run the shade_volume kernel.

Yes, sorry, I meant to say the overall scene traversal. As it stands, I added the octree traversal after scene_intersect in integrator_intersect_closest. Although it commented out.

And then in shade_volume we traverse the octree, updating the volume stack as it goes. Direct and indirect light sampling would then work on all volumes between the two surfaces at once.

With null scattering it's also possible to handle each volume separately, but still you'd want to do shading for potentially multiple ray segments of that volume between surfaces in one go.

Just to note, the patch does not bother with the stack. At each step, all of the volume shaders in the current leaf node are evaluated at once.

> In #92570#1341274, @brecht wrote: > Thanks for the info, if you have a patch that applies to master that's always helpful, even if just as a reference. I created a draft revision: [D14656: Cycles: ratio tracking for volume rendering [WIP]](https://archive.blender.org/developer/D14656) > I'm not exactly sure what you meant regarding including volume octree traversal in BVH traversal, but I think they should be separate. The way I would imagine it to work is that `intersect_closest` would check if there are any potential intersections after BVH traversal has determined the start/end, to see if there is a need to run the `shade_volume` kernel. Yes, sorry, I meant to say the overall scene traversal. As it stands, I added the octree traversal after `scene_intersect` in `integrator_intersect_closest`. Although it commented out. > And then in `shade_volume` we traverse the octree, updating the volume stack as it goes. Direct and indirect light sampling would then work on all volumes between the two surfaces at once. > > With null scattering it's also possible to handle each volume separately, but still you'd want to do shading for potentially multiple ray segments of that volume between surfaces in one go. Just to note, the patch does not bother with the stack. At each step, all of the volume shaders in the current leaf node are evaluated at once.

Sam Morse-Brown commented

2022-04-27 13:51:36 +02:00

Added subscriber: @ParallelMayhem

Jakub Jaszewski commented

2023-01-22 14:47:44 +01:00

Added subscriber: @silex

Daniel Gryningstjerna commented

2023-01-22 14:53:28 +01:00

Added subscriber: @Dangry

Brecht Van Lommel added this to the Render & Cycles project 2023-02-07 19:08:06 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles: volume sampling improvements #92570