miko3d

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?

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!

Hey Guys,

Any updates on this? are portals supported in 18.0 Karma?

The parameter for portals is there, in the dome Lop node, but i cant get any results.

Thanks