Forums Solaris and Karma Creating variants in for loop from input primitives

Creating variants in for loop from input primitives

   2360   6   2
User Avatar
AslakKS
Member
160 posts
Joined: Feb. 2016
Offline
 
Hi, how would I create a .usd with variants created from a name attribute in sops.

I curious how you would do this without a name attribute too, "merging" primitives into a single primitive with variants.

I've been banging my head against this for a couple of hours now, and I can't say I'm making much sense of how to approach it.

Attachments:
ksnip_20210623-200804.png (490.9 KB)
create_variant_in_foreach.hiplc (113.9 KB)

 Report
User Avatar
AslakKS
Member
160 posts
Joined: Feb. 2016
Offline
 
I found a way yesterday, I was basically just using the for each loop incorrectly. . .
This correct approach lets me create variants from prims quite easily.



Only thing I would add is that there is a prim present even if no variant is selected. One day I'll look at that too

Attachments:
Lops_prim_to_variant.png (142.2 KB)
Lops_packed-to-variants_v001.hip (1.8 MB)

 Report
User Avatar
Hyperreal-Studios
Member
15 posts
Joined: Nov. 2021
Offline
 
AslakKS
I found a way yesterday, I was basically just using the for each loop incorrectly. . .
This correct approach lets me create variants from prims quite easily.

Image Not Found


Only thing I would add is that there is a prim present even if no variant is selected. One day I'll look at that too
Hello. I tried your solution. But not with SOP Import, but with Sublayer node. And it's create primitives, but they became I don't see them in scene nor render

Attachments:
Screenshot 2023-09-21 122535.png (26.8 KB)
Screenshot 2023-09-21 131052.png (882.5 KB)

 Report
User Avatar
Hyperreal-Studios
Member
15 posts
Joined: Nov. 2021
Offline
 
I figured out that if I remove mtl, exerything works correct, only thing that I miss materials on object, that not appropriate way. As I have material already assigned, I need to keep them on the model, without reasigning and etc.
 Report
User Avatar
aeaeaeae
Member
126 posts
Joined: Aug. 2010
Offline
 
I wonder what they we're thinking when designing this, it's incomprehensible, even for senior users. You shouldn't need to spend hours figuring how to get a set of named primitives from SOPs into USD variants.
 Report
User Avatar
mtucker
Staff
4441 posts
Joined: July 2005
Offline
 
Sorry to hear you're having trouble, but perhaps you could be more explicit about what you're having trouble with? Maybe post a hip file showing what you've tried? As demonstrated by the OP, creating variants with a For Each loop does work, and doesn't involve a huge number of nodes.

@Hyperreal-Studios didn't post a hip file (and the image posted covers a lot of the important details with a parm dialog) so it's not clear what their issue was...

The designation of what is "incomprehensible" is always in the eye of the beholder, so we need your help seeing through your eyes. I think a good starting point is for us to see what you've got, we'll get it working, and then we can discuss what made it impossible for you to get to the solution on your own.

Thanks for your input!
 Report
User Avatar
aeaeaeae
Member
126 posts
Joined: Aug. 2010
Offline
 
Yeah, I don't know what to say ...you need to include more "beholders" during your design process?

As far as I remember trying to get this up and running (I've deleted the files) the issue was a combination of syntax confusion, you needed at least 4 layers of abstraction (for loop nodes, expressions, context variables and USD paths), unreliable cooking from the for loop nodes, and no obvious visual confirmation that you had hit the right combination of settings. Parameters scattered across nodes. Subtlies like `` @ $ etc. To me it's obvious that the design is to complex, without much guardrails and to dependent on context specific know-how. It adds an overall usage tax, since trivial tasks require looking up previous setups or turning to google.

I gave up and used PDG instead, which worked fine.
 Report
  • Quick Links