Hello,
I'm having a problem with variants to work properly… or I'm doing something wrong (the latter is a very big possibility). I'm attaching a lot of images and I hope it will be readable.

So in USD learning mode I'm replicating a “pipeline” and using “layer break” to simulate where we might export stuff.

1.) First I'm creating some collections to be exported (ignore he model export). Thinking they could be nice to have.


2.) Then I make some amazing lookdev work. And shaders are attached with Collections, and I add a extra Collection.


3.) I'm now doing some lookdev variations. And now I just want to change the color of the hull to a red color (setting the display flag to the edit material to see the result).


So the “edit material” worked, but when I use the set variant it doesn't. Below setting the display flag to “setVariant”.


Below are the options that I have in the variants nodes



4.) Now simulating a “shot variant” to color the threads red.


And this works….


The only difference in these two variants are that one is using “edit material” and the other “assign material”.

I hope someone can clear up my little mess

best regards
stefan

I can't really dig into this right now, but I suspect the issue is LIVRPS (look for Opinion Strength on this page: https://www.sidefx.com/docs/houdini/solaris/usd.html)

Short version: opinions in the local layer stack (sublayered layers) are stronger than opinions expressed in variants (L before V). I would guess that your material definition is in the local layer stack, so opinions about the material definition made in variants are weaker and therefore ignored. Howevere if you Reference in your material rather than having it defined in the local layer stack, the variant opinions will be stronger (V before R).

This is probably the number one issue I see with variants, and I'm working on some changes to Add Variant to make it easier to avoid or work around this problem, but they won't be ready until the new year.

Edit: Apologies in advance if my off the cuff analysis is wrong and your problem is something different and I just wasted a bunch of your time…

Thanks for the suggestion, I'll look into it and see what I can find. I'm currently working from home to be able to post on the internet and make screengrabs, so my only resort is Apprentice. Otherwise maybe the ascii version of usd would help out. I'll try the same thing at the office later on today.

regards
stefan

I think you are on to something about opinions. I tested to add a prune. And I think the reason why this works is because we have specified an item and therefor we have an opinion about it.



While adding the node “edit material” we don't specify. If we add an “assign material” node we do specify and therefor we have an opinion.

But I don't know how to solve this

regards
stefan

You have to make sure that the prim on which you are authoring the variants has all its opinions (or at least all opinions affected by the variants) defined through a reference. This can be a reference to another prim in the scene graph rather than a reference to a separate file on disk. So suppose you have /mats/material1 on which you want to create variants. Instead of creating the variants on /mats/material1, you would deactivate /mats/material1, and create /mats/material1_with_variants that is a reference to /mats/material1. Then define your variants on /mats/material1_with_variants.

Of course doing this dance requires that you to your material assignment after authoring the variants (or updating the assignments after the fact). As is often the case with USD, planning your sceen structure ahead of time is key to exploiting its flexibility.

So what you are saying is that we can't (as and example) add a texture to an existing material, but rather having to create a duplicate of that shader and then do the variation there? That doesn't sound very flexible. This means that you need to add all variations into the lookdev of the asset instead of having it separate.

We were thinking that we could keep a “base” lookdev and then have variations layered on top of it. And this would also mean that you can have shot_variation.usd on top of it. But if you can't inherit the material from the lookdev_base.usd that is going to be somewhat problematic.

sample asset.usd

I'm not sure how I can actually do this

and create /mats/material1_with_variants that is a reference to /mats/material1

or how to deactivate a material.

regards
stefan

mtucker
You have to make sure that the prim on which you are authoring the variants has all its opinions (or at least all opinions affected by the variants) defined through a reference. This can be a reference to another prim in the scene graph rather than a reference to a separate file on disk. So suppose you have /mats/material1 on which you want to create variants. Instead of creating the variants on /mats/material1, you would deactivate /mats/material1, and create /mats/material1_with_variants that is a reference to /mats/material1. Then define your variants on /mats/material1_with_variants.

Of course doing this dance requires that you to your material assignment after authoring the variants (or updating the assignments after the fact). As is often the case with USD, planning your sceen structure ahead of time is key to exploiting its flexibility.

This seems like a flawed approach. We could never expect artists to do this dance in production. Things suddenly changing names due to a new set of variants somewhere. It is also not intuitive at all.
Variants was one of the biggest selling points of Solaris, and I wish is just behaved like if I merged each "variant" on with a switch, which is what we are doing instead. No opinion problems there. Perhaps if there was a node to actually set the opinion strength of a branch like configure layer/primitive or something, that would be nice.

This kind of thing needs to be established long before it gets to the artist. If you plan your asset structure to enable this capability, then these operations can "just work" without the artist having to think about opinion strength at all.

mtucker
This kind of thing needs to be established long before it gets to the artist. If you plan your asset structure to enable this capability, then these operations can "just work" without the artist having to think about opinion strength at all.

In a setting where you have 1000 artists and 12 department it makes sense to handhold with custom setups for variants etc. For a smaller studio however, with 16 artist, we need our artists to be able to build whatever is needed for that project.

So it is a terrible shame if Solaris is only geared towards the big dogs with big tech departments, and not really meant to be used by regular artists like like they would with the rest of Houdini. It then becomes a hard sell to win over people from using blender, clarisse or maya, that can be used for lighting "out of the box" in a sense.

We love Solaris, but I do hope it will become more user friendly, so younglings playing with houdini at home, evolve into Solaris superstars instead of looking the other way.

At a smaller studio, I think the only answer is education. With 16 artists, all of whom are expected to be able to create assets that take advantage of advanced USD features like variant sets, there is no substitute for making sure that everyone understands how this stuff works. So for such users, I see the job of SideFX being to provide lots and lots of high quality learning material, and examples, and starting points and templates that demonstrate best practices. And we are doing all these things, but they take time, and generally lag somewhat behind the development of the features in the software.

In terms of priorities, it is true that we have been so far focused on the large studios, because they can take advantage of the feature set without as much training material (because they can hire in-house expertise). But we have reached the point where we are starting to pivot to be more accessible to smaller studios (though of course all of this work also benefits the large studios, since easier to use software is easier for everyone to use, and they shouldn't need to provide as much custom tooling).

mtucker
At a smaller studio, I think the only answer is education. With 16 artists, all of whom are expected to be able to create assets that take advantage of advanced USD features like variant sets, there is no substitute for making sure that everyone understands how this stuff works. So for such users, I see the job of SideFX being to provide lots and lots of high quality learning material, and examples, and starting points and templates that demonstrate best practices. And we are doing all these things, but they take time, and generally lag somewhat behind the development of the features in the software.

In terms of priorities, it is true that we have been so far focused on the large studios, because they can take advantage of the feature set without as much training material (because they can hire in-house expertise). But we have reached the point where we are starting to pivot to be more accessible to smaller studios (though of course all of this work also benefits the large studios, since easier to use software is easier for everyone to use, and they shouldn't need to provide as much custom tooling).

Agreed, training is vital. We have been enrolled with Houdini Insight for these purposes until it was taken down recently. And I myself try to contribute with doing talks for sidefx as well. For freelancers we would hope they learn this stuff on their own, much like Maya for instance.

I think solving the main thing holding Solaris back for smaller studios and independents, is just packaging somethings up, similar to the karma rendernode vs how you set up renderproduct & rendervars etc without it. Something like that is needed for variants as well. Simplified. Explore variants was a good start of that, and I hope we see more things like that in the future, and by your words, it seems like it may.

I guess the difference if sidefx does it vs every studio rolls their own hdas, is that all solaris artist will at least on some level have the same understanding of solaris, growing the number of artists and freelancers available for it.

In Houdini 19.0.589 (last available supported by Renderman), I am having the same problem with setVariant not working but toggling the output flag within the variant block working. I followed the above instructions in this thread on duplicating / deactivating the original material and working on the reference but I cant get it to work.

• 
  
• 
  
• I sop imported a simple grid,
  created a simple pxrsurface inside a material library, DEACTIVATED IT,
  set up a configurelayer,
  referenced the material with Reference Type set to Multi Input,
  assigned the referenced material,
  created the variant block
  added an edit to the the material, changing Color from red to blue
  again, I can see the change within the variant block by toggling the output flag
  unfortunately, shader permanently stuck on the original red when reaching setvariant.
  

How can I make setvariants work for me? What am I missing?