0:00
/
0:00

Hello everyone. This is an update to my old tutorial about importing Realflow simulations to Lightwave 3D without the Realflow plugin. Lightwave Digital has fixed the alembic importer and finally, Lightwave can read alembic deformations and particles. However, there are still some issues.

This will be a fast tutorial, based on the previous one here, that stills valid, since I’m still using the conversion to openvdb method in Lightwave 2024. Why? Openvdb is extremely fast to read and to render, and the cache file is much smaller than the alembic one. Besides, the artist has extra options such as use the openvdb filter node to inflate, to erode, to smooth the mesh and to do other modifications.

I used the Hybrido Waterfall example that is shipped with Realflow.

My first attempt was unsuccessful: I exported the particles as alembic. Lightwave recognized the particles in the alembic file, but raised an “EXCEPTION ERROR”.

Lightwave recognized the alembic particles…
Lightwave recognized the alembic particles…
… but an error was raised.
… but an error was raised.

Then, the solution was to export as a Hybrido mesh vdb.

In doing so, Lightwave was able to correctly read the file cache.

Note the value of Vertex Cache Units. I put 100 because Realflow’s original scene scale.
Note the value of Vertex Cache Units. I put 100 because Realflow’s original scene scale.
The alembic cache in Lightwave.
The alembic cache in Lightwave.

However, there are caveats: the artist should use Realflow’s Stich alembic files tool to transform the file sequence in one single file (as I’ve shown in the first tutorial). Lightwave was able to read the original sequence, but wasn’t able to play the animation, as it appears to be stuck in an infinite loop in the first frame. Then, the solution was to use the stich tool.

Second, the playback of the simulation was extremely slow. At this point, I say that convert to openvdb is necessary, despite Lightwave now is able to read the alembic cache. What I did was to hide the alembic cache and create a null with an openvdb evaluator attached to it.

Hiding out the alembic cache.
Hiding out the alembic cache.
Creating the openvdb evaluator.
Creating the openvdb evaluator.

Then, I read the imported alembic cache using the Mesh to Volume node. I put the voxel size to 0.2 because the simulation is in meters, then the voxel size should be high. Larger scales require bigger voxel size; small scales require smaller voxel size. If the artist does not obey this rule, the computer will freeze, for sure. The reader can try 0.1 for this scale. The conversion will take a little bit longer but the artist will have a sdf mesh with more fine details. Just don’t go too low.

The openvdb evaluator was able to read many informations from the alembic cache.
The openvdb evaluator was able to read many informations from the alembic cache.
The alembic cache as openvdb sdf.
The alembic cache as openvdb sdf.

After that, I used the saver node to save the alembic cache as openvdb sequence, which was a very fast process.

Then, I disabled the alembic cache completely,

and used an OpenVDB info node to load the openvdb file sequence…

… and that’s it: very fast playback in Lightwave and just take a look at the size of the alembic cache (2,5 GB) and compare it to the size of the openvdb sequence (25,5 MB). Then, why to use the alembic cache if its slow and occupies a large amount of disc space?