Tyler Britton avatar image
Tyler Britton asked

HtoA not using @path attribute when outputting materialX

We are exporting geometry (ABCs) and volumes (VDBs) along with a materialX file to later assign a shader in Gaffer using the export's path attribute.

Right now we have volumes working well, as I am assigning a @path attribute in Houdini which matches the volume's location with a "vdb" suffix added (example: s@path = "/obj/materialX/VDB/vdb"). This works great, as Gaffer will read the s@path and assign it the correct shader using the materialX file using the "geom" variable (example: geom="/obj/materialX/VDB/vdb").

However for geometry its a bit tricky. The when exporting packed geometry, the geom variable adds a numeric suffix at the end of inside the materialX file (example: geom="/obj/materialX/Geo/polygons:7124"). This is making creating a matching @path attribute hard as I am not sure how the numeric number is being created. When not packing the geometry, there is no numeric suffix in the materialX file (example: geom="/obj/materialX/Geo/polygons"). Furthermore, when I transfer the path attribute when I pack it on my pack node, I get a warning saying..

WARNING | /obj/materialX/Geo/polygons:7124: could not set STRING parameter "path"

... which makes me seem like it is somewhat picking up the @path attribute, even through I don't see it being used in the materialX file.

Am I doing this all wrong? I would ideally like to set my own @path attribute and then for the materialX file to use that. It looks like Arnold is somewhat recognizing it when exporting the materialX file, though I do not see it in the final .mtlx file. I would like to pack all my geometry as it just works better in Gaffer, however this is giving me the undesired numeric suffix.

Thanks in advance for the help.

htoahoudinihtoa arnold houdinimaterialx
10 |600 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 2.0 MiB each and 9.8 MiB total.

Julian Hodgson avatar image
Julian Hodgson answered

Hi Tyler,

When exporting a scene from HtoA, we have to make sure the nodes created from the packed primitives have unique names. Currently we do this using a numerical suffix.

You may be able to work around this by creating a custom attribute with the name you require. It sounds like you're trying to do that with the path attribute but it's not working though.

We could also look at the option of using the path attribute to name our nodes, if it's available, to make the names unique.

Do you have an example .hip file showing the issue so we can look into this please?



10 |600 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 2.0 MiB each and 9.8 MiB total.

Tyler Britton avatar image
Tyler Britton answered


sorry for the late response.

I was able to make a example scene file with a couple of attempts along with the mtlx file result for reference.

Just a recap from my first post in regards to the new example file...

Goal- To get the materialX file to source the prim attribute "path" in the output mtlx file

matExport_obj- I assign a shader to my geo and get the correct number of materialassigns (1 for each packed path), however the geom in the mtlx file is still pointing to the geo's operator path (geom="/obj/matXExport_obj/polygons:42281"). I would ideally want it to actually respect the "path" attribute and be something like geom="/cache_geo/Fx/0".

matXExport_sop- in this setup I assign the shader with a Material sop node and not at the object level. This would be most ideal as I would be able to assign it on a per path level. Still I get the same results as matExport_obj.

matXExport_sop_unpacked- Here I tried to assign the shader through a Material sop as before. I get the same results, except only 1 materialassign instead of the correct amount (ideally I would be working with packed data. Interestingly enough, I do not get this error that I got for the other ones...

00:00:00   987MB WARNING | /obj/matXExport_obj/polygons:44: could not set STRING parameter "path"

My only alternate solution would be before I export the mtlx file would be to move all my nodes to Houdini /obj/ paths that match their "path" prim attribute, (so the node's path would be something like "/obj/cache_geo/Fx/0" then remove the "/obj/" prefix in the mtlx file or upon processing in the next application. That seems a bit hacking though, and I would prefer to not have to do this.

Hopefully these files help. We are successfully importing mtlx files and converting them to Arnold shaders in Maya, Gaffer and Houdini, and just need to iron out this issue before we can export them from Houdini.

10 |600 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 2.0 MiB each and 9.8 MiB total.

Has anyone been able to take a look at this? We are trying to use this in production.

1 Like 1 ·

Support this topic

0 Likes 0 ·

@ Julian Hodgson

0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 2.0 MiB each and 9.8 MiB total.

Welcome to the Arnold Answers community.

This is the place for Arnold renderer users everywhere to ask and answer rendering questions, and share knowledge about using Arnold, Arnold plugins, workflows and developing tools with Arnold.

If you are a new user to Arnold Answers, please first check out our FAQ and User Guide for more information.

When posting questions, please be sure to select the appropriate Space for your Arnold plugin and include the plugin version you are using.

Please include images, scene and log files whenever possible as this helps the community answer your questions.

Instructions for generating full verbosity log files are available for MtoA, MaxtoA, C4DtoA, HtoA, KtoA, and Kick.

If you are looking for Arnold Documentation and Support please visit the Arnold Support site.

To try Arnold please visit the Arnold Trial page.

Bottom No panel present for this section.