Houdini
Poly Haven in Houdini, in both contexts
Blender gets an official addon. Houdini gets a ZIP, and then a decision — because the same texture set is built two different ways depending on whether you are in /obj or /stage, and three or four more ways depending on your renderer.
Everywhere else, "set up a PBR material" has one answer per renderer. In Houdini it has one answer per renderer per context, and the two contexts do not share materials. Add the fact that Houdini artists change renderers more often than most, and the combinatorics are why this particular chore never becomes muscle memory.
Pick your context before you unzip anything
/obj — Material Network
Use when: quick look-dev, self-contained scenes, anything that will render straight out of Houdini without a USD stage.
Material lives in: a matnet containing a Redshift, Arnold or Principled Shader builder. Texture nodes plug into the shader directly and the material is assigned via a Material SOP or the object's material parameter.
HDRI via: an Environment Light with the HDRI in its texture parameter.
/stage — Solaris / LOPs
Use when: USD workflows, shot assembly, anything travelling to another department, and any scene where the material should live with the asset rather than the file.
Material lives in: a Material Library LOP holding a MaterialX subnet
(mtlxstandard_surface) or a renderer-specific builder, bound with an Assign Material LOP.
HDRI via: a Dome Light LOP with the HDRI as its texture file.
Building the MaterialX network
Worth learning even if you normally use Redshift, because a MaterialX network is portable in a way that a renderer-specific one is not. Inside a Material Library LOP, create a MaterialX subnet and wire it like this:
| Map | Node chain | Input on mtlxstandard_surface | Colour space |
|---|---|---|---|
| _diff | mtlximage | base_color | srgb_texture |
| _rough | mtlximage | specular_roughness | raw |
| _metal | mtlximage | metalness | raw |
| _nor_gl | mtlximage → mtlxnormalmap | normal | raw |
| _disp | mtlximage → mtlxdisplacement | displacement output | raw |
Then bind it with an Assign Material LOP. The colour space column is set on each mtlximage
node's file parameter — one map as srgb_texture, the rest as raw, exactly the
same rule as everywhere else and exactly as easy to forget.
For Redshift and Arnold instead
The structure is identical, the node names are not. In a Redshift material builder you are using texture
sampler nodes into a Redshift Standard Material with a Bump Map node handling the normal; with HtoA you
are in an Arnold material builder using image nodes into an aiStandardSurface with a
normal_map node. Displacement is the part that differs most: each renderer wants it bound in
its own way, and each has its own scale convention, so a displacement height that looks right in Karma
will not look right in Redshift.
Absolute paths are a farm bug waiting to happen
Drag a Poly Haven texture into a file parameter and Houdini records wherever it happens to be. That works perfectly until the scene is opened by anyone or anything that is not your workstation.
✗ C:/Users/fabian/Downloads/polyhaven/plaster_diff_4k.jpg
breaks on the farm, on a colleague's box, after any reorganise
✓ $HIP/tex/plaster_diff_4k.jpg
travels with the scene file
✓ $JOB/lib/polyhaven/plaster_diff_4k.jpg
travels with the job, shared library stays sharedThis matters more in Houdini than in other applications because Houdini scenes genuinely do travel — to the farm, into a wedge, through a pipeline. It is also one of those conventions that is trivial to follow from the start and miserable to retrofit across two hundred file parameters.
My own software from here. Everything above is free and complete, and in Houdini specifically a home-grown Python shelf tool is a very reasonable alternative. What follows is the thing I sell.
What the plugin handles for you
Kiosk reaches Houdini through a shelf tool and the Tab menu, with the Poly Haven catalogue browsable in the same window as your own folders. The three decisions this page has been describing — context, renderer, path style — are the three things it resolves without asking.
- Context detection. It checks whether you are working in
/objor/stageand imports the way that context expects — geometry into SOPs, USD-appropriate setups in Solaris. - Renderer-correct networks. Karma, Arnold, Redshift and RenderMan each get their own graph built properly, including the normal conversion node and the displacement binding that renderer wants.
- Relative paths by default. File references are written Houdini-style with
$HIPand$JOB, so scenes stay portable across machines and render farms without a cleanup pass. - Not just textures. VDB volumes, geometry caches and your own scanned assets sit in the same library as the Poly Haven content, which for Houdini work is usually the bigger half of the library.
Questions
Is there a Poly Haven addon for Houdini?
No. Poly Haven maintains an official addon for Blender only, and Houdini is arguably the application where its absence is felt most — not because the setup is harder, but because Houdini artists tend to work across more renderers and two different contexts, so there is more to rebuild each time.
Should I build the material in /obj or /stage?
It depends on what the scene is for. /obj with a Material Network is the shorter path for quick look-dev and for scenes that stay inside Houdini. /stage with Solaris is the right answer when the result is going to be a USD layer, when you are working with a wider pipeline, or when you want the material to travel with the asset. The important thing is that they are not interchangeable: a material built in /obj is not automatically available to a LOP network, and this trips up a lot of people moving to Solaris.
What is the MaterialX equivalent of a Principled BSDF?
mtlxstandard_surface. Inside a MaterialX subnet you feed it with mtlximage nodes, convert normals with mtlxnormalmap, and drive displacement through mtlxdisplacement into the displacement output of the subnet. Karma renders MaterialX natively, and the same network is portable to other MaterialX-aware renderers, which is a meaningful advantage over renderer-specific graphs.
Why should I use $HIP or $JOB in texture paths?
Because absolute paths break the moment the scene leaves your machine. A path such as C:/Users/you/Downloads/textures is fine until the file hits a render farm, a colleague, or your own machine after a drive letter change. Houdini variables such as $HIP and $JOB keep paths relative to the scene file or the job root, which is the difference between a scene that renders on the farm and one that renders as grey.
Which normal map variant does Houdini want?
nor_gl, the OpenGL convention. Karma, Redshift and Arnold in Houdini all expect green-up tangent-space normals. The nor_dx variant has the green channel inverted for DirectX-convention engines; using it produces lighting that looks subtly inverted rather than obviously broken, which is why it survives review so often.
Can this be automated?
Yes, and Houdini is the easiest DCC to automate it in — a Python shelf tool that reads a folder and builds a matnet or a Material Library LOP is very achievable. Third-party asset managers also do it; Kiosk, which I develop, detects whether you are in /obj or /stage and writes $HIP-relative paths.
Related: the same walkthrough for Maya and Cinema 4D, and the cross-library PBR suffix cheat sheet.
The free edition includes the Houdini plugin, material networks for Karma, Arnold, Redshift and RenderMan, relative-path file references, and the Poly Haven library built into the browser.
Download the free edition