Use a for each to send each variant into a SOP Modify LOP?

   1310   6   4
User Avatar
Member
355 posts
Joined: 11月 2015
Offline
Is there a way I can use a For Each LOP to send each variant into a SOP modify LOP, do some animation stuff and get it back into Solaris as a layer override?

Essentially something like shown in the image.

Attachments:
Screenshot 2023-05-23 201848.png (43.6 KB)

hou.f*ckatdskmaya().forever()
User Avatar
Member
22 posts
Joined: 6月 2013
Offline
You're 90% there already! Take a look at the attachment. Is this what you were looking for?
Edited by alexandru_p - 2023年5月25日 19:36:19

Attachments:
foreach_vars.hiplc (238.6 KB)

User Avatar
Member
355 posts
Joined: 11月 2015
Offline
alexandru_p
You're 90% there already! Take a look at the attachment. Is this what you were looking for?
yes, thanks a ton, this is exactly what I'm after!
hou.f*ckatdskmaya().forever()
User Avatar
スタッフ
4438 posts
Joined: 7月 2005
Offline
Yes, you can do roughly what you've done there, but you also have to use an Add Variant LOP between the SOP Modify and the foreach_end so that the per-variant modification is authored back into the originating variant. As you've got it there, the overrides authored for each variant are all going to be applied to the prim all the time, regardless of the variant selection.
User Avatar
Member
55 posts
Joined: 5月 2013
Offline
I'm trying to learn more about Solaris and USD from the forums.

Can I ask what the advantage of using the sublayer workflow is? If I switch the for each to run over each variant in the first input and wire addvariant1 into there, I can't see any difference in the result.
User Avatar
Member
22 posts
Joined: 6月 2013
Offline
Using the first input of the foreach instead of the second makes the original geometry be used also as an input stage. That means the layer resulting after the foreach doesn’t contain just the “over” with the modified geo, but also the original layer.
While this is a totally valid approach, we usually like to keep things separate because it gives you the flexibility in the final stage to load/unload layer at will.

Usually these things happen in different Houdini projects handled by different departments. You would have the initial static asset published by the lookdev department, the animation would read these assets but only write inside their own usd file the changes they bring to the asset. Finally, when it comes to lighting for instance, the artist can start working with the static assets, even if the animation is not there yet, and load it in later at his own convenience.
User Avatar
Member
55 posts
Joined: 5月 2013
Offline
I see, that makes sense. Thanks very much for the explanation.
  • Quick Links