EC - OpenVBD

As of version 7.1.2., RealFlow provides support from DreamWorks Animation's “OpenVDB” format. OpenVDB is able to store volumetric data inside an effective hierarchical sparse data structure. Together with Sony Imagework's Field3D format and Alembic I/O, which are both supported by RealFlow, artists have direct access to the industry's most important formats. The format's native key features include, amongst others:

  • Fast access to voxels even in very large datasets

  • Mathematical transformations

  • Geometric transformations

  • Filters

The OpenVDB C++ library also contains functions and tools to show and manipulate level sets, iso-surfaces, and convert volumes to adaptive meshes, point clouds, or Signed Distance Fields. Particles with position and radius data can also be turned into iso-surfaces. With this method, artists will get a fast initial surface from fluids or other particle sources.

In RealFlow it is possible to load and visualize OpenVDB data with easy-to-use Graphs nodes. These nodes allow you to display volumetric data from OpenVDB files and extract iso-surfaces. It is even possible to save these surfaces as meshes. The appropriate graphs can be downloaded here, directly from RealFlow's technical documentation, or our resources page:

http://www.realflow.com/resources/

If you want to learn more about OpenVDB or download the source code, please visit:

http://www.openvdb.org

OpenVDB and RealFlow

As mentioned above, RealFlow has some built-in tools for working with VDB files, for example the creation of Signed Distance Fields or the extraction of iso-surfaces (please see below for a definition of iso-surfaces and how to obtain this feature with RealFlow's Graphs).

The OpenVDB format option is available for Hybrido domains from RealFlow's “Export Central”. Simply check if you want to use “OpenVDB” from the “HY_Domain's” tree. There, you also have the possibility of including/excluding certain fields individually. OpenVDB offers compression and can be used instead of RealFlow's GFC format. This also means that it is possible to resume simulations from VDB files, and even secondary elements can be created from this data. If you want to use VDB instead of GFC, please make sure that the following fields are active:

  • fluid_distance

  • fluid_velocity

  • fluid_acceleration

  • particle_count_per_cell

  • label

If these resources are inactive, RealFlow will not be able to resume from interrupted simulations. Please also bear in mind that exporting VDB files is slower than writing GFC sequences, because RealFlow has to perform internal conversions to translate the internal representation of fields into a VDB-compatible format.

At the moment, RealFlow's implementation of OpenVDB is tailored to Houdini's axis setup. If you want to make use of the OpenVDB library in your own projects and load field data from RealFlow, please take a look at the following tables:

 

Field name

OpenVDB type

solid_distance

FloatGrid

fluid_distance

FloatGrid

solid_velocity

VectorGrid

fluid_velocity

VectorGrid

fluid_acceleration

VectorGrid

particle_count_per_cell

Int32Grid

label

Int32Grid

 

This table shows you the metadata written by RealFlow to the OpenVDB files:

 

Metadata name

Metadata type

Description

cell_size

FloatMetadata

The cell size.

tile_granularity

Int32Metadata

This number to the cube is the number of cells per tile.

n_x

Int32Metadata

Number of cells in the X axis.

n_y

Int32Metadata

Number of cells in the Y axis.

n_z

Int32Metadata

Number of cells in the Z axis.

memory_type

Int32Metadata

Type of field, 0 -> dense, 1 -> sparse

position

Vec3SMetadata

The position in world space of the minimum corner of the field box.

fluid_distance_bandwidth

FloatMetadata

The bandwidth around the fluid surface where the fluid SDF is defined. This number is in world space.

solid_distance_bandwith

FloatMetadata

The bandwidth around the solid surface where the fluid SDF is defined. This number is in world space.

 

Other node types, for example mist, do not support OpenVDB.

Working with Fields

In VDB files, objects are voxelized and do not contain any mesh data, polygons or vertices. In any case it is possible to use the stored voxel information to reconstruct the original surfaces. This is done by extracting iso-surfaces from the voxels. the Greek prefix “iso” means “equal” or “the same” and here, the term iso-surface describes all voxels with exactly the same distance from a certain point. When these points are visualized you will see that they are all located on a surface.

If you have read the “HyFLIP – Volumes and Distance Fields” then you have also heard about “Signed Distance Fields”. These fields are used to determine whether a point (or particle) is inside or outside an object's surface. Points outside the surface have a positive offset from the surface, particles inside wear a negative sign. If the distance is 0, then the point is directly located on the surface. With this information it is possible to create a so-called “Signed Distance Field” (SDF) and look for all voxels with a distance of 0 to reconstruct the surface itself. Once the field has been created, the process of finding the iso-points and the associated surface is very fast.

The same applies for pure particle data and each particle position can be assigned to a certain level to reconstruct a surface. Another interesting approach is to store a particle's radius with its position. The radius is used to put a sphere around a particle and create very fast mesh previews. If there is an additional velocity channel, then this value can be taken into account to calculate the sphere's deformation, and achieve a very realistic effect.

The concept described here is exactly the same as with objects inside RealFlow: our fluid simulator creates a distance field around an object. This information helps Hybrido to determine whether a fluid particle is inside or outside the colliding object. The distance field can be adjusted manually to avoid leaking or particles trapped inside objects – this is done with the object's “Surface width” parameter under “Volume”. When the distance field is extended (= positive values) then you will also observe that the surface becomes smoother.

Working with OpenVDB Data

RealFlow provides dedicated Graphs nodes and converters to load, save, and visualize voxel data from OpenVDB files directly inside the viewport. On the OpenVDB website you will find a couple of files to download:

http://www.openvdb.org/download/ (“Download sample models”)

Let's use a complex shape for this example. Please download the file “Smoke 1” from the page above. The file weighs in at 2 MB and has a voxel resolution of 111 x 222 x 112. We want RealFlow to create a mesh from the smoke cloud, visualize it in the viewport, and finally save it as an OBJ file.

The VDB file can be extracted/stored anywhere on your hard disk. Then, download the graphs file attached directly below. Open RealFlow's “Batch Graph” editor from the “Layout” menu and load graph file. Please take a look at the graph's notes, because they contain a description of how to use the “script”.

 

Please click on the image for a full-size view.

 

If you do not want to save the mesh created from the field, just remove the connection from the “MeshSave” node to the “Evaluator”. The same applies for the “DisplayMesh” and “DisplayFieldScalar” nodes. As long as all branches of the tree are evaluated they will be executed. Here is a mesh created from the "Smoke 1" file – the creation time was approximately 2 seconds on a MacPro "Early 2009".

 

 

To run the graph, please click on the “Execute graph” button in the editor's icon bar.

The “DisplayFieldScalar” node is responsible for the field's visualization in the viewport and provides settings to control which slice of the VDB's dataset should be shown (x/y/z slice). As you can see, the default value is 0.5. Since it is not possible to use absolute values here, the size of the voxel data set ranges between 0 and 1. Therefore, a value of 0.5 represents the midpoint, or better: middle slice. By using values greater than 0 and smaller than 1 you can shift the slices easily.

The size of the points, representing the voxel data, is changed with “point size”. Higher values create a more opaque effect.

 

The smoke cloud with "point size" = 1.0 and "point size" = 10.0.

 

Finally, there is the “FieldRealMesher” node. This is a mature meshing tool to extract the iso-surface from the voxel data. To finally get a surface, “isovalue” must be (at least slightly) greater than 0. This mesh can be saved in OBJ, ABC, or BIN format.

Extracting Field Data

Similar to the process of visualizing voxel data in RealFlow, it is also possible to create and extract field data from native or imported objects, and store them in VDB format. Again, this is done with RealFlow's Graphs system. Create a basic scene with an object of your choice, and open the “Batch Graph” window again.

Download the graph from the link below and copy/paste/load it into the editor. The canvas should now look like this:

 

Please click on the image for a full-size view.

 

Again, all nodes contain comments and descriptions. The object's field is displayed in the viewport and saved as an OpenVDB file. This file can be re-imported with the previously discussed graph or loaded into Houdini (or any other application that supports OpenVDB ). To store a VDB file, simply execute the graph. If the object's topology changes over time, for example with meshes, then it is possible to use this graph inside the “Simulation Flow” window and execute it at every frame to write out a series of VDB files.

Notes on RealFlow's OpenVDB Implementation

As you have read in the previous chapters, RealFlow is capable of writing and reading OpenVDB files though graph nodes. At the moment, the following grid formats are supported:

  • FloatGrid

  • DoubleGrid

  • VectorGrid

 In RealFlow, fields are always aligned to the global axis system and therefore, all transformations of the OpenVDB grids are simply ignored by RealFlow to avoid problems. Another important fact is that RealFlow only uses fixed cell sizes. Non-uniform cell sizes and transformations are not considered.