Share

write_OpenVDB

This node writes Bifrost points objects and volumes to an OpenVDB file.

Inputs

points

The Bifrost points objects to write.

volumes

The Bifrost volumes to write.

enable

If true, enables writing of files. Otherwise, node works as a passthrough.

filename

The file name. Use # to include the input frame number. The number of occurences of # determines the amount of padding. For example, file####.vdb resolves to file0001.vdb, file0002.vdb, and so on.

directory

The directory.

frame

The frame number. You can connect the frame output of a time node to a to_long node, and then connect the result here.

overwrite

If true, overwrites existing files.

create_directories

If true, creates output directory hierarchy if it doesn't exist.

properties

A space-delimited list of properties to write. Use * (asterisk) to specify all properties. See also Limitations below.

resolution_rounding

Controls the resolution rounding used when converting from Bifrost volumes to OpenVDB grids. Since Bifrost has more levels in its adaptive data structure than OpenVDB grids, voxel properties cannot be stored without conversion. In case of a mismatch you can choose to round the resolution up and avoid loss of resolution at the cost of higher resolution and thus larger file sizes. You can also choose to round the resolution down which saves space at the cost of some loss in resolution. As a compromise, you can opt to always round to the nearest possible resolution in OpenVDB.

As a concrete example, consider a Bifrost volume with voxels with a voxel width of two. If you choose to "round up", these voxels will be stored as a 2x2x2 block of voxels in the OpenVDB grid. If you instead choose to "round down", the next level in the OpenVDB grid will be chosen, in this case that would be voxels with a voxel width of eight, and you would effectively have your resolution divided by four. Finally, in "nearest mode" a voxel width of two would (still) be "rounded up" and stored as a 2x2x2 block, while a voxel width of four would instead be "rounded down".

Outputs

out_points

Passthrough of the input point clouds.

out_volumes

Passthrough of the input volumes.

success

True, if file was written successfully.

file_path

The full path of the written file.

Limitations

For volumes, the following subset of the OpenVDB standard types are supported: float, double, int, long, int3, float3 and double3. The types boolean and string are not supported.

For points objects, per-point properties of all OpenVDB standard types are supported. This includes boolean, float, double, int, long, string, int3, float3 and double3.

In addition for points objects, global properties are supported — these are properties with a single data value for the whole object, rather than a value per point. For example, this can be useful for storing the object transform. Global properties are stored as metadata in the OpenVDB grid. All of the standard OpenVDB types for metadata are supported: bool, float, double, int32, int64, string, int2, float2, double2, int3, float3, double3, float4x4 and doubl4x4.

Note that global properties are not supported for volumes.

Was this information helpful?