Will nanoVDB replace(or merge) the gvdb in the future?
yangfengzzz opened this issue · 1 comments
what is the difference for these two repos? there are very few infos about nanoVDB, but I find it already a lot of implementations
Hi yangfengzzz!
The hope is that NanoVDB will replace GVDB in the future, and we're encouraging new voxel projects to start with NanoVDB. However, this will still stay up, since people are still using it. NanoVDB's API is cleaner in many respects and maybe easier to start with, it includes statistics and cleaner raycasting, is easier to include (on account of the header file approach) and it's where most development effort is going. The main limitation of NanoVDB compared to GVDB at the moment is that NanoVDB doesn't explicitly support modifying the topology of the tree after it's been created (e.g. adding new bricks in GVDB) -- but I think this may be more of an API limitation than a data structure limitation, since if you're willing to go low-level enough the data structure does support some topology modification so long as it fits in the allocated buffer, and if re-allocating a buffer is OK then I think it might even be possible to reimplement GVDB over NanoVDB.
To help with interop between the two, we have the gNanoVDB sample which shows how to convert a GVDB volume into a NanoVDB volume (there's some trickiness there because we handle most tree branching factors using code in a .ptx file, while if you only have to handle one tree branching factor or if you can use the CUDA Runtime API things get easier). I'm also hoping to improve GVDB documentation, so that if someone wants to port their GVDB code to NanoVDB, it's easier to determine what a GVDB function call is doing.
My main source for NanoVDB reference is the NanoVDB examples; NanoVDB.h is also extensively documented and is a good source for low-level info.
Hope this helps!