Please or Register to create posts and topics.

Houdini | Add name attribute node with import

First of Prism is fantastic! Finally got around to use it.

I have a simple tweak to the import fbx function.
Before merging all the imported separate meshes in 'FBX_Objects'  add a 'name' node after the object merge (1st image). In the Name field put in this script to take the name of the object merge node upstream: `opinput(".", 0)`

This will create a primitive attribute with the name of the fbx geometry piece. It let's you work on each piece even though they are merged. It is very standard practice and integrates with so many other houdini nodes. The ROP fbx output will for example export each different name attribute as separate pieces.
Partition can create groups based on name (see 2nd image).
An official video describes the name attribute in length here:


And +1 for the Houdini feature:

  • [0118] Support for arbitrary rendering/export nodes | ability to set outputpath for export/render via rigthclick on parameter.

but maybe that comes with changing the State Manager to native Tasks nodes?

Uploaded files:
  • You need to login to have access to uploads.

I tried to implement it in the file /Prism/Plugins/Apps/Houdini/Scripts/StateManagerNodes/
Seems to work. Don't know if it'll mess anything else in Prism up?!?

I added the following lines to the importFBX function at line 396:

namenode = mergeGeo.createNode("name", "NameAttribute_" + )
namenode.setInput(0, objmerge)

Shown in context in the attached image. I changed the final line to hook into the namenode.
Edit: The screenshot was before I fixed to use single quotes on setting the namenode.parm("name1").set('`opinput(".",0)`'). The snippet of code has double quotation marks.

Would love to try and do proper commits to github when I get a better understanding of Prism.

Uploaded files:
  • You need to login to have access to uploads.

Hey @bastianls,

Thanks for providing an example for this. I've added it for the next update.

I'm well aware of the name attribute. In most cases I prefer to use alembics and the path attribute though, because it represents the full object hierarchy. Is there a particular reason why you prefer fbx?



Hi @RichardF

I'm on a game project and are generally dealing mostly with assets. Going between Houdini and Blender and export to Unity, in a folder outside prism of course. It is very useful to have Prism take care of versions and files, and updated import/exports.

Still developing the pipeline, but just about all exports into Unity is fbx.
Rigs goes from Blender through Houdini, where I plan to use KineFX to do skinning and back for animation. Also fbx. Last I heard alembic doesn't support skinned meshes and joints right?

But perhaps I should use alembic for models between Houdini and Blender? Even static ones.

I think there might be some support for bones in alembic too, but I agree for that kind of project .fbx is probably the better choice. Soon we will also have the .usd format, which supports skinned bones.

And I cannot wait. Blenders is slated for 2.93 right?

I want off Autodesks wild ride (:

There's already very basic support for USD in Blender. Not sure when Blender will support skinning in USD though.