OpenVDB, buildFromGrid doesn't work?

[michaelw]

hi there, I'm playing around the vdb with houdini but I noticed it doesn't work very well. For example, I tried to convert a grid to a VDB primitive as below:

openvdb::FloatGrid::Ptr sphere_grid = openvdb::tools::createLevelSetSphere<openvdb::FloatGrid>(50.0, openvdb::Vec3f(1.5, 2, 3),0.5,4.0);

sphere_grid->insertMeta("radius", openvdb::FloatMetadata(50.0));

sphere_grid->setName("LevelSetSphere");

GU_PrimVDB* vdb_ptr = GU_PrimVDB::buildFromGrid(*gdp, sphere_grid);
[/CODE]

but I got the following error message:

[CODE]error: ‘buildFromGrid’ is not a member of ‘GU_PrimVDB’[/CODE]

I don't understand this error because I already followed the guide from GU_PrimVDB.h

[CODE]00103 // NOTE: For static member functions please call in the following
00104 // manner. <ptrvalue> = GU_PrimVDB::<functname>
00105 // i.e. partptr = GU_PrimVDB::build(params...);[/CODE]

Anyone succeeded in using the "buildFromGrid" method? I was also wondering when will houdini ships the header files of the OpenVDB library.

P.S it would be nice to see some HDK examples with OpenVDB

Thanks,

Edited March 21, 2013 by michaelw

[edward]

Sorry, the OpenVDB headers are not shipped with the HDK yet. There are some symbol issues that we want to resolve first in order to allow studios to use ABI-compatible, but private OpenVDB implementations. Once we have that stabilized, we'll start shipping the headers within the HDK.

Part of the problem is that you're probably using the opensource version of OpenVDB which has OPENVDB_VERSION_NAME (defined in openvdb/version.h) set to something like v1_0_0 whereas Houdini's libopenvdb.so is built with it set to v1_0_0_sesi. So at a minimum, you need to make sure that matches or else you will get linker errors.

[edward]

P.S it would be nice to see some HDK examples with OpenVDB

There's a link to the source for most of the VDB SOPs here: http://www.openvdb.org/download/

(direct link: http://www.openvdb.o...0_0_houdini.zip )

[magneto]

Edward, does this mean all Houdini source code utilizing OpenVDB must be open source? It says mozilla license, so I assume it's not that strict, but you can do whatever you want, even hide it all? Anyway just curious.

[edward]

Edward, does this mean all Houdini source code utilizing OpenVDB must be open source? It says mozilla license, so I assume it's not that strict, but you can do whatever you want, even hide it all? Anyway just curious.

IANAAL, but my reading of the MPL license FAQ says no. Note that Side Effects is not licensing OpenVDB under the MPL because of a prior collaboration agreement.

Most of the VDB-specific SOPs currently in Houdini 12.5 were written by DreamWorks, and these are the ones that they graciously open sourced as well. DreamWorks had originally developed the toolset within Houdini via the HDK for production use (eg. used on Puss in Boots).

[magneto]

Thanks for the info Edward, that's awesome. I am surprised a company actually does that. Most companies I know and worked are very stingy with their tools even when the tools are very specific and trivial that no one outside the company would care about them. But they treat it like it's a high end trade secret that needs to be guarded by the HR.

I wish more companies do that with you, like ILM, SPI, Framestore, etc for the sake of innovation. Not that SESI needs it, but still

[michaelw]

hi edward, thanks for your reply.

Sorry, the OpenVDB headers are not shipped with the HDK yet. There are some symbol issues that we want to resolve first in order to allow studios to use ABI-compatible, but private OpenVDB implementations. Once we have that stabilized, we'll start shipping the headers within the HDK.

Will this happen in the following months? or it will only be possible for the next major release (H13)?

Part of the problem is that you're probably using the opensource version of OpenVDB which has OPENVDB_VERSION_NAME (defined in openvdb/version.h) set to something like v1_0_0 whereas Houdini's libopenvdb.so is built with it set to v1_0_0_sesi. So at a minimum, you need to make sure that matches or else you will get linker errors.

Yeah, i will try this today to see if it works.

There's a link to the source for most of the VDB SOPs here: http://www.openvdb.org/download/

(direct link: http://www.openvdb.o...0_0_houdini.zip )

sure. But I mean some simple example that users can explore without all those configurations with dreamworks vdb code and sesi library (which is what i'm doing right now...). Just something like those sample code shipped with HDK (like that SOP_Star).

Anyway, thanks for the information.

Edited March 22, 2013 by michaelw

[edward]

Will this happen in the following months? or it will only be possible for the next major release (H13)?

This will happen for the next H12.5 production build, which we're trying to get out soon.

sure. But I mean some simple example that users can explore without all those configurations with dreamworks vdb code and sesi library (which is what i'm doing right now...). Just something like those sample code shipped with HDK (like that SOP_Star).

I see, but note that the Transform and Scatter ones are pretty simple if you just look at their cookMySop() implementations, which you can easily transplant into your own code.

[michaelw]

This will happen for the next H12.5 production build, which we're trying to get out soon.

That's great news. Thanks!

[michaelw]

Hi Edward, I saw H12.5.371 production build came out, but I didn't find the openvdb header files. Any information about this?

This will happen for the next H12.5 production build, which we're trying to get out soon.

[edward]

Sorry, didn't quite make it out in time as we're still doing some production testing. We will try to put up another production build as soon as we're done. If you take the production build, it should be compilable against any post-1.0.0 OpenVDB headers. The H12.5.371 is using OpenVDB 1.1

[michaelw]

Sorry, didn't quite make it out in time as we're still doing some production testing. We will try to put up another production build as soon as we're done. If you take the production build, it should be compilable against any post-1.0.0 OpenVDB headers. The H12.5.371 is using OpenVDB 1.1

Great. Thanks edward!