Found 1021 posts.
Search results Show results as topic list.
Solaris and Karma » issues with material changes causing upstream recooks
- mtucker
- 4441 posts
- Offline
Just to follow up from the bug report, the problem is that there is a "Scene Import All" LOP in /stage that is importing the "gloopy" materials. So when these materials are modified the Scene Import All LOP recooks. It seems that the Scene Import All tool should be more selective about how it fills in the "Additional Materials" parameter on that LOP to avoid this common workflow. For now it should be possible to modify this LOP after the fact to either turn off the importing of additional materials or trim down the search pattern (/obj/** for example, if you know all your materials for import will be coming from /obj, or /mat/** if your materials are in /mat).
Solaris and Karma » Retrieving Pixel Data Pre-Save in USD Render ROP Husk Script
- mtucker
- 4441 posts
- Offline
No, I don't believe so, but you can read in the image from the exr file on disk and I think there are command line tools to add/edit metadata in an exr file without altering the image? I'm afraid I don't know what these commands are, but I bet someone else around here does...
Solaris and Karma » Geometry Clip Sequence LOP manifest file is not exported
- mtucker
- 4441 posts
- Offline
Solaris and Karma » About External References in Solaris
- mtucker
- 4441 posts
- Offline
There is a workaround to avoid re-publishing your .bgeo files with the USD Configure SOP. You can force a .bgeo file to be loaded as if it was published with a "time" value from a USD Configure SOP by appending a suffix like ":SDF_FORMAT_ARGS:t=$T". So the file path you put in the geo clip sequence LOP would look something like "/path/to/file.$F4.bgeo.sc:SDF_FORMAT_ARGS:t=$T".
Solaris and Karma » Geometry Clip Sequence Lop or how to handle large data
- mtucker
- 4441 posts
- Offline
The answer to your question is "the geo clip sequence LOP". If it's not working as expected, or not generating results that work for you, then please provide some kind of example/demo file that shows this happening. This is the intended and expected workflow, so if it's not working, we'd like to fix it.
Loading a properly structured value clip into a scene should not cause all the clip files to be opened at once. And the geo clip sequence LOP should always be authoring properly structured value clips.
I did notice you saying that you sublayered the value clip file into your scene, which is a bit unusual. Generally when working with value clips I've seen the referenced onto a stage rather than sublayered. I don't think that should matter, but it might be worth testing...
Loading a properly structured value clip into a scene should not cause all the clip files to be opened at once. And the geo clip sequence LOP should always be authoring properly structured value clips.
I did notice you saying that you sublayered the value clip file into your scene, which is a bit unusual. Generally when working with value clips I've seen the referenced onto a stage rather than sublayered. I don't think that should matter, but it might be worth testing...
Solaris and Karma » Layer has cycles warning
- mtucker
- 4441 posts
- Offline
That's not a lot to go on... I can only say that I've never seen USD complain about cycles when there weren't cycles.
Can you provide an example? USD file? Hip file?
Can you provide an example? USD file? Hip file?
Solaris and Karma » Primvars indices written as blocked
- mtucker
- 4441 posts
- Offline
Yes, we do this exactly for the reason given by @tamte...
What cases have you seen where blocking the indices attribute has caused problems?
What cases have you seen where blocking the indices attribute has caused problems?
Solaris and Karma » Clone Control Panel - save images?
- mtucker
- 4441 posts
- Offline
One of the big use cases we see for clones is having a single local clone that is exactly following the current session. i.e. Having a background process doing your continuous karma interactive render of your whole scene, while you work in the OpenGL viewport. So I do think you might find that style of cloning useful. Especially if you have access to a render farm so that interactive karma render could be running on a different machine...
Once the clone can be "snapshotted", you can already RMB-click on a snapshot in the gallery and say "open in file browser" which takes you to the image on disk (render gallery entries are just exr files on disk). What I was saying is basically that the render product name will be ignored because the full generality of what husk can do with this information is a lot more than we would want to try to manage just because the user hits "snapshot" (generating and trying to display 100 separate exrs in the snapshot gallery would be a UI nightmare).
So no, this isn't a render queue, and if that's what you're looking for clones aren't the answer. For what you're looking for, what is missing from the current ROP based workflows (just hit Render in Background on a USD Render ROP when you want to generate a non-updating test render)?
Once the clone can be "snapshotted", you can already RMB-click on a snapshot in the gallery and say "open in file browser" which takes you to the image on disk (render gallery entries are just exr files on disk). What I was saying is basically that the render product name will be ignored because the full generality of what husk can do with this information is a lot more than we would want to try to manage just because the user hits "snapshot" (generating and trying to display 100 separate exrs in the snapshot gallery would be a UI nightmare).
So no, this isn't a render queue, and if that's what you're looking for clones aren't the answer. For what you're looking for, what is missing from the current ROP based workflows (just hit Render in Background on a USD Render ROP when you want to generate a non-updating test render)?
Solaris and Karma » Solaris - How to Export Animated Cameras and Geo?
- mtucker
- 4441 posts
- Offline
Solaris and Karma » Clone Control Panel - save images?
- mtucker
- 4441 posts
- Offline
No, clones are meant to be interactive renders like in the viewport in your current Houdini session. There is no way to save the resulting images to disk as husk is able to do. However we do have it on the roadmap to allow you to "snapshot" clone renders and preserve them in the render gallery. But the AOVs will al be saved to a single EXR in a Houdini-chosen location, just like snapshots of viewport renders.
Solaris and Karma » Exclusive primitive selection pattern
- mtucker
- 4441 posts
- Offline
Perhaps you want to apply transforms to various levels of the scene graph tree within a single SOP Modify LOP? Also, if we were to provide safeguards, should we exclude duplicates by taking the prims as high up the hierarchy or as low down the hierarchy as possible? Using the "noancestors" and "nodescendants" auto-collections lets the user decide exactly how duplicates should be avoided.
That said, I wouldn't be against a menu on the LOP Import SOP that gives options like "Match Primitive Pattern Exactly"/"Remove Duplicate Ancestor Prims"/"Remove Duplicate Descendant Prims" if someone thinks that's worth an RFE.
That said, I wouldn't be against a menu on the LOP Import SOP that gives options like "Match Primitive Pattern Exactly"/"Remove Duplicate Ancestor Prims"/"Remove Duplicate Descendant Prims" if someone thinks that's worth an RFE.
Solaris and Karma » Exclusive primitive selection pattern
- mtucker
- 4441 posts
- Offline
/scene/anim/letty/** will bring in /scene/anim/letty/geo. Which means that not only will all of tempGeo be brought in as part of the "geo" packed prim, but every other piece of geometry under /geo will be brought in twice (once as part of the "geo" packed prim, and again as "geo/eyes", "geo/frames", etc. Generally speaking using "**" in LOP Import patterns is going to make things difficult to control because the matching can happen at many levels of the hierarchy, and matching a higher level prim will effectively bring in all lower level prims, and you'll almost definitely end up doubling up on geometry.
One way out of this (if you can't find a nice clean pattern that avoids using "**") is to use the "%noancestors" auto-collection to modify your pattern. I think "%noancestors(/scene/anim/letty/** - /scene/anim/letty/geo/tempGeo**)" might give you what you want by only returning "leaf" primitives matching that overly-inclusive pattern. But I may also be wrong about this This pattern stuff can be very difficult to reason about in your head without making mistakes. I should say "difficult to reason about in MY head". I don't mean to cast aspersions on anyone else.
One way out of this (if you can't find a nice clean pattern that avoids using "**") is to use the "%noancestors" auto-collection to modify your pattern. I think "%noancestors(/scene/anim/letty/** - /scene/anim/letty/geo/tempGeo**)" might give you what you want by only returning "leaf" primitives matching that overly-inclusive pattern. But I may also be wrong about this This pattern stuff can be very difficult to reason about in your head without making mistakes. I should say "difficult to reason about in MY head". I don't mean to cast aspersions on anyone else.
Solaris and Karma » USD stitch clips: possible bug!
- mtucker
- 4441 posts
- Offline
The solution is to stop using the USD Stitch Clips ROP and used the Geometry Clip Sequence LOP to author your value clips instead Then the USD ROP or the Configure Layer LOP can be used to set the FPS/TCPS values on the value clip layer just like any other USD layer. Plus the Geometry Clip Sequence LOP is (I think) better than using the USD Stitch Clips ROP in a variety of other ways too...
Solaris and Karma » Overriding Unpacked Primitives
- mtucker
- 4441 posts
- Offline
I don't know how you're composing all these opinions, but my best guess is that the anim dept is (accidentally) authoring opinions that are ending up stronger than the CFX opinions and masking the changes CFX is trying to make. You might want to look at the layer stack in the scene graph details pane to see what layers are contributing opinions to the geometry that CFX is trying (and failing) to override. Then you'll probably have to adjust your Anim tooling to avoid publishing these unintended stronger opinions.
Solaris and Karma » How to create an animation binding in Solaris?
- mtucker
- 4441 posts
- Offline
I was going to say you can use an Edit Properties LOP, drag the "animationSource" attribute from the "Schemas/SkelBindingAPI" folder on the "From USD" tab in the far left panel of the Edit Parameter Interface dialog... But it seems that this doesn't apply the API schema. Adding the "geomBindTransform" primvar applies the API schema, so there may be something wrong with how Relationships are brought in from that pane? In the meantime, you can edit the "skel:animationSource" parameter that gets created by adding the "usdapischema" tag with a value of "SkelBindingAPI". Then when you set the animationSource parameter, it will set the relationship and apply the SkelBindingAPI schema. Basically what your python code above is doing.
I'll look into the bug about the SkelBindingAPI schema not being applied automatically.
I'll look into the bug about the SkelBindingAPI schema not being applied automatically.
Solaris and Karma » Adding external file to a USD layer
- mtucker
- 4441 posts
- Offline
Ah, okay. So how are these FBX files referred to by the USD file?
- Have you got a file format plugin that is loading the FBX files into the USD scene graph?
- Or do you just have custom attributes on prims that hold paths to FBX files on disk?
- If they are attributes, are they of type "string" or "SdfAssetPath"?
Solaris and Karma » Solaris Large Scene question / best practices?
- mtucker
- 4441 posts
- Offline
Sorry if this is a silly question, but you know references and payloads are very specific and separate things, right? The Refrence LOP lets you choose whether to "reference" the file on disk or "payload" the file on disk. If you are "referencing" the files on disk then you have no payloads in your scene, so "unloading payloads" won't do anything. Unless the files you are referencing into your scene have payloads inside them. In which case I'm not sure why you'd be having trouble unloading them...
Solaris and Karma » Solaris Large Scene question / best practices?
- mtucker
- 4441 posts
- Offline
2. The Material Library LOP will author time-varying attributes on shaders, but you have to explicitly enable "Allow Shader Parameter Animation" on the Material Library LOP. The way you described with a Material Library followed by an Edit Material Properties LOP is going to be much faster to cook because it doesn't require regenerating the material from the VOP network on every frame - just running the edit materials property LOP to set one attribute on the otherwise-unchanging material prims.
Merges are fine for combining a bunch of References into a single scene graph, but I'd suggest using the Flatten Layers Merge Style so you don't end up with a separate sublayer for bringing in each referenced asset. The other option is to just chain the Reference LOPs together. The end result will be the same and the performance will be very similar, so it's really a question of how you want to build and lay out your network. You can also mix and match with some chaining and some Merges.
Solaris has the Loft Payload Info LOP for adding extent information to any primitive with a payload specified on it. If you are payloading in your substance assets, this LOP should let you see bounding boxes for the assets when you unload the payloads. I assume this is the behavior you're interested in?
Merges are fine for combining a bunch of References into a single scene graph, but I'd suggest using the Flatten Layers Merge Style so you don't end up with a separate sublayer for bringing in each referenced asset. The other option is to just chain the Reference LOPs together. The end result will be the same and the performance will be very similar, so it's really a question of how you want to build and lay out your network. You can also mix and match with some chaining and some Merges.
Solaris has the Loft Payload Info LOP for adding extent information to any primitive with a payload specified on it. If you are payloading in your substance assets, this LOP should let you see bounding boxes for the assets when you unload the payloads. I assume this is the behavior you're interested in?
Solaris and Karma » Animated Volume Stuttering in Render - Solaris/Redshift
- mtucker
- 4441 posts
- Offline
If karma renders without the jitter then perhaps it's an issue with Redshift.
I also noticed that the Volume LOP had "Generate errors for missing files" turned off - are you sure that the file names match the ones on disk, and there aren't any files missing? You can inspect the generated USD file to make sure that the Volume LOP is authoring the right VDB file name at every frame in the sequence.
Those are the only suggestions I can think to make without a sample file to let us reproduce the problem.
I also noticed that the Volume LOP had "Generate errors for missing files" turned off - are you sure that the file names match the ones on disk, and there aren't any files missing? You can inspect the generated USD file to make sure that the Volume LOP is authoring the right VDB file name at every frame in the sequence.
Those are the only suggestions I can think to make without a sample file to let us reproduce the problem.
Solaris and Karma » Adding external file to a USD layer
- mtucker
- 4441 posts
- Offline
Gets copied where? And when? What operation are you expecting to cause the FBX file to get copied somewhere?
-
- Quick Links