Nanite Assemblies & Unreal Export
This page is for when an export runs but the result is wrong. For the normal import workflow, see Working with Assemblies in Unreal. For wind authoring, see Wind for Unreal.
Before you export
Most export problems trace back to the input, not the export node.
- The input must come from a Simulate. The rig and skin weights are produced at simulate time. If you export geometry that didn't pass through a Simulate, you get the "Missing BoneCapture" warning and an unrigged result. Re-derive from a Simulate before exporting.
- The assembly needs clusters. The exporter works on a tree that has assembly clusters; a bare grow/simulate with nothing to assemble has nothing to export. Confirm your assembly decoration is producing clusters upstream.
- Use the navigation shim to get into Solaris. The SOP-side Export Unreal Nanite Assembly node has a single Enter Solaris button that drops you onto the LOP create node where the actual export lives.
Export-time errors
AttributeError: 'module' object has no attribute 'fillmaterials'. The export node's internal code is out of sync, usually a node carried over from an older build, or one that was promoted/wrapped so its callback can't find the function. Recreate the export node from the current Natsura build rather than reusing an old one, and re-run Auto-fill Materials.AttributeError: 'NoneType' object has no attribute 'geometry'(during the wind JSON write). The export has no geometry to read: the geometry input is empty or disconnected. Confirm thegeometryinput is wired to a valid Simulate result before exporting.- "Unable to cook test input" on a resource/decoration node. The upstream assembly resource or decoration has no valid input. Wire it correctly upstream; an empty assembly resource should not be used directly as a decorator.
Materials don't come across
Materials are the most-reported export problem. The export authors materials two ways: the materials multiparm (one row per material) and the Auto-fill Materials button, which walks the assembly's display geometry and reads each piece's shop_materialpath.
- Run Auto-fill Materials on the export node. If the multiparm is empty, no materials were bound upstream; assign materials on the Houdini side first.
- Check each row has a material node (
matnode), a USD path (matpath), and a geometry target (geopath). Empty rows export geometry with no material binding. - In Unreal you may see fewer material slots than in the Houdini viewport (e.g. trunk + branches show as separate materials in Solaris but arrive as one slot). Confirm the per-piece
shop_materialpathstrings are distinct upstream; pieces sharing a path collapse to one slot. - USD exports with no material IDs point to the same root cause: nothing was bound for Auto-fill to find.
Branches missing, exploded, or at the wrong place
- All instances import at the world origin (tree collapses to a point). The most common version of the bind-transform issue, and it has a reliable workaround on the Unreal side. Open the imported Skeletal Mesh editor, and in the Asset Details panel search Preserve, set Shape Preservation to Voxelize, and Apply Changes. The instances then move off the origin into their authored positions. This requires Nanite Foliage to be enabled in Project Settings (voxelisation is the path that resolves the transforms). (Confirmed in the Natsura 101 series; root cause, identity bind-transforms on instance-only joints, is still being addressed on the export side.)
- Only the base/trunk exports; no branches in the USD. The branch geometry is instance-bound to joints that can land at the world origin on import (an identity bind-transform issue on instance-only joints). This is a known fragility being worked on. Try the Voxelize workaround above first; if branches are genuinely absent from the USD rather than collapsed, check whether they're coming through as instances and report the case with a reproducer.
- The mesh "explodes" in Unreal when the trunk and main branches are both in the Skeleton Group. Splitting the skeleton group so the trunk and main branches are not combined avoids the blow-up. (Confirm current guidance against your build.)
- The skeleton imports differently in Unreal than it looks in Houdini. This is usually an up-axis / units mismatch (Houdini is Y-up/metres, Unreal is Z-up/cm) or the bind-transform issue above. Verify your USD import settings match the export's stage metadata.
All my assemblies are named the same
Every export ships with a generic root prim name unless you change it, so two assemblies collide in the same Unreal project / USD stage. Set the name (and the root prim path) per export so each asset is uniquely named before you save to disk.
Wind looks wrong or drops bones
- The wind JSON is missing a lot of bones after "Simplify Tree Rig & Skin". Simplifying the rig reduces the joint set the wind data is authored against. Author/transfer wind on the simplified rig (match by the stable wind id, not by joint name), or simplify before authoring wind so the two stay consistent.
- Wind movement doesn't look right in Unreal. Confirm the
wind.jsonsidecar that shipped next to the USD is the one wired into Unreal's wind system, and that the layers in it match what you authored in Wind Config. See Wind for Unreal.
Importing into Unreal
- Static mesh importer rejects the geometry. Almost always non-manifold decoration meshes; make decorations produce watertight, manifold output before re-exporting.
- Large imports are slow or freeze (seen on UE 5.7). The static-mesh importer is unstable in the large-volume, high-resolution regime. Keep individual exports under roughly 56,000 instances; split large forests across multiple exports.
- Can't use an exported Static (non-skeletal) Nanite assembly USD. Confirm you exported with the assembly type set to Static Mesh for a static target; the skeletal and static paths produce different USD.
- Extra props (e.g. berries imported from another package) disappear when entering Solaris. Props that aren't part of the Natsura assembly aren't carried through the export. Bring them in as part of the assembly upstream, or add them on the Unreal side.
Related
- Working with Assemblies in Unreal, the normal import workflow.
- Wind for Unreal, authoring wind layers.
- Assemblies (overview), building the decoration that gets exported.
- Troubleshooting, general Natsura troubleshooting.
Working with Assemblies in Unreal
How to bring Natsura's Nanite Skeletal Assembly exports into Unreal: import, materials, instancing, and wind hook-up.
Extend Natsura
Natsura is built to be opened up and extended. Author your own decorations, write custom effectors and wrangles, define custom maps, and compose your own tools out of the core verbs.