Compute hessian of grid?

[medakk]

I see operators to compute gradient, laplacian, etc. Is there any way to compute the hessian of a scalar grid in OpenVDB?

[Idclip]

Hi @medakk - this is a good question, but unfortunately there are no existing tools to do as you've asked. We discussed this at the last technical steering committee (see the notes here https://github.com/AcademySoftwareFoundation/openvdb/pull/699/files#diff-afac2009603b08c8533db3186b50a26eR62). Although the calculation itself should be relatively straightforward, VDB doesn't register matrix grid types by default, which is an example of the type of container/Grid we'd use to represent the results. This evolved into more discussion about whether registering these grid types was the right thing to do as there's lots of complexity involved with adding new default types.

In short, this is something we'd like to pursue, but needs a bit of thought as to how to return the results.

[medakk]

Thanks! Maybe I need to read the paper some more: but what generally limits OpenVDB from having arbitrary(but known at compile time) grid types?

[Idclip]

Hey @medakk, sorry for the late reply. There are two main concerns when instantiating arbitrary grid types. The first is itself defining a compatible type. If you try the following in VDB, you'll currently run into compilation errors:

#include <openvdb/openvdb.h>
using T = openvdb::BoolGrid::ValueConverter<openvdb::math::Mat3<float>>::Type;
int main() { T grid; return 0; }

This is due to certain grid methods requiring certain type operators/function specialisations on the chosen value type. This in essence is fairly minor to solve (there's actually a PR here to resolve this for mats #723) and for your own types, so long as you define the required operators, it's not a big deal.

The second issue is related to serialisation and compile times. Describing this as adding "lots of complexity" was a bit misleading of me - but it does potentially have far reaching consequences. Registering an arbitrary grid type is simple (assuming it can be instantiated):

// int16_t grid type 
using T = openvdb::BoolGrid::ValueConverter<int16_t>::Type;
T::registerGrid(); // T can now be written out to a vdb file

But there's a difference to using that grid type as intermediate storage and registering it for serialisation. Anyone can do the prior in their own applications and are encouraged to do so - however if you register and write out your own custom types (i.e. any types not defined by the default OpenVDB installation), you will not be able to pass these files to any other OpenVDB reader. In addition, adding new grid types as default types to OpenVDB will increase compile times for downstream users due to a) many grid algorithms that still live on the Grid object and b) their applications now potentially requiring to support said type. This is the main reason why there's not hundreds of grid types in the type register by default.

I hope that's cleared things up a bit!

[medakk]

Great explanation, thanks! I'm not sure how many users would require more Grid types like Mat3, but perhaps that could be disabled by a CMake flag?