FloatGrid to Vec3SGrid and back to FloatGrid

[MotivaCG]

Here is a basic sample converting them and dumping the result into a mesh:

// FloatGrid  to Vec3SGrid
openvdb::Vec3SGrid::Ptr Vec3SGrid = openvdb::Vec3SGrid::create();
Vec3SGrid->setTransform( floatGridA->transformPtr());
for (auto itAll =  floatGridA ->cbeginValueOn(); itAll; ++itAll) {
        auto pos = itAll.getCoord();
        auto valueAll = itAll.getValue();
        auto Vec3s = Vec3SGrid->tree().getValue(pos);
        Vec3s[0] = valueAll;
        Vec3SGrid->tree().setValue(pos, Vec3s);       
 }

// Back to FloatGrid
openvdb::FloatGrid::Ptr floatGridB = openvdb::FloatGrid::create();
floatGridB ->setTransform( Vec3SGrid->transformPtr());
for (auto it = grid->cbeginValueOn(); it; ++it) {
      auto pos = it.getCoord();
      auto Vec3s = it.getValue();
       floatGridB->tree().setValue(pos, Vec3s[0]);
}

 OpenVDBMesh meshA, meshB;
    openvdb::tools::volumeToMesh(*floatGridA ,  meshA.points,  meshA.faces,  meshA.quads, iso, adapt, flag_relax);    openvdb::tools::volumeToMesh(*floatGridB ,  meshB.points,  meshB.faces,  meshB.quads, iso, adapt, flag_relax);

Unfortunately the besides I've copied transform too, the result on both meshes are different.

Any idea on that? thank you!

[Idclip]

Signed and Unisigned distance fields in VDB have more data associated with them than just their active values. Importantly, inactive values in signed distance fields have the same appropriate signs as active values, where positive (+) values represent the outside of the field and negative (-) values represent the inside. The background value of a level set also holds intrinsic information, mainly representative of the maximum possible world space distance from the surface to which valid distance values are query-able. When you convert a valid level set to a mesh, the algorithm will need to check at least some of these inactive values (as well as the grids background value) to accurately pinpoint the represented iso surface.

What you're doing here is only copying the active states but leaving any potential inactive neighbours as zero initialized. Should volumeToMesh need to perform neighbouring lookups/samples, these zero weights will most likely a) cause sampling errors and b) cause issues inside the level set where positive zeros (+0) are inferred as an outside coordinates.

I would try changing your value iterator from cbeginValueOn to cbeginValueAll. I would also make sure that your floatGridB is marked as a level set and has it's background value appropriately set:

floatGridB->setGridClass(openvdb::GRID_LEVEL_SET);
// don't copy child nodes - we used cbeginValueAll to do this originally which also preserves the original sign
floatGridB->tree().root().setBackground(floatGridA->background(), /*update child nodes=*/false);

You can definitely achieve what you're trying to do, but it's a bit awkward - making sure that all intrinsic details of a valid level set are propagated to a Vector grid and back to a float grid will be fiddly.