Ethan Estrada

Glad to assist.

The help for the “Export Deforms as Vertex Caches” toggle isn't very, well, helpful. It makes it sound like it is just for exporting animation instead of exporting the skinning data of a rig, but really it is for exporting any SOP level deformation as a point cache. I think it is off by default for the sake of efficiency.

hopbin9
Is there a reason why Houdini doesn't use Python 3.x?

My understanding is because most studios' pipelines are glued together with python scripts that were written years ago and converting python scripts from 2.x to 3.x can be more than trivial. It is the same reason that Maya's shipped python version is a similar one to Houdini's, and why I'm pretty sure PRMan's python bindings only work with 2.x, etc.. Once larger studios move to 3.x, so will Houdini, along with every other major CG package.

If you write your python scripts intelligently by never using deprecated features and using “from __future__ import (replacement feature X)” as much as possible, your scripts should be fairly easy to convert when the time comes that 3.x is supported.

Ok. I have had similar situations before and it is always one silly toggle that I forget to check. I think it is turning on “Export Deforms as Vertex Caches” and/or “Detect Constant Point Count Dynamic Objects”. With the first one on your FBX should also export a folder called “fpc” that will contain the point cache. Since imported RBD animation happens at the geometry level, it is technically deformation, not transformation, thus the point cache.

Also, be sure to export the FBX in ASCII. This will only affect the “.fbx” file. That way it is human readable and you can trouble shoot more easily.

Also, is your simulation being imported into a geometry object or do you only have an object level DOPnet? Trying to export geometry from a DOPnet directly into a scene format like FBX or alembic sometimes does weird things.