[HDK] Building NanoVDB grids in Houdini

   575   6   0
User Avatar
Member
28 posts
Joined: April 2017
Offline
Hey folks,
I'm running computations on NanoVDB grids on the device then convert them back to OpenVDB in order to build the grid in Houdini.
This round trip Open -> Nano -> Open is really slow, especially the NanoVDB to OpenVDB part.
The HDK allows to build VDB using GU_PrimVDB by exposing
    GU_PrimVDB* buildFromGrid(GU_Detail& gdp, openvdb::GridBase::Ptr grid,
	const GEO_PrimVDB* src = NULL, const char* name = NULL)
    {
	return GU_PrimVDB::buildFromGridAdapter(gdp, &grid, src, name);
    }
which is pretty much an overload of the private function :
    static GU_PrimVDB*	buildFromGridAdapter(
			    GU_Detail& gdp,
			    void* grid,
			    const GEO_PrimVDB*,
			    const char* name);

I was wondering if there was faster way to build a grid by specifying a array of value / positions. So I could extract the necessary information of a NanoVDB grid using a kernel on the device without having to download the whole data on the host.

I already managed to build nanovdb Grids on the device, which increased the speed of the VDB From Particle node by 10x, but writting them back is really challenging.

Any help would be appreciated !
Thanks
Enzo C.
https://www.linkedin.com/in/enzocrema/ [www.linkedin.com]
User Avatar
Member
28 posts
Joined: April 2017
Offline
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
Enzo C.
https://www.linkedin.com/in/enzocrema/ [www.linkedin.com]
User Avatar
Member
155 posts
Joined: May 2021
Offline
ZephirFX
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

There 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.

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.
Edited by PHENOMDESIGN - Sept. 4, 2024 17:29:12
Brave, Big-hearted Rebel
------
Design the Future, Now.
PHENOM DESIGN
------
Processing smarter, not harder on a M3 MAX 36GB
User Avatar
Member
28 posts
Joined: April 2017
Offline
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.
Enzo C.
https://www.linkedin.com/in/enzocrema/ [www.linkedin.com]
User Avatar
Member
155 posts
Joined: May 2021
Offline
fVDB is headers, C++, and Cuda specific kernels: https://github.com/AcademySoftwareFoundation/openvdb/tree/feature/fvdb/fvdb/src [github.com]

It does have Python bindings too but the "src" is C++. You need those Cuda Kernels to keep everything on device. I think they call the approach a jagged tensor kernels.

As far as a transfer, I would think that streaming binary strings or json would be really fast and not inefficient...there is no copy and reads all at once, no loop?
Edited by PHENOMDESIGN - Sept. 4, 2024 19:21:50
Brave, Big-hearted Rebel
------
Design the Future, Now.
PHENOM DESIGN
------
Processing smarter, not harder on a M3 MAX 36GB
User Avatar
Member
28 posts
Joined: April 2017
Offline
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]
Edited by ZephirFX - Sept. 4, 2024 19:25:50
Enzo C.
https://www.linkedin.com/in/enzocrema/ [www.linkedin.com]
User Avatar
Member
155 posts
Joined: May 2021
Offline
ZephirFX
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.

Cool cool. Ya I think I would already have the OpenVDB already built and read that in instead of building on the fly. Then prune if needed.

Check the Multi-threading in OpenVDB presentation under the from 2023 SIGGRAPH Course on the OpenVDB Docs here: https://www.openvdb.org/documentation/ [www.openvdb.org]

It has some benchmarking etc that you will find interesting.

Attachments:
Screenshot 2024-09-04 at 7.32.32PM.png (139.7 KB)

Brave, Big-hearted Rebel
------
Design the Future, Now.
PHENOM DESIGN
------
Processing smarter, not harder on a M3 MAX 36GB
  • Quick Links