protean

Hi,

I've stumbled upon this thread and looked into the example. There's an issue with the geo path in the swirl_mesh_topology usd in that it is a full path. In the swirl_mesh.usda they are relative. Is this by design? I have to manually/post process this usda to have a relative path to work cross platform at the moment. Well, when I say 'work', it works OK but there will be problems if the metadata is required.

Cheers,

J

Hi,

I notice that the material library becomes sluggish very quickly when one is left to noodle. In this example I've created 64 Principled shaders and connected a singular UV Triplanar Project to illustrate the issue. If I now try and edit the network, I can be waiting 10s of seconds for an update.

This example is a bit silly and one could be using 'material builders' to segregate the shaders and prevent the whole library compiling when adding nodes etc. Even so, some single shaders can become quite complex during developments so I suppose we'd need to find other ways to approach look development to mitigate this slowness.

J

Oh, maybe it's not that practical to have it as an option by default. I just recreated the same workflow from the Karma standard vars and filtered by name *LGT_GEO* so as not to go crazy. Would there be a way to filter the for loop by the existance of a primvar?