One of the features of working in Houdini is that complex tasks are easy to do, while simple tasks can be difficult. I’ve noticed that many people online have encountered issues with exporting 3D objects from Houdini to game engines while preserving the hierarchy of game objects/transforms and pivots. Well, I faced this issue too, and the Houdini forum was very helpful. Let me show you my setup and share it with you! (If you know a more convenient setup, I’d be happy if you shared it!)
Let’s start with the following setup. We have a 3D model: the body of a small device, which includes a screen, a knob, and a switch button. All elements are placed on the device body using MatchSize nodes, which ensure the precise positioning of all elements on the front panel of the device. Houdini allows us to create fully parametric objects, but in this tutorial, we will focus on transferring the 3D model to the Unity engine and adjusting the pivots.
Here is the initial setup.
One of the first features of Houdini that is difficult to get used to after working with 3ds Max, Blender, and other 3D graphics editors is that in this setup, there are no pivots/transforms and hierarchy as traditionally understood. We see a set of objects created with certain settings and then positioned relative to each other, but this does not constitute a hierarchy. What happens if you export this model as-is to Unity? You get a single solid mesh. (For export, we use the ROP FBX OUTPUT node).
This clearly does not satisfy us. What if we want the control elements to be separate and physically distinct objects? Exporting objects separately won’t help either, as we would have to manually assemble the entire hierarchy in the engine, which we’d like to avoid. So, what should we do? If the pivots of the objects are not important to us, we can use the Build Hierarchy from Path Attribute property.
We will define these paths for each part. To do this, you can add an Attribute Create before each model, select string as the data type, and specify the paths as follows:
- for the body:
root/ - for the button:
root/button - for the screen:
root/screen - for the knob:
root/knob
The result of exporting such a hierarchy will be the device body as a separate object, with the knob, screen, and button attached to it as child objects. This is better, but still not ideal. The object pivots are at zero. The first thing that comes to mind is to use MergePacked or Pack, and in them, select the pivot as the centroid. But what if we want full control over the setup?
For this, I will do the following: we will create pivots, prepare the rig, and export all this to Unity.
Let’s start with the pivots. We will create points where we want to attach our elements. The points will be placed at the center of the bases of the control elements using MatchSize. Then we will combine the points, which will serve as our pivots, with the 3D objects themselves, but this time using the mergePacked node (don’t forget to select Pivot as Centroid in the settings). Thus, we have the body, 3 pivots, and 3 control elements.
This is already quite good, we just need to add the hierarchy and export everything. Let’s prepare the rig:
What’s happening here:
Using RigDoctor and RigStashPose, we initialize the transformation matrices and set them as point attributes.
We transfer the attribute name of the detail to the point from the model names.
Using AttachCaptureGeo and CapturePackedGeo, we prepare the joints and geometry for the rig.
(Don’t worry, below I provide a file with the digital asset for your convenience.)
We just need to set up the hierarchy and export everything.
Add a ParentJoints node and define the following hierarchy:
- button inside the button pivot
- knob inside the knob pivot
- screen inside the screen pivot
- all pivots inside the device body
Next, add a Blast node to remove all unnecessary geometry (the pivots are points, but we don’t need them; we need an empty transform).
And to save all this setup, we need to use FBX Character Output.
Let’s see what we got in Unity.
Now each object is inside its pivot, and the pivot is inside the root object — the device body.
The config itself looks quite cumbersome, doesn’t it? This is because, unlike typical 3D graphics editors where there is a certain hierarchy of objects, here each element is an independent 3D object, and we have to create this hierarchy ourselves. However, once we’ve done it, we can save the corresponding node and reuse it. This approach allows us to experiment with the object hierarchy as much as we want, creating various configs for different purposes.
Need a solid dummy object? Don’t create a hierarchy at all. Need to make the screen part of the object? Just remove part of the hierarchy. And all this is completely controllable at every stage, allowing for preset templates that can be exported to other FBX files. Additionally, if we suddenly need to create meshes for object collisions, we can add them to the hierarchy at any modeling stage and then, at the Unity exporter level, process the relevant objects and create mesh colliders, etc.
Let’s refine this config, pack everything related to FBX export into a small Digital Asset, so we never have to deal with this headache again:
Thus, we can fully control the pivots when exporting to other engines in FBX format. Despite this being a Character Exporter, there is no need to worry that the output will have SkinnedMeshRenderers, because if the bone weights are all 1, Houdini optimizes it and exports it as a regular mesh. Therefore, there are no risks to the geometry.
Below, I provide all the test assets and the scene (since I used proprietary models in the example, all 3D models have been replaced with simplified ones, but the essence remains the same). Included are 3 Digital Assets: for creating pivots, preparing for the rig, and exporting the model to FBX.
Thank you for reading, and may your pivots always be where you want them to be!
https://drive.google.com/file/d/1dpCIN3VTlniNAPwFcS6dT5mdrKndfIe3/view?usp=sharing