goldleaf
It's because the Assign Material LOP can only see cube1 or sphere1 at a time. If the node can't see a primitive, it won't author a material binding. USD supports authoring to a pure "over", which basically says "if a prim is ever defined here, give it this material binding". Most LOP nodes don't work like this, because usually that's not what people want/expect.

It's usually better for the assignments to either be authored within the variant. Even if the material itself is not defined within the variant.

Another approach is to only control visibility or activation in the variants. This means that all (or nearly all, if using activates) of the prims are present, and can be edited by LOP nodes. I believe this is the approach Pixar takes for model variants. I've attached an example of visibility-variants.

Hope this helps!

This is great! thanks much. I also did another version (attached file) that seems to work ok, what would be the pro and cons of both versions?

I have this setup (see attached file) where I'm creating variants, each with a different material. Now, if the set variant LOP comes before the assign material, it works, but if it comes after, it doesn't work. I don't want to use the component builder for this because I'm wanting to understand what the composition engine is really doing. So, my question is, what is happening behind the scenes why I'm getting these results, and what can be done to fix it? Variants are very cool for how I want to work and I really want to get a hold of what's happening and when local arcs are messing me up.

Carlos_Rivadulla
-Revamped Substance Designer like COPs. Packing an MTLX within an USD-HDA has a lot of potential.
-Sculpting basics (you don't need to be the best). I don't care if it's an all-in-one node or a suite of nodes. I'm dying for grid remeshins>sculpting>quadremeshing. Aren't you?
-More appealing direct modeling.There is too much friction between the user and the viewport.
-More appealing subd modeling.
-Kill OBJ level in favor of LOPs.
-Kill Mantra in favor of Karma.
-try to end redshift's hegemony in favor of materialx
-GPU Multithreading pyro solver.
-cascadeur like Physics anim.
-Vulkan viewport.
-Continue bringing valuable things hidden in networks to SOP level. Blender users are using VOPs in SOPs, and they don't even know it. That's the key, make people use it without telling them they are using it. There are a lot of things that are not used simply because they are hidden. Maybe geeks like that, but it's not reasonable, accessible, intuitive, or user-friendly at all. Constraint Relationships for mechanical stuff is a good example of what I'm not using because it's out of scope. Another example is to use a simple geometry CHOP you have to create a CHOPnet, a channel node, dive inside, use a Geometry (specify the path) and then use the actual node (...) 4 nodes and one lvl down to do a noise filter really?.
-Get rid of redundant nodes (clean the house, tidy up your room, throw away the old furniture)
-Add the whitewater nodes to the new FLIP suite.
-A shortcut like R+R in Blender to rotate with the trackball should be great to have. Especially when rotating bones. Typing in the viewport like g+x+value (move+axis_constraint+amount) is also a good idea to reduce friction.
-Symmetry selections and select similar.
-The groups widget is kind of annoying. It should be great to visualize groups through the info panel by clicking on the group name, just like you do with attrs.

Dreaming is free section
-AI-powered nodes (starting with Auto UV as an experimental field). Similar to Runway tools "color grade from prompt", "color grade from reference", "auto-tracking from target". They have 30 one-click tools that could perfectly be Houdini nodes.
-Neural VDBs
-AI Accelerated karma
-Convert to nurbs > bevel > convert back to poly. To leverage the most envied feature of software like Plasticity (which is the NURBS beveling).

Some Nice Words
Don't rush to release this update. Take as much time as you need to make it as impactful, disruptive, loud and groundbreaking as possible, so that it shakes up the industry and claim your throne as industry standard. If you have to delay it 1,2,3 months, fuck people really.
...
"I never saved anything for the swim back" Gattaca (1997)

These are my hopes and dreams too! lol
I hope sidefx is listening, I’m doing a lot of non-procedural modeling in houdini atm and the software almost seems like it’s begging me not to do so! the viewport interaction with modeling tools is a hit and miss situation. The node graph sometimes drops edit nodes in weird places in the node graph and totally f’up the model; it’s just way more frustrating than it needs to be! The object level has always been the worst thing about houdini for me and I truly hope I no longer have to use it, my start up currently defaults to stage context.

The houdini openGL view might just be the worst one I’ve use on any 3D software in terms not updating properly; a lot of times I have to close the viewport panel and open a new one to kick in updates, I don’t know if that’s houdini or GPU drivers.

UV tools need to be better!

I’m really looking forward to H20 whenever it comes out! I too hope SESI takes their time and give us a great update!

Is there anyone here who uses Redshift with Solaris for rendering millions (like 10 and above) of particles? If so, I'd love to get some insight into your workflow. I now know, courtesy of J Gonzalez that there is a limitation with RS in Solaris where if you want to render particles as little spheres, you must use point instancing. So, he suggested using the points as a proxy and the instances as render geo. Is anyone else using a different workflow?

jsmack

traileverse
Yes! that was the issue indeed. thanks a ton. Also, what would be your recommendations (videos, articles etc) for learning karma more in-depth?

I don't know any other than the docs. I mostly use the scientific method of trial and error.

Docs are always best of course. I know they working on making the karma sections more comprehensive and polished so I'll stick with it.

jsmack
That's strange. the only thing I can think of is it a ray bias issue? The transparent layer between the camera and the emissive material, is it closer to the transparent material than the size of the ray bias? (default is 0.001 for Karma and Mantra I think) For small objects modeled in meters, the default may be a tad large.

Yes! that was the issue indeed. thanks a ton. Also, what would be your recommendations (videos, articles etc) for learning karma more in-depth?

I have serveral pieces of geometry that make up a screen:

1. the body - (plastic like material)
   
2. a plane piece that is the LED screen - (emissive material)
   
3. and a piece representing a glass covering over the screen (for reflections and such) - (transparent material)
   

I've uploaded images from both the karma and redshift render.

When I render in Karma, the emissive mat is weird and it seems as if I'm seeing through the emissive material to the geometry behind it (circled red in the karma image). I'm using USD preview material but I also tried with Mtlx and it's the same. I then used both redshift and arnold to render the geometry with the usd preview surface and it works as expected.

Anyone experienced with karma can share what the problem might be here would be much appreciated. Thanks in advance.

Seeing that MaterialX now has native graph editor, is sidefx going to implement this?

are there plans for a material browser palette in solaris where we can easily see previews of our preset materials and also see proper visual previews of new materials as we adjust the parameters?

tamte
I'm not sure if there is a place with rules described, the only place in docs seems to be this
https://www.sidefx.com/docs/houdini/basics/select.html#pattern [www.sidefx.com]

Yeah that's what I found as well I was hoping there was someplace where it was a little more detailed, but oh well. Group range or something similar will have to do until I get more clarity on how that works.

tamte
here is docs for SOP group patterns:
https://www.sidefx.com/docs/houdini/model/groups.html#manual [www.sidefx.com][

and here for LOP primitive patterns:
https://www.sidefx.com/docs/houdini/solaris/pattern.html [www.sidefx.com]

Oh no, sorry my bad, not pattern selections in group parameters, but like interactive primitive pattern selection while modeling or editing geometry.

Like say I have a selection like seen in the image and I want to use something like that and the press SHIFT+Up Arrow to continue the pattern across the geo. Sometimes it even says valid pattern selection, but then does the wrong selection when I try to continue the pattern.

Is there a place in the documentation for pattern selections? I'm making some pattern selections that seem to me like they should work, but I'm getting a message that it's an invalid pattern selection. What rules should I follow for a 'valid' pattern selection?

I'm really excited by the things that was said to be coming for h20 (KineFx matured, hopefully XPU prod ready, feather system and whatever else was mentioned). But I'm hoping for some serious modeling improvements! I'm a freelance artist and Houdini is my tool of choice for everything along with zbrush. I'd love for it to really be more fun for typical manual asset creation task (It's great for procedural asset creation):

• More robust interactive modeling tools
  
• Topobuild SOP is OK for retop, but not a fan of how it automatically caches the geometry and locks it in, this makes it weird to use for normal modeling IMO. But the tool is a step in the right direction.
  
• The viewport state between Edit SOP and other node like polysplit etc is very glitchy (Viewport state, in general, is just )
  
• Pattern Selection is a neat idea but definitely needs to be able to handle more sophisticated patterns
  
• Allow edit SOP to do things like duplicate edges as we slide them across other edges or over the surface and also add snap feature within the SOP like you have in topobuild where we can snap and fuse points
  
• I need to use the radials menus more before I can say anything about them, I honestly just mostly forget that they exist lol
  
• Overall, creating and editing polygons needs to be faster and more interactive and viewports states need need religious intervention to remove the glitches and bad state updates.
  
• We could also do with something like the Insertion Point LOP in SOPS for modeling purposes.
  
• Viewport subdivision view mode must be a joke, It doesn't work at all while modeling in SOP context (Am I using it wrong or does it only work at object level?)
  
• I like doing UVs in houdini (if they work without (UV Layout, UV Flatten etc) SOPS crashing and doing all sorts of weird shit (and yes sometimes we will have degenerate geometry so it needs to handle those without going crazy)) - these SOPS have improved with recent biulds of houdini though so many thanks for that.
  
• UDIMs workflow could do with some re-evaluation (even though the current workflow is not bad).
  

osong
Merge Small Island option in autoUV by labs should help with this issue

Sometimes the merge small islands cause overlaps; but what kinds of major issues will these small islands cause when baking and texturing in a tool like substance painter?

If I have UV maps like the one shown in the image (in the zoomed-in image you can see the very small/tiny UV islands circled red which will occur when using Auto UV solutions in Houdini (even after running something like LABS merge small islands and it also helps to avoid overlaps)), is this really bad when doing a normal map bake in say substance painter? Is there anything I can do in Houdini to mitigate potential problems, or is this not a problem for map bakers?

I'm only doing these sorts of auto UV stuff for models that I create in ZBrush and use auto re-topology solutions because they aren't deforming meshes and as such, excellent topology is not a must and I would hate to spend the time doing manually re-topology if it's not necessary; but UVs must be able to work great for normal bakers and such. Any guidance in this area is much much appreciated.

goldleaf
Yes; you would put the variant set blocks within each other, like this. You also need to ensure that the nested variants are authored on the same prim as the outer-most variantset, or on a child of that prim; the data within the variant must be encapsulated beneath that primitive.

Hope this helps

Thanks a lot for this! yep, this works great!

Can we nest a variant set with its own variants under another variant set? if yes, how can we do this in solaris?

npetit
The warning comes from the stage being time dependent, and thus the node being time dependent too - you can ignore the warning, or you can cache the animation which will improve performance overall.

Setting a cache LOP to 'always cache all frames' gets rid of the error; is there any way to see what the cache LOP is doing in terms of memory used and so forth? The performance of the scene didn't seem to take any hits performance-wise but how dangerous is it to cache all frames in memory like this? Or is it totally Ok to do so?

jsmack

traileverse

tamte

traileverse
it says setting animated variants is not supported in USD

Is that a Houdini limitation?
Based on Pixar usd glossary:

Each Variant can contain arbitrary scene description including the introduction of additional composition arcs. This gives us great flexibility in building up variations out of existing, modular pieces that can be referenced, inherited, etc.

it sounds like it should be possible if each variant can really contain any scene description or reference

It seems to work but I get this warning:

That means the selection of the variant can't be animated, the variant itself can contain animation. To animate which variant is visible, two references would be needed and the visibility flag can be animated instead.

I'm not animating which variant is active, there is no animation on the set variant LOP, it's picking up the animation that's on the prim. How would I get the set variant in a non-time sampled stream? the image shows what the set variant LOP looks like at the moment and you see no animation.

tamte

traileverse
it says setting animated variants is not supported in USD

Is that a Houdini limitation?
Based on Pixar usd glossary:

Each Variant can contain arbitrary scene description including the introduction of additional composition arcs. This gives us great flexibility in building up variations out of existing, modular pieces that can be referenced, inherited, etc.

it sounds like it should be possible if each variant can really contain any scene description or reference

It seems to work but I get this warning: