Miknik made me aware of this issue today, so I had a look. And sorry that we missed this post. Please contact our support if you find an issue that doesn't get resolved here.
Anyway, the TL;DR version: With the next release (4 RC6) we will be ignoring the sampling rate of the extra UV coordinates, which causes all frames of the scene ParticleMesh_VDB01_Stitcher_10F.abc to load and render correctly.
Long explanation:
It seems that in the original single-frame export from RealFlow, the UV coordinates, vertex normals and speeds are stored twice. Once as attributes of the mesh and then again underneath the attribute group
arbGeomParams. This attribute group is usually used for additional attributes that are not necessarily supported by all Alembic readers. When the stitcher creates one Alembic file out of it, it gives all attributes under
arbGeomParams an incorrect sampling rate of 1fps while the residual mesh attributes have a sampling rate of 30fps.
When Octane loads the Alembic file, it loads the UV coordinates under
arbGeomParams as second UV coordinate set - because often extra UVs are provided in that group. Unfortunately it has the incorrect sampling rate and thus doesn't change during the first frames while the other attributes describing the mesh topology
do change. When Octane compiles the geometry it makes sure that all mesh data is consistent and detects the mismatch and filters the mesh out. This is why only the first frame is rendered. If you open the log window you will also notice an error message that the A_UVWS_2 indices are invalid.
To solve the issue we will be using not a time-based selector but a sample-based value selector in the Alembic reader (effectively ignoring the sampling rate) which solves this problem:
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
