OpenVDB and mipmapping

[Andrew Selle]

We're all excited and impressed with OpenVDB, and so we have started to think about using it in production. It's an exciting take on architecture friendly data structures for volumetric data.

On to my question: I was wondering if anyone has started to look at writing a prman ImplicitField plugin that would allow injecting OpenVDB into RenderMan microvoxel shading primvars. One question would be if there are efficient ways of getting min and max estimates of values in the voxels in a given world space bounding box without having to process all points inside that box. Another question is how to handle filtered lookups. Specifically, it would be nice if there was a way to get mipmapped lookups so you would only have to read the data you need to achieve the appropriate level of detail Based on my read of the documentation (and the FAQ "Is VDB an adaptive grid?"). It seems like this is not directly possible. This was an issue we had with Field3D  and I was hoping VDB would have a good solution for this out of the box. If not, one possible solution one could imagine is creating multiple VDBs at different resolutions and choosing the appropriate one to use for different areas at render time. Has anyone done this? Another obvious strategy would be to convert before writing the processed VDB from houdini into a prman brickmap which does support these features. But this seems less desirable as I would imagine VDB is much more optimized. However, if you only need a coarse level of data, no amount of optimization is faster than reading orders of magnitude less data.

Thanks,

-Andy

[Julian Fong]

I've been working on an ImplicitField plugin for prman this week, with the eventual goal of adding official support. I've gotten some nice results from rendering level sets, both as an isosurface (RiBlobby) and as a volume (RiVolume). Kudos to the OpenVDB team on the implementation! I've been able to get the full dragon level set rendered in PRMan (with full ray tracing, physical area light shading, etc) in very reasonable amounts of RAM.

I'd like to add a "me too" to both of Andrew's requests. Some background: RenderMan, being a divide and conquer renderer, would like to subdivide the entire space and quickly figure out the minimum/maximum active value over a subregion. Basically, I'd like something akin to Grid::evalMinMax, but constrained to a bounding box subregion. I've currently implemented this by looping over an accessor in what I hope is optimal i/j/k order and it's faster than I expect, but it's still currently the bottleneck of my implementation. I'm not sure whether implementing a custom tree iterator is a better way of doing this or not.

Also, another "me too" on Andrew's filtering request - I can provide more details on that if needed.

Julian

[koen]

Hello Julian,

Did you compare the performance between getting an accurate min/max for a region and just always giving it the grids min and max? For the mantra vdb procedural, I just always returned the min max of the whole grid. The performance was great (if I remember correctly, vdb volumes rendered faster then native houdini volumes).

I have to admit I do not know completely what these values are used for by the renderer, I kind of assumed they would be used in the velocity and displacement bounds. The empty space optimization in mantra is done by providing a set of bounding box of the regions you want to march, for these I just gave the blocks.

Cheers,
Koen

[Julian Fong]

For a level set converted to a fog volume (as per the cookbook), the min and max are always 0 and 1. PRMan's volume rendering approach is to take the bounding box of the volume and start subdividing it into smaller bounding boxes. At each subdivision, it would like to know the min/max within. If max < threshold (for volume) or (max > threshold) != (min > threshold) (for isosurface) it trivially discards that region. Basically, we end up with a sparse BSP, and getting a quick answer to min/max in a region is helpful to building that BSP quickly. Keeping the BSP sparse is also essential for ray tracing performance, and this is where if I just returned 0/1 for the entire grid we would have performance issues because the BSP wouldn't be sparse.

However, I think I can make PRMan work the other way, i.e. with the list of blocks. Just as a point of clarification: by "blocks" you mean "tiles", right?

Thanks,
Julian

[koen]

Ah yes, if prman uses these values it to discard empty space you'll need a more accurate value .

if you can get it to take a list of boxes, that fits perfectly with the structure vdb.

Here is the mantra spec and for the getBoxes() It just returned the level above the voxels.:

http://www.sidefx.com/docs/hdk12.1/class_v_g_e_o___volume.html

yes, I think I meant tiles, the one level above the actual voxels, I think they changed the name of those, sorry :-).

Cheers,
koen

[Julian Fong]

It ends up that there's a lot of interior nodes for the dragon level set. :-/

However, I managed to solve the performance problem by writing a tree visitor, and making liberal use of iterator::getCoord() and iterator::getParentNode()->getChildDim(), which I hope is a kosher way of figuring out the dimensions of a child.

[OpenVDB]

Hey Andy,

Sorry that it took me so long to get back to you, but we (the VDB team) are totally slammed with production requests and merging stuff from SideFX into the main VDB repository. It's all kosher - just a ton of work! We hope to have another major release next week. Anyway, back to your question about mipmaps and VDB. As you undoubtedly know brickmaps conceptually store LOD representations of the same volume in a single hierarchical tree structure. There are two reasons why this is problematic for VDB. The first one is simply that as of today the VDB data structure can only associate a single value with a given voxel coordinate, (i,j,k). While this value can exist at any of the tree's levels (we call it a "voxel value" if it lives at the leaf level and else a "tile value"), they never "overlap". As hinted this is merely a design choice that could change one day. This takes us to the second and most important reason why a single VDB grid is not well suited as a LOD representation. As you might know the VDB tree, by design, employs very large fan-out factors. In fact this is one of the reasons it has such good random access performance. However, as a consequence the re-refinement between tree level is very high, and probably too aggressive for LOD (>>2). This all sounds like bad news for VDB, but as suggested by yourself a simple approach involves a sequence of VDB grids, each representing a filtered LOD version of the previous grid in the sequence, should work! Since the VDB is sparse and generally has a small memory footprint, the overhead should be relatively small.  While we haven't tried this in a rendering context (yet), we use exactly this approach for multi-resolution simulation, more specifically an elliptic multi-grid solver. We even have plans to add a "multi-tree-grid-type" in the near future that essentially encapsulating this idea in a single class. Let's stay in touch regarding this development!

Cheers,
Ken

PS: I'll add an efficient method to derive the min/max within an aa-bbox next week :)

[OpenVDB]

Hey Julian,

Awesome to hear you're adding support for vdb in prman! We are eager to help you with any performance issues our questions you might have. It sounds like you have addressed the bbox/min/max problem, but I'm happy to look into this if you want? Just say the word (and let me know exactly what you did so I can avoid doing the same :) Anything else we can help with?

Cheers,
Ken

[Cameron Druyor JR]

Does anyone know if this was added?  After grepping around the source and documentation, I haven't found anything, but I may be looking for the wrong terms.  Basically any tool that let me use a bounding box to query the tree would be useful.

Thanks,
-Cameron