Page MenuHome

Animated ABC Won't Collide With Fluid Simulation
Closed, ArchivedPublic


Blender 2.79

It's pretty simple to recreate, Import an animated ABC mesh and try to use it as a collision object. The fluid system ignores the the mesh completely, even when placed in Triangle MESH mode.

NOTE: The .ABC file I am using is the CRAG ROBOT Test Geometry that I exported from Houdini. It is a 420 frame animation that weighs in around 2GB. (not sure if your system can handle that size of an upload)

I tried to create a companion python script that would fetch the data block from the ABC object and assign it to standard mesh, but only fetches the first frame from the animation and produces the following error on all other frames.

AbcObjectReader::xform(): unable to find IXform for Alembic object '/OUT_CRAG'

My guess is the data block is no being updated for the .ABC object, when the frame changes.

Here is my basic transfer mesh data block that runs in a frame change.

def processFrameChange(scene):
    # Hardcode names, for now.
    abc_source_name = "OUT_CRAG"  #Name of ABC object to mirror.
    abc_companion_name = "%s_collider" % abc_source_name
    ob_abc_source =
    if ob_abc_source != None:
        #We found the source, fetch the companion.
        ob_companion =
        if ob_companion == None:
            #Object does not exist, create it.
            me_new_mesh = returnTriangleMesh("me_triangle")     #Create smallest possible temp mesh.
            ob_companion =, me_new_mesh) 
        #Make sure it's linked to the scene.
            #Probalby already linked.
            pass =
        print("No abc source found [%s]." % abc_source_name)



Event Timeline

Philipp Oeser (lichtwerk) claimed this task.

This is because the alembic modifier cannot be placed above the fluidsim modifier.
(this would be needed in order for the fluidsim to pick the changes up)

You should get a message like

Cannot move above a modifier requiring original data

I think the reason is that .abc [in contrast to .mdd or .pc2] can have changing vertex count across frames, which apparently fluidsim obstacles cant handle...
If you know your vertex count is not changing, try caching in .mdd or .pc2 instead.
Then use the Mesh Cache modifier (not the Mesh Sequence Cache modifier) to load the cache.
The Mesh Cache modifier can indeed be place above the fluidsim modifier, thus this can be used as an (deformation-animated) obstacle.

Long story short: this is a known limitation [which might be lifted with upcoming mantaflow integration, but not sure...].
And there is a workaround that would work in most cases (non-changing vertex count).

Will archive this report, feel free to comment again if issues persist...

So why can't I fetch the mesh data block, from the .abc animation, in a frame change?
Shouldn't the Mesh Sequence Cache modifier correctly present the current mesh data block, to the API, for the frame it is displaying?
Why does the frame change code fail? =
NOTE: I have attached a shortened version of the .ABC file that I am using, for others to test with.

Havent actually checked it, and it feels like swapping mesh datablocks in a framechange handler is not the best solution, but would it help getting the evaluated object?

eval_ob_abc_source = bpy.context.depsgraph.objects.get(, None)