Hi all,

I'm encountering extremely long compilation times on XPU when making updates to MaterialX nodes. To clarify, this issue is not related to the initial "time to first pixel" or GPU pre-compilation, but rather occurs during interactive tweaking of materials.

My material network primarily consists of layered textures—mostly HEX triplanars and mtlxmix nodes—feeding into an mtlxStandardSurface. While cached nodes update responsively, introducing new nodes (e.g., adding a new mix layer or swizzling channels) causes Houdini to freeze for 10–15 minutes, which makes the workflow nearly unworkable.

It's worth noting that the same setup performs as expected on CPU (Embree), with no significant delays during material edits.

Has anyone experienced similar behaviour or found workarounds to reduce the recompilation time on XPU for MaterialX networks?

Thanks in advance!

miko3d
Has anyone experienced similar behaviour or found workarounds to reduce the recompilation time on XPU for MaterialX networks?

unfortunately, changing the shader graph topology will cause a compilation for Optix. I've not seen any take that long though. Does your graph have thousands of nodes?

jsmack

miko3d
Has anyone experienced similar behaviour or found workarounds to reduce the recompilation time on XPU for MaterialX networks?

unfortunately, changing the shader graph topology will cause a compilation for Optix. I've not seen any take that long though. Does your graph have thousands of nodes?

Not thousands of nodes, but the graph is definitely becoming quite complex. I'm currently building a modular, texture-layered terrain shader using hex-based triplanar projections, MtlXmix, and various mask setups. I've noticed that compilation times tend to increase in a non-linear—almost exponential—manner as the network grows, which has been quite frustrating.

It would be extremely helpful to know which specific nodes contribute most to longer compile times, as that would allow me to optimize the network more strategically.

PS: Are there any (near future) plans to remove the current XPU limitation of only mixing max 2 shaders via the mtlxMix node?

Possibly related: https://www.sidefx.com/forum/topic/88469/ [www.sidefx.com]

Since i dont see your nodegraph i can only guess whats causing the slow compilation.
Hextile and triplanar projection are quite expensive, so if you build multiple texturesets like this it can exponentially slow down your compilationtimes, at least as far as i experienced it with mtlx and xpu.

Also whats always a potential bottleneck for xpu is using displacment. if you are using it, turn it off as long as you are still making big changes on runtime.

Just a thought - the issue I had in the link above was that the python parameters on the nodes (in our case VRay) were slow, and given the scale of each material network they would take a long time to update (even in manual mode). Thus, the compilation of the shaders was also slow. A way to make it a bit easier was to have a single Material Library node for the material you are working on, to cut down the number of nodes that require evaluation (and perhaps compilation).