Enzo Crema

Oh cool I didn't look hard enough at fvdb

The problem isn't really traversal and memory efficiency, the problem is how to convert a NanoVDB grid back into OpenVDB since Houdini can only build openvdb::Grid<T> types.

I just managed to find a solution 20x faster than the NanoToOpen function :p this will do the work for now but i'll look more into fvdb to see if there's interesting stuff.

the commit if anyone wants to dive in : https://github.com/ZephirFXEC/HNanoSolver/commit/edc5d009c9575cb3089f73dab4edc4fc55996309 [github.com]

PHENOMDESIGN
here are some branches on the OpenVDB github that could help. I believe one is specifically dynamic (they call it adaptive) and the fVDB which would be the new version of the GVDB. Both are branches off the main OpenVDB github.

I saw those but the adaptive openvdb branch is CPU based so unusable in my case and fvdb is python based and i'm kind of a python hater . No but i'd need to do some test as i'm really not as comfortable in python as I am in cpp.

PHENOMDESIGN
As far as transfer, have the grids already built and read/stream with text or json. I saw this in a thread in python but I definitely know you can do this in C++. So you are just transferring string data which should be super-fast.

Yes i'm not using strings as it is very inefficient but I'm traversing the tree on gpu and keeping track of active voxels and the value. Then I loop over those pair on the Host to build the grid.

After some test, I came up with this :
https://github.com/ZephirFXEC/HNanoSolver/blob/master/src/SOP/ReadWrite/SOP_VDBFromGrid.cpp#L114 [github.com]

That i will couple with my Kernels :
https://github.com/ZephirFXEC/HNanoSolver/issues/7 [github.com]

It's veryyyy hacky but it seems like the only solution :/ Nvidia GVDB addresses that issue by having sparse dynamic grids on the GPU but is discontinued