Is it me or is replacing a branch from USD not a thing? Got incoming geo with cheapo materials, got a nice material lib setup in LOPs with identical path and names etc.. been trying for an hour to replace the materials on the incomming geo. Merging/layering/etc it over somewhat works for CPU Karma, not for GPU. Also the enable texture flags are ignored by the conversion, I'll add it to the pile of bug reports I still have to make on Solaris Karma.

Rant part starts here.. All I need to do is add a 3d model of an Hydrogen plant to some drone footage, a rather simple task

This whole 'work in native USD' workflow nice on paper but falls apart real fast when you're also working in /obj to prep geo and setup materials. With default nodes it's a 20sec conversion time when you touch anything or scrub the timeline. Granted the plant is a 300MB fbx but not exceptionally heavy. Everything is static except for a single camera yet the Karma rop is recooking the whole scene when you just look at it. I spend a few hour redoing all that and got a somewhat workable setup. Last step is to simple replace materials, something that should be a no brainer!

All I want is to render a simple scene in Karma and do some lookdev. I'm close to giving up on this again, Maybe H20.5 fixes this all but I doubt that since it's a fundamental issue. Either Karma needs to work with native Houdini geo or /obj needs to output USD natively and as fast. Neither of those look like a realistic option.

To end with a positive, Karma itself is really nice!

Jonathan de Blok
Is it me or is replacing a branch from USD not a thing? Got incoming geo with cheapo materials, got a nice material lib setup in LOPs with identical path and names etc.. been trying for an hour to replace the materials on the incomming geo. Merging/layering/etc it over somewhat works for CPU Karma, not for GPU. Also the enable texture flags are ignored by the conversion, I'll add it to the pile of bug reports I still have to make on Solaris Karma.

that's not how the layering works, you wouldn't attempt to combine a material with an overlay of a different one, that would just end up with a corrupt mess. You would have to replace the material, which isn't a thing in USD. There is no replace only combine.

the proper way to layer is to create a new material with a non-conflicting name, and in the layer also change the material assignment to this new material. This way the layering will combine like for like. An empty prim containing an assignment opinion will overwrite the existing assignment in the lower priority layer. The way to directly layer the material itself is with a topologically consistent change, such as changing a texture path(s) or shader parameter(s).

Presumably your initial/cheap material definitions aren't in a separate layer to the geometry and bindings? If they were you could just replace that layer with a different layer that uses the same names but with upgraded materials.

Thanks for the pointers, I actually did manage to find a way replace/delete/update branches.

Using a 'split' scene you can split of the part you don't want, then replace them with a new one, if paths/names match it will work as a replacement.

red: incoming scene with original /obj/plant/matnet1 content
green: by splitting off the /matnet1 branch, the left over is the scene excluding that part
blue: the matlib node inserting it's content at /obj/plant/matnet1 effectively replacing it.


That being said, my Solaris adventures goes into the fridge for now, back to Redshift it is. I really wanted this to work, and i hope 20.5 brings some mayor overhaul in this area. Solaris has fundamental performance issues, Karma renders fine but the whole UX is flawed. Everything takes so much more time to setup, I'm sure there is a tipping point for Pixar sized studios where it's all worth it but for solo artist/small teams it's just not there. Working natively with USD is nice on paper but also very incompatible with the regular /obj workflow. That in itself is not that terrible was it not for the fact that Karma is USD only. So effectively Houdini does not have a way to render it's own native /obj content in a efficient way that makes it comfortable for animation and lookdev.

/rant

Jonathan de Blok
Thanks for the pointers, I actually did manage to find a way replace/delete/update branches.

Using a 'split' scene you can split of the part you don't want, then replace them with a new one, if paths/names match it will work as a replacement.

red: incoming scene with original /obj/plant/matnet1 content
green: by splitting off the /matnet1 branch, the left over is the scene excluding that part
blue: the matlib node inserting it's content at /obj/plant/matnet1 effectively replacing it.

Image Not Found

That being said, my Solaris adventures goes into the fridge for now, back to Redshift it is. I really wanted this to work, and i hope 20.5 brings some mayor overhaul in this area. Solaris has fundamental performance issues, Karma renders fine but the whole UX is flawed. Everything takes so much more time to setup, I'm sure there is a tipping point for Pixar sized studios where it's all worth it but for solo artist/small teams it's just not there. Working natively with USD is nice on paper but also very incompatible with the regular /obj workflow. That in itself is not that terrible was it not for the fact that Karma is USD only. So effectively Houdini does not have a way to render it's own native /obj content in a efficient way that makes it comfortable for animation and lookdev.

/rant

Even Sidefx doesn't recommend using karma in this way. Package your asset with component builder, then render it in proper stage environment.

In your example you don't really need to replace the original "pebbles" material. It is possible as you've shown, but there's no real benefit so if it were me I wouldn't waste the time trying. Just create a new material like "pebbles_new" and assign it to whatever geometry was previously assigned to "pebbles". If the now redundant "pebbles" material is annoying to have around and can't be discarded from the original input, it can be deactivated with a configureprimitive lop.


The sceneimport performance is a different issue and I hope gets faster in the future too.

The pebbles was just a reduced example, the full scene is around a 1000 objects with 50+ materials. So it's not that easy.

And packaging assets, that's nice when the assets are all finilized and locked. But I'm fixing geo issues, doing materials, adding details etc as I see fit. I guess my workflow just does not play nice with the ways of USD. Solo-artist-needs vs large-team-needs.