Page MenuHome

Newer version of openVDB leads to crash
Closed, ResolvedPublic


System Information
CentOS, Nvidia GTX 1070

Blender Version
Broken: latest master and 2.79b

Short description of error
Houdini uses a newer version of openVDB 3.3.0, but blender supports 3.1.0 and it leads to crash. Here's the log:

unsupported VDB file format (expected version 223 or earlier, got version 224)
terminate called after throwing an instance of 'openvdb::v3_1_0::LookupError'
  what():  LookupError: Cannot find metadata blender/smoke/min_resolution
Aborted (core dumped)

I think it should simply ignore the version and not crash at least.
Or you could add support for the newer version of openVDB, if you have resources, of course.

Exact steps for others to reproduce the error
Open the attached blend file
Go to smoke cache -> file path and point to the vdb file directory (also attached)



Event Timeline

Yegor (Yegor) updated the task description. (Show Details)

@Yegor (Yegor) Your problem doesn't seem to have to do with OpenVDB versions, but with where the .vdb was created.

The OpenVDB cache expects a .vdb generated by Blender itself, and there isn't proper support yet for importing from other software. Looking at your .vdb file, it looks like it was created in Houdini, so it is missing some metadata Blender is expecting. It probably shouldn't crash just due to invalid .vdb files though (probably just throw an error message).

If you want to import the .vdb, in theory you can add the missing metadata yourself (like in T49835), but even with the Blender-specific metadata there is no gurantee that the volume will be exactly the same as it was in Houdini as we still lack full support for proper importing.

Oh, by the way, this is what renderman manual says: "Houdini 16 uses OpenVDB 3.3.0 but RenderMan currently supports OpenVDB 3.1.0.
You can ignore the message: "unsupported VDB file format (expected version 223 or earlier, got version 224)". The volume still renders correctly."

This is quite similar to what we have in blender. Can we just ignore the version and skip the metadata blender expecting?

Brecht Van Lommel (brecht) triaged this task as Confirmed, Medium priority.

To fix this bug, we should add exception handling somewhere so we can report an error instead of crashing.

Later we can also consider upgrading to a newer OpenVDB version.

Hm, like @Geraldine Chua (gschua) said, blenders vdb import is not really meant to use vdbs generated in other software (yet).

Whilst reading files written by other software should be possible, as long as the other software exports metadatas which would make sense in Blender, reading such files is not officially supported since that to properly support external .vdb files we would need a more open minded solver, or possibly even some volume primitive. Therefore I'm archiving this report.

For I/O failures we have a few cases:

  • ...
  • metadatas can throw too, e.g. if two metadatas have the same name but not the same type, or if no metadata is found for the given name (these likely need to be handled too)
  • ...

Metadata reading happens here and it seems blender is actually pretty dependent on it

Would be nice to not crash but I'm leaving this up to @Kévin Dietrich (kevindietrich) to close (or resolve)

We upgraded OpenVDB to 5.1.0 since this was reported, should work fine now.