SOP Import/Create have a "Define Only Leaf Primitives" toggle, which will only create Gprims with overs on all of the ancestor prims. Alternatively there is an "Other Primitives" toggle to control things as well.
https://www.sidefx.com/docs/houdini/nodes/lop/sopimport.html#prim_def [www.sidefx.com]
Found 681 posts.
Search results Show results as topic list.
Solaris and Karma » How do I link geometry to a camera in solaris?
- goldleaf
- 4177 posts
- Online
Solaris and Karma » Adding custom "Kind"
- goldleaf
- 4177 posts
- Online
It's done using USD's plugin mechanism, but doesn't require any compiling. You register additional kinds via the
Here are some links for more details/examples:
plugInfo.json
and add it's directory to $PXR_PLUGINPATH_NAME
. As long as that env var has the directory to your plugin folder, Solaris will include your custom kinds in the kind-based menus/parameters (i.e. Kind-based selections, Here are some links for more details/examples:
- Extending the Kind Registry [graphics.pixar.com] - USD Docs
- USD Cookbook - Subclass Your Own Kind [github.com] - Colin Kennedy
Solaris and Karma » VOP -> light texture input?
- goldleaf
- 4177 posts
- Online
Solaris and Karma » Can I change Reference play back from 24 fps to 30 fps?
- goldleaf
- 4177 posts
- Online
I suspect that in the sublayer case, there is no other layer setting the FPS so it's just using that when it's playing back; though I'm not sure if that should be considered a bug or not...
USD linearly interpolates values, so the time-scale will be linear, though whether it's smooth or not is hard to guess without seeing any results. But if you're referencing files with different FPS, time scale is probably the best bet (apart from re-authoring the files to export at an expected frame rate).
Is there a reason you're mixing USD layers generated at different rates? I would expect if you don't want 24FPS that you'd set it in your hip file. All project files for the same show/productionproject should probably use the same FPS for all of it's layers/exports (even if there are some cases where you would cache out additional sub-frame time samples for motion blur reasons).
USD linearly interpolates values, so the time-scale will be linear, though whether it's smooth or not is hard to guess without seeing any results. But if you're referencing files with different FPS, time scale is probably the best bet (apart from re-authoring the files to export at an expected frame rate).
Is there a reason you're mixing USD layers generated at different rates? I would expect if you don't want 24FPS that you'd set it in your hip file. All project files for the same show/productionproject should probably use the same FPS for all of it's layers/exports (even if there are some cases where you would cache out additional sub-frame time samples for motion blur reasons).
Technical Discussion » NVIDIA RTX 3050 compatibility (desktop version)
- goldleaf
- 4177 posts
- Online
From the System Requirements page:
https://www.sidefx.com/Support/system-requirements/supported-graphics-cards/
[www.sidefx.com]
I imagine an RTX 3050 will work fine fine.
It's probably the driver version. I have an RTX 3070 running Linux Mint 20.3 (based on Ubuntu 20.04), and I upgraded to the 510 series of driver. I thought the minimum driver version was 495 on Linux, in order to have a new enough cut of the Optix library XPU relies on.
Houdini requires an OpenGL 4.0 compliant graphics card. 4GB VRAM or more is required.
If a card is not on our supported list, it does not mean that it will not work with Houdini. Cards that meet the requirements (4GB or more of VRam, GL4.0 compliant, OpenCL 1.2 support) should still work. We just haven't been able to obtain the card to certify it.
https://www.sidefx.com/Support/system-requirements/supported-graphics-cards/
[www.sidefx.com]
I imagine an RTX 3050 will work fine fine.
Enivob
I can verify that Karma XPU does not leverage this card on H 19.0.561. It does show up under the Preferences as a detectable GPU, however.
It's probably the driver version. I have an RTX 3070 running Linux Mint 20.3 (based on Ubuntu 20.04), and I upgraded to the 510 series of driver. I thought the minimum driver version was 495 on Linux, in order to have a new enough cut of the Optix library XPU relies on.
Technical Discussion » Icon for digital assets.
- goldleaf
- 4177 posts
- Online
Solaris and Karma » About usd animation cache and virtual memory
- goldleaf
- 4177 posts
- Online
Just a comment on USD animation caches in general (value clips or single-file): You can use the "Set Default Values" to specify attributes that you know aren't animated, which should cut down on file sizes and memory use. Think of "Default Values" as "Static Values". The name is unfortunate and not intuitive right-away, but this is how USD labels/identifies values that aren't animated (i.e. time sampled). It's also a good idea in USD to make sure you aren't importing unnecessary attributes - if you are caching out animation, and you have lots of attributes from vellum/kinefx/etc... (especially string attrs) you can make your USD files very large.
We don't yet have a way to handle mixed static/animated cases automatically yet; it's something we're aware of, but this might help make your USD Exports and Value Clips a bit easier to work with.
We don't yet have a way to handle mixed static/animated cases automatically yet; it's something we're aware of, but this might help make your USD Exports and Value Clips a bit easier to work with.
Solaris and Karma » LOPs cache node and save-paths
- goldleaf
- 4177 posts
- Online
The cache lop isn't required for writing to USD, but it helps for interaction in LOPs (and things like motion blur, while in the GUI). What node are you feeding into the Cache LOP? Or which node is following the Cache? That's probably why it's trying to generate a save path; but a hip file would help.
Solaris and Karma » Subdivision Workflow
- goldleaf
- 4177 posts
- Online
FWIW, "Complexity" in USD (usdview, husk; it's Level of Detail in HoudiniGL's display settings) is a global subdivision level (at least in the basic sense; there may be subtleties to OpenSubdiv). Roughly, it appears that the complexities map to subdiv levels (at least in Storm - I think Karma/Prman are probably very high / adaptive all the time):
Hope this helps a bit; but @antc is right that it'd be hard to generalize to every renderer. Some delegates ignore the built-in subdivision attributes of meshes, and just look for their own properties on the prims.
- Low - None
- Medium - 1 level
- High - 2 levels
- Very High - 3 levels
Hope this helps a bit; but @antc is right that it'd be hard to generalize to every renderer. Some delegates ignore the built-in subdivision attributes of meshes, and just look for their own properties on the prims.
Solaris and Karma » Best way to hide faces/polygons from mesh in Solaris?
- goldleaf
- 4177 posts
- Online
When a mesh is turned into a subdiv, holeindices work. Because most characters are subdivs, that's what I've seen used in production.
For meshes/polygons, displayOpacity could work, but a material applied to a geomsubset should also work.
For meshes/polygons, displayOpacity could work, but a material applied to a geomsubset should also work.
Solaris and Karma » Kind using component builder
- goldleaf
- 4177 posts
- Online
Component Builder is setup to make a single component with a payload, not nested assemblies, groups, and components. If you wanted that entire Alembic file to be a component asset, try putting your Alembic SOP inside of the Component Geometry LOP and unpack it, and see if that gives you what you're after?
Solaris and Karma » get collections from selected prim with python
- goldleaf
- 4177 posts
- Online
The unit tests on Github have a lot of really good examples for the Python API: https://github.com/PixarAnimationStudios/USD/blob/v21.08/pxr/usd/usd/testenv/testUsdCollectionAPI.py [github.com]
As does Colin Kennedy's website: https://github.com/ColinKennedy/USD-Cookbook [github.com]
As does Colin Kennedy's website: https://github.com/ColinKennedy/USD-Cookbook [github.com]
Solaris and Karma » Karma cryptomatte data doesnt load in Fusion
- goldleaf
- 4177 posts
- Online
I completely forgot, but this is likely because Fusion and/or Fusion's Cryptomatte plugin doesn't support the "newer" EXR format (it was introduced around 2013, I'm told).
You can append
Does this help?
You can append
--exrmode 0
to your husk command, either in the commandline or on the USD Render ROP go to the "Driver" tab and add the flag there.Does this help?
Solaris and Karma » Physical Lens Exposure slider
- goldleaf
- 4177 posts
- Online
Those both seem like bugs, the latter being a bug in Scene Import.
Would you mind logging an issue for each of those, with a simple hip file if possible?
Thanks!
Would you mind logging an issue for each of those, with a simple hip file if possible?
Thanks!
Solaris and Karma » MaterialX | Importing Node Definitions/Graphs
- goldleaf
- 4177 posts
- Online
The only mechanism we currently have for importing MaterialX is the UsdMtlX format plugin, which lets you reference MtlX materials out of the xml-based .mtlx files, and into USD.
The Lama nodes should import into USD fine, but I'm not sure how well, if at all, they will render with Karma just yet. Those were added to a version of MaterialX after H19 was released.
The way to export to a .mtlx file currently is via the RMB menu (see screenshot). I haven't personally used this feature at all though.
Hope this helps, sorry if I misunderstood the questions!
The Lama nodes should import into USD fine, but I'm not sure how well, if at all, they will render with Karma just yet. Those were added to a version of MaterialX after H19 was released.
The way to export to a .mtlx file currently is via the RMB menu (see screenshot). I haven't personally used this feature at all though.
Hope this helps, sorry if I misunderstood the questions!
Solaris and Karma » USD pipelines and file locking
- goldleaf
- 4177 posts
- Online
From what I've seen, this isn't a USD-only problem, but also affects other binary file formats like Alembic. Are you able to write to .abc files while they're being read by other users/processes? If so, maybe those solutions/workarounds would work for binary USD files as well.
Solaris and Karma » Karma cryptomatte data doesnt load in Fusion
- goldleaf
- 4177 posts
- Online
Hi, so we had someone internally open an EXR out of Karma, and the Cryptomatte pass displays correctly in the viewer, though the node throws a Lua error (which seems different from the one you described). So it's hard to tell if this is a bug in Fusion's Crytomatte plugin, or if it's a bug with Karma.
If you can put together a hip file showing the Karma/Mantra behaviors and log a bug, that will help us to track the issue (and better determine if there's anything we can do on our end).
If you can put together a hip file showing the Karma/Mantra behaviors and log a bug, that will help us to track the issue (and better determine if there's anything we can do on our end).
Solaris and Karma » SOP geo empty on only some frames generates incorrect USD
- goldleaf
- 4177 posts
- Online
tamtegoldleafwhile it works in LOPs on cache1 node in LOPs, it doesn't seem to be an ideal solution
However, within LOPs proper, Track Visibility does behave as expected.
since the geometry is still present/interpolated on the mesh even if hidden so LOP Import SOP importing back the cache1 lop will see that geo (it would require unpacking and using s@usdvisibility to further delete such geo)
and also if there is some stronger opinion about the visibility later such interpolated or held geo can show up again
would it be more proper to author empty geo time sample for that prim for such cases? I believe Alembic works this way during stitching
That's a great question. At the moment, I can't think of a reason why empty attributes/primvars would be any better/worse than visibility. They may very well be one, but I just can't think of it right now TDs at Pixar have used visibility for these cases, so in that sense it's more "proven". I can also imagine that it's less work to simply author visibility, without necessarily tracking all of the primvars/attributes that might be added. But otherwise, I'm not sure I have a satisfactory reason; perhaps someone else will be able to chime in with a better response.
Solaris and Karma » SOP geo empty on only some frames generates incorrect USD
- goldleaf
- 4177 posts
- Online
Yes it is partially related to interpolation, but it's also because USD doesn't support prims appearing/disappearing from frame to frame. This is because prims appearing/disappearing over time would break composition.
The USD ROP and Cache LOPs support a feature called "Track Primitive Existence to Set Visibility". When enabled, Houdini will keep track of prims that appear/disappear from frame-to-frame. This means on frames when there is no geometry, the prim is still authored but is set to be invisible.
I'm not 100% sure why this parameter isn't available on the USD Export SOP, but even if you unlock the HDA and enable it, the USD Import SOP doesn't seem to like importing back into SOPs for some reason. However, within LOPs proper, Track Visibility does behave as expected.
The USD ROP and Cache LOPs support a feature called "Track Primitive Existence to Set Visibility". When enabled, Houdini will keep track of prims that appear/disappear from frame-to-frame. This means on frames when there is no geometry, the prim is still authored but is set to be invisible.
I'm not 100% sure why this parameter isn't available on the USD Export SOP, but even if you unlock the HDA and enable it, the USD Import SOP doesn't seem to like importing back into SOPs for some reason. However, within LOPs proper, Track Visibility does behave as expected.
Solaris and Karma » usd performance strategy
- goldleaf
- 4177 posts
- Online
Related to the already excellent suggestions: I suggest working to avoid Houdini Time Dependencies wherever possible, especially ones high-up in your node network. These are the bright-green clock badges that show up on nodes in Houdini. The behavior isn't new to Houdini, it's just easier for time-changes to cause pain in LOPs, compared to SOPs. Even innocent nodes like Render Settings, which can be time dependent only to set the product name (file path), can end up causing huge amounts of your LOP network to re-cook on every frame, even if it doesn't need to.
You can reduce/avoid these by using appending a Cache LOP right after one or more time-dependent nodes(set it to cache all frames), or by writing to disk and layering back in.
I'd also recommend going to Edit > Preferences > Lighting, and turning Off the preference "Panes Follow Current Node". While it's convenient sometimes to be able to select a LOP node and see the Scene Graph Tree reflected at that node's position, sometimes the work USD/Solaris have to do, in order to draw that scene graph can lead to some performance issues. With that preference turned off, you need to move the display flag, to inspect the stage at that location in the SG Tree, Viewer, SG Details, etc...
You can reduce/avoid these by using appending a Cache LOP right after one or more time-dependent nodes(set it to cache all frames), or by writing to disk and layering back in.
I'd also recommend going to Edit > Preferences > Lighting, and turning Off the preference "Panes Follow Current Node". While it's convenient sometimes to be able to select a LOP node and see the Scene Graph Tree reflected at that node's position, sometimes the work USD/Solaris have to do, in order to draw that scene graph can lead to some performance issues. With that preference turned off, you need to move the display flag, to inspect the stage at that location in the SG Tree, Viewer, SG Details, etc...
-
- Quick Links