Found 1021 posts.
Search results Show results as topic list.
Solaris and Karma » Correct way to get instancer using variants
- mtucker
- 4441 posts
- Offline
Solaris and Karma » Creating explicit save layers with Python
- mtucker
- 4441 posts
- Offline
One more thing you need to do to get the USD ROP to save your anonymous layers: create the anonymous layer with a "tag" argument of "LOP". This is how the USD ROP identifies layers as having been authored by the LOP network.
Note that everything else you're doing here is correct, and in fact there is a python method loputils.createPythonLayer that encapsulates all this so you don't actually need to know all these details. Just pass it the hou.LopNode that is creating the layer (hou.pwd() when inside a Python LOP) and pass in a save path where you want the layer to be saved.
Note that everything else you're doing here is correct, and in fact there is a python method loputils.createPythonLayer that encapsulates all this so you don't actually need to know all these details. Just pass it the hou.LopNode that is creating the layer (hou.pwd() when inside a Python LOP) and pass in a save path where you want the layer to be saved.
Solaris and Karma » Correct way to get instancer using variants
- mtucker
- 4441 posts
- Offline
Try turning off the "Create References" toggle on the Explore Variants node? I believe that will eliminate the reference arc above the individual variants, allowing each variant to be safely copied into the instancer's prototypes folder.
Solaris and Karma » Usd render scene issue
- mtucker
- 4441 posts
- Offline
Since you mention "work items" I assume you're using TOPs as well, not a vanilla USD Render ROP? Any chance you could attach a simple hip file to demonstrate your setup? Thanks!
Solaris and Karma » Editing variants not selected in the stage.
- mtucker
- 4441 posts
- Offline
Using Set Variants is the only way to nicely edit a variant. We have it on our "eventual todo" list to create an "Edit Variant" HDA (similar in concept to "Edit Prototype"), which wraps the Set Variants inside a subnet where you can safely edit the chosen variant. But this idea hasn't made it into any of our release plans yet.
Using `/parentprim{variantSet=variant}childprim/mesh` style paths doesn't make much sense in a LOP context where LOP nodes make modifications to a composed stage. Variant-selection paths like this only really make sense when directly editing Sdf layers using low level Sdf APIs (which most LOP nodes don't allow, and if they do it's an "implementation detail" that we don't want exposed to the user because we may want to change the implementations).
Using `/parentprim{variantSet=variant}childprim/mesh` style paths doesn't make much sense in a LOP context where LOP nodes make modifications to a composed stage. Variant-selection paths like this only really make sense when directly editing Sdf layers using low level Sdf APIs (which most LOP nodes don't allow, and if they do it's an "implementation detail" that we don't want exposed to the user because we may want to change the implementations).
Solaris and Karma » Default AOVs / Render Output in the Solaris viewport
- mtucker
- 4441 posts
- Offline
If you have a render settings prim, the list of render products is "ordered", and on each render product, the list of render vars (AOVs) is also "ordered". The ordering of that AOVs menu to the right of the viewport respects the ordering of render products and render vars specified on these USD prims. If "color" is not found among the available AOVs, the viewport defaults to showing the "first" one in the list. Thus you can control with LOP nodes which AOV gets shown in the viewport by default.
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- mtucker
- 4441 posts
- Offline
I can assure you we are not intentionally makig Houdini more difficult with each release. Perhaps you could explain in more detail what you are trying to do, what steps you have taken to accomplish our goals, and what you have found difficult about the process we could help, and maybe improve the software to make it easier for the next person. Your basic question seems to be "how do I assign materials" and the basic answer is "the Material Linker LOP or the Material Assign LOP"...
Solaris and Karma » Correct way to get instancer using variants
- mtucker
- 4441 posts
- Offline
That method is totally correct and official, but maybe not optimal Have you tried using the Explore Variants LOP? You network would be Asset Reference -> Explore Variants -> Instancer (2nd input).
Solaris and Karma » How to author layer mutes with a python LOP
- mtucker
- 4441 posts
- Offline
No, it is not currently legal to mute layers in a python LOP.
If the python is expensive, you can run it once in a python LOP, and attach the result to the HoudiniLayerInfo prim as metadata or an attribute. Then in the Configure Stage LOP you can read the value from the stage with some fairly simple python code.
If the python is expensive, you can run it once in a python LOP, and attach the result to the HoudiniLayerInfo prim as metadata or an attribute. Then in the Configure Stage LOP you can read the value from the stage with some fairly simple python code.
Solaris and Karma » "Render All Frames with a Single Process"
- mtucker
- 4441 posts
- Offline
There are a couple of potential problems with rendering all frames from a single process:
1. it's harder to track progress
2. problems can occur when objects move from far away to up close - redicing may be required, but may not happen
3. Problems with some LOP setups can be "papered over" by rendering each frame separately (as described above by @goldleaf)
4. there used to be a much bigger problem, where the more frames you render from a single process, the more likely the renderer is to crash. It still happens of course, but far less frequently than when we made the decision on this default.
If we solved that first problem I'd be more likely to consider changing this default... Even more so if husk could detect frames that had already been rendered and skip ahead to the first frame in the sequence that didn't already exist on disk (in case it crashes half way through the sequence).
Anyway, it's definitely something we should consider...
1. it's harder to track progress
2. problems can occur when objects move from far away to up close - redicing may be required, but may not happen
3. Problems with some LOP setups can be "papered over" by rendering each frame separately (as described above by @goldleaf)
4. there used to be a much bigger problem, where the more frames you render from a single process, the more likely the renderer is to crash. It still happens of course, but far less frequently than when we made the decision on this default.
If we solved that first problem I'd be more likely to consider changing this default... Even more so if husk could detect frames that had already been rendered and skip ahead to the first frame in the sequence that didn't already exist on disk (in case it crashes half way through the sequence).
Anyway, it's definitely something we should consider...
Solaris and Karma » What to expect going forward with Solaris?
- mtucker
- 4441 posts
- Offline
Having a USD "scene delegate" that translates SOP geometry directly to hydra prims is something that has always been on the big wish list, but it's a huge amount of work, so we've always shied away from it. Especially with the major upgrades that have been drifting into hydra over the past couple of years it was extra hard to justify that effort. Now that the new hydra framework has settled down it at least becomes feasible to think about this again, but it's still a huge amount of work, and so would take a lot of developer time away from other things. The other knock against it is the limited contexts in which it would be useful. It's basically only going to work for in-Houdini-process render delegates. Add to this the work we're doing to improve workflows where Houdini GL is rendering a stage and the SOP viewer is rendering SOP geometry into the same viewport, and the use case gets even smaller.
So yeah, it's a good idea in theory, but has so far been rejected because of the calculation of effort versus how much is gained by how many people. A "SOP scene delegate" has just never made the cut. It really hasn't even been close, to be honest. But I'd never say never.
For now we are just focusing on the "Karma ROP" workflow where we have tried to make the translation process from OBJ to karma seamless and robust (and as fast as it can be given the inherent limitations of importing to USD before sending to the renderer).
So yeah, it's a good idea in theory, but has so far been rejected because of the calculation of effort versus how much is gained by how many people. A "SOP scene delegate" has just never made the cut. It really hasn't even been close, to be honest. But I'd never say never.
For now we are just focusing on the "Karma ROP" workflow where we have tried to make the translation process from OBJ to karma seamless and robust (and as fast as it can be given the inherent limitations of importing to USD before sending to the renderer).
Solaris and Karma » Layout Only Uses One Variant ?
- mtucker
- 4441 posts
- Offline
Are you on Windows by any chance? There is a bug (that we just fixed today) where thumbnail generation on Windows in general wasn't working, but it should be fixed in tomorrow's builds. If you're not on Windows, what version of Houdini are you running? Both @goldleaf and I have been able to write out per-variant thumbnails without issue (excepting the Windows bug mentioned above).
Attaching my super simple hip file in case that might be helpful. Just hit "Save to Disk" on torus_asset.
Attaching my super simple hip file in case that might be helpful. Just hit "Save to Disk" on torus_asset.
Solaris and Karma » What to expect going forward with Solaris?
- mtucker
- 4441 posts
- Offline
WowNems
As you says, if we could use SOlaris and Karma without USD, it would be PERFECT!!!!
I hear this sentiment expressed every now and then, but to be clear, neither Solaris nor Karma would exist without USD. The amount of infrastructure provided by USD and hydra is absolutely enormous. They can't simply be "replaced with native Houdini". Houdini never had these capabilities. A scene graph? Layered opinions? LODs? Variants? Composable scene graphs? An industry standard renderer-agnostic rendering API? A (nearly) universally understood data format for sharing between DCCs? Multithreaded scene construction? A complete python API for scene graph manipulation? An army of Pixar, Autodesk, nVidia, Adobe, Apple, and other developers working together on the underlying framework?
The alternative to embracing USD and hydra was never "stay on the current path". Does anyone remember trying to work with stylesheets for material assignments and overrides? And continuing to live with no actual overall scene description? Just a free floating cloud of objects that each needed to be represented by a separate node in /obj? That would never be able to compete with the likes of Katana.
The only actual alternative to adopting USD and hydra was writing our own equivalent to provide all this functionality ourselves. And then to also write a robust import/export system for interchanging with USD (since it really is the closest thing we have to an industry standard these days). After five years of working on that we would have had a much worse equivalent of USD with much worse tooling built on top because we would have had a lot less developer time to devote to the tooling with more resources (but nowhere near enough) focused on the framework. I have never doubted our decision to put USD and hydra at the core of Solaris. Not because USD and hydra are uniformly wonderful, but because I have given a great deal of thought to the alternative.
Now, do I wish we could have accomplished more by now? Of course! I have a list of tasks a mile long that I am eager to get to. If you ask me again in five years, or ten years, I can almost guarantee I'll be saying exactly the same thing. But I also think we will have made a great deal of progress, just as I think we have over the past five years. I think we have a pretty good idea where Solaris comes up short, and we'll keep plugging away trying to make it a little better with each release, for what we hope is an ever-growing set of users. Thank you all for your thoughts!
Solaris and Karma » Creating variants in for loop from input primitives
- mtucker
- 4441 posts
- 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!
@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!
Solaris and Karma » Layout Only Uses One Variant ?
- mtucker
- 4441 posts
- Offline
You need a separate asset definition in the asset gallery database for each variant. Then you explicitly pick which variants the Layout LOP should be using with the current brush. I believe the Component Builder has options to create per-variant entries in the asset gallery. The reason for this arrangement is that point instancers in LOPs can't pick a prototype variant on a per-instance basis. Each variant selection must be presented as a separate prototype. So we adopted a similar arrangement for assets in the gallery. This approach also has the advantage that it is easy to see the difference between the variants (from their thumbnails) and when using assets with variants, it isn't an all-or-nothing choice. You get to include/exclude each variant explicitly.
Solaris and Karma » Retiming value clip instances
- mtucker
- 4441 posts
- Offline
For sure, having the SOP Import LOP explicitly recognize packed disk primitives and convert them into references or value clips is definitely a good idea to provide an even more familiar SOP-centric workflow. I was about to say "you should submit an RFE for that", but a quick check reveals that you already have! So thank you for that.
If what you're describing is the desired workflow for this user, then the closest option is the one demonstrated in the posted hip file (option 4) of using a geo clip sequence in "sample all frames" mode to create the value clip, then using an instancer LOP and a retime instances LOP. It's obviously different from a pure SOP/packed disk workflow, but not too far off, I think.
But in the provided file, the original animated SOP data is being saved out as per-frame USD files, not BGEO files. And the original question was the very generic "how I can instance animated geometry in LOPs". So given that context I thought it was worth mentioning that an animated USD file would, IMO, be a better option that avoided value clips altogether.
If what you're describing is the desired workflow for this user, then the closest option is the one demonstrated in the posted hip file (option 4) of using a geo clip sequence in "sample all frames" mode to create the value clip, then using an instancer LOP and a retime instances LOP. It's obviously different from a pure SOP/packed disk workflow, but not too far off, I think.
But in the provided file, the original animated SOP data is being saved out as per-frame USD files, not BGEO files. And the original question was the very generic "how I can instance animated geometry in LOPs". So given that context I thought it was worth mentioning that an animated USD file would, IMO, be a better option that avoided value clips altogether.
Solaris and Karma » Retiming value clip instances
- mtucker
- 4441 posts
- Offline
Let me start with a general piece of advice: Unless you know for sure that you need value clips, always assume that you don't need value clips. Value clips provide basically one bit of functionality: the ability to split a single large USD file into a bunch of smaller USD files, but have them behave in USD as if they are one large USD file. If your problem is anything other than "my USD file on disk is too large", you probably don't want value clips. You're almost always better off with a single animated USD file.
I may be pushing back on this harder than is absolutely necessary, but I see a lot of people think they need value clips when they really don't, but they dive into the value clip rabbit hole anyway and learn that value clips don't make anything easier. They make everything harder. When you need them, you need them. But when you don't need them, don't use them.
In your case, you want to retime animations. There is nothing inherent about animations or wanting to retime them that points in any way towards needing value clips. So you probably don't want to use value clips. In your original USD Export, you could just specify the Output file as $HIP/geo/seq/sphere.usd and your animated sequence would go into one USD file and everything else would be much easier.
BUT I could be wrong about your situation, and you provided a great sample hip file, so let me try to answer your actual questions. First, from your hip file:
1. The timeshift_doesnt_work node works fine for me.
2. The SOP Import doesn't work because your "packed disk" primitives are actually "packed USD primitives" because you're loading them from a USD file. Packed USD prims are handled specially by the SOP Import LOP. If your SOP packed prims were just loading BGEO data, you could set the SOP Import to handle "Packed Primitives" as "Unpack", and you'd probably get more or less the result you expect.
3. retimeinstances_doesnt_work doesn't work, in part, because you are pointing it at the wrong primitive. You need to set the Instances parameter to /geoclipsequence_noTimeDep_usd and then you can see the SdfLayerOffset on the Reference set on that prim has an offset of -3.1. Now this still accomplishes nothing because that reference is to the _topology_ file of the value clip. By definition, the non-animated stuff. So adjusting the timing of the non-animated stuff does nothing. This reveals a major underlying issue: the Retime Instances LOP retimes things by adjusting the SdfLayerOffset on reference and payload arcs. It knows nothing about value clips, so it cannot explicitly retime a value clip. This also points to a solution - put the value clip (which retime instances cannot retime) behind a reference (which retime instances can retime).
4. This gets us to retimeinstances_seems_to_work, which does indeed work because the instancer1 LOP created those references to the value clip I mentioned in point 3. Retime instances can adjust the SdfLayerOffset on those references and everything works as expected.
As to why you need to turn on "Sample Frame Range" on the geo clip sequence for any of this to work - this is going to be true of any retime instances workflow. The retime instances actually works fine in "current frame" mode, the problem is that you can't _see_ that its working fine if there is only one frame of animation data available at a time. You need to have the full (or at least partial) animation available in a layer for you to see the effect of the SdfLayerOffset set by Retime Instances. If you use a USD ROP to write out a 24 frame USD file with the geo clip sequence set to "current frame" and sublayer in that resulting USD file, you'll see that it actually works just like setting the geo clip sequence to "sample all frames".
Hope that helps clarify some things,
Mark
I may be pushing back on this harder than is absolutely necessary, but I see a lot of people think they need value clips when they really don't, but they dive into the value clip rabbit hole anyway and learn that value clips don't make anything easier. They make everything harder. When you need them, you need them. But when you don't need them, don't use them.
In your case, you want to retime animations. There is nothing inherent about animations or wanting to retime them that points in any way towards needing value clips. So you probably don't want to use value clips. In your original USD Export, you could just specify the Output file as $HIP/geo/seq/sphere.usd and your animated sequence would go into one USD file and everything else would be much easier.
BUT I could be wrong about your situation, and you provided a great sample hip file, so let me try to answer your actual questions. First, from your hip file:
1. The timeshift_doesnt_work node works fine for me.
2. The SOP Import doesn't work because your "packed disk" primitives are actually "packed USD primitives" because you're loading them from a USD file. Packed USD prims are handled specially by the SOP Import LOP. If your SOP packed prims were just loading BGEO data, you could set the SOP Import to handle "Packed Primitives" as "Unpack", and you'd probably get more or less the result you expect.
3. retimeinstances_doesnt_work doesn't work, in part, because you are pointing it at the wrong primitive. You need to set the Instances parameter to /geoclipsequence_noTimeDep_usd and then you can see the SdfLayerOffset on the Reference set on that prim has an offset of -3.1. Now this still accomplishes nothing because that reference is to the _topology_ file of the value clip. By definition, the non-animated stuff. So adjusting the timing of the non-animated stuff does nothing. This reveals a major underlying issue: the Retime Instances LOP retimes things by adjusting the SdfLayerOffset on reference and payload arcs. It knows nothing about value clips, so it cannot explicitly retime a value clip. This also points to a solution - put the value clip (which retime instances cannot retime) behind a reference (which retime instances can retime).
4. This gets us to retimeinstances_seems_to_work, which does indeed work because the instancer1 LOP created those references to the value clip I mentioned in point 3. Retime instances can adjust the SdfLayerOffset on those references and everything works as expected.
As to why you need to turn on "Sample Frame Range" on the geo clip sequence for any of this to work - this is going to be true of any retime instances workflow. The retime instances actually works fine in "current frame" mode, the problem is that you can't _see_ that its working fine if there is only one frame of animation data available at a time. You need to have the full (or at least partial) animation available in a layer for you to see the effect of the SdfLayerOffset set by Retime Instances. If you use a USD ROP to write out a 24 frame USD file with the geo clip sequence set to "current frame" and sublayer in that resulting USD file, you'll see that it actually works just like setting the geo clip sequence to "sample all frames".
Hope that helps clarify some things,
Mark
Solaris and Karma » Geometry Clip Sequence Lop or how to handle large data
- mtucker
- 4441 posts
- Offline
To be clear, you _can_ use a volume LOP and value clips together, but there isn't enough information in your description to provide any useful analysis of why your setup isn't working, and I'm not bothering to ask additional questions about it because in the end I'll still tell you to stop trying to use value clips
Solaris and Karma » Geometry Clip Sequence Lop or how to handle large data
- mtucker
- 4441 posts
- Offline
Definitely use a Volume LOP, and using value clips buys you absolutely nothing in this situation. VDBs are "large geometry", but not in any sense that USD is aware of. USD handles VDBs like texture maps - simple paths to files on disks containing data that only the renderer cares about. Value clips are useful to split large amounts of USD data between multiple USD files on disk. But VDB files are already organized this way, so adding value clips into the mix adds complications to the authoring workflow and provides no advantages to the runtime or rendering.
Solaris and Karma » Geometry Clip Sequence LOP manifest file is not exported
- mtucker
- 4441 posts
- Offline
Great sample file, thanks! I am able to reproduce the problem, and can see that the manifest file under the variant is an "anonymous" layer, even after being written to disk, which should never happen. I'll have to do some researh to figure out why this is happening.
-
- Quick Links