Found 1017 posts.
Search results Show results as topic list.
Solaris and Karma » Remove a USD attribute from the layer it is defined?
- mtucker
- 4435 posts
- Offline
If you know that you're still editing the same layer where the attribute was originally defined, there are Sdf APIs to clear a property setting from an SdfLayer (and you can use a Python LOP to invoke these). With nodes, the closest you can get it using an Edit Properties node to Block an attribute. But I think that will author an explicit block, hiding lower strength opinions rather than revealing them as would happen if you cleared the opinion on the active layer. My concern with exposing this as a node based operation is that there are so many situations in which this won't do the expected thing (because opinions are authored in layers other than the active one).
Solaris and Karma » Issue of reading values in LOP
- mtucker
- 4435 posts
- Offline
This is an issue with the transient nature of context options set in the LOP network. The For Each LOP sets a context option, ITERATIONVALUE, which is used to cook each iteration of the second input. But if you just evaluate the nodes inside the for each loop, ITERATIONVALUE isn't being set. It's only set when cooking the For Each loop. This situation has been improved for the next major release of Houdini, in that LOP nodes will at least remember the last context option values used to cook the node. If the option isn't being explicitly set anywhere, the last-used value will be reused, making for more predictable, stable results when looking at nodes inside a for each loop. Though it is still not perfect, since only LOP nodes are made to use the “last used” context option values… When diving into the SOP Network, Houdini can still lose track of the context options used on the last cook…
Solaris and Karma » Does Solaris respect fps metadata on a layer
- mtucker
- 4435 posts
- Offline
My understanding (from reading the descriptions of GetFramesPerSecond and GetTimeCodesPerSecond) is that FPS is a non-binding suggestion to help auto-configure a playbar in a DCC app. We do not surrently make use of that value anywhere in Houdini, but if we did, it would be to drive the Houdini playbar's FPS value when the viewport's “Stage frame range drives playbar range” toggle is turned on. But given the consistency within a show for this value, this hasn't been an issue so far.
The TCPS is, if I'm reading it right, a value that USD should internally be using to scale time code values to seconds. But the more I think about it, the less likely that seems… Because all the USD APIs take UsdTimeCode objects to specify the time, the conversion from “seconds” to “time codes” must be expected to be done by the DCC. At the moment Houdini assume TimeCodes == Frames everywhere, but technically we should probably convert Frame -> Time (using the Houdini playbar FPS, possibly driven by the USD stage FPS), then Time -> Time Codes (driven by the TCPS of the stage we are dealing with).
Of course this doesn't help if you load in a USD file with a TCPS that doesn't match the TCPS of the overall stage. Unless USD takes care of the time scaling in this case, which I'm not sure if it does or not. But USD does provide (and Houdini lets you set) the Time Scale/Time Offset values used when sublayering or referencing a file, so that would be my recommendation right now for cases wher TCPS != FPS: set a Time Scale when loading in these layers such that the scaled TCPS == FPS.
I'll make myself an RFE to investigate this further and see if we should in fact be doing something other than using Frames==TimeCodes, and possibly driving the playbar FPS from the stage FPS if that viewport toggle is turned on. Thanks for bringing this up, and let me know if you think I've missed anything.
The TCPS is, if I'm reading it right, a value that USD should internally be using to scale time code values to seconds. But the more I think about it, the less likely that seems… Because all the USD APIs take UsdTimeCode objects to specify the time, the conversion from “seconds” to “time codes” must be expected to be done by the DCC. At the moment Houdini assume TimeCodes == Frames everywhere, but technically we should probably convert Frame -> Time (using the Houdini playbar FPS, possibly driven by the USD stage FPS), then Time -> Time Codes (driven by the TCPS of the stage we are dealing with).
Of course this doesn't help if you load in a USD file with a TCPS that doesn't match the TCPS of the overall stage. Unless USD takes care of the time scaling in this case, which I'm not sure if it does or not. But USD does provide (and Houdini lets you set) the Time Scale/Time Offset values used when sublayering or referencing a file, so that would be my recommendation right now for cases wher TCPS != FPS: set a Time Scale when loading in these layers such that the scaled TCPS == FPS.
I'll make myself an RFE to investigate this further and see if we should in fact be doing something other than using Frames==TimeCodes, and possibly driving the playbar FPS from the stage FPS if that viewport toggle is turned on. Thanks for bringing this up, and let me know if you think I've missed anything.
Solaris and Karma » Prune Deactivate
- mtucker
- 4435 posts
- Offline
Thanks @alexwheezy.
I'm pretty sure @jsmack is right, that this problem was introduced by that “automatically prune ancestors” option on the prune, which was added after the 18.0 release.
As to the suggestion of auto-unpruning, that's a very dangerous game. Either you unprune all the ancestors of the prim you are about to create (in which case you risk loading in a dangerously large amount of scene graph), or you unprune your direct ancestors, but prune siblings instead so that only the minimal set of stuff gets activated. But in that case, re-activating things becomes a _lot_ more complicated.
I'm pretty sure @jsmack is right, that this problem was introduced by that “automatically prune ancestors” option on the prune, which was added after the 18.0 release.
As to the suggestion of auto-unpruning, that's a very dangerous game. Either you unprune all the ancestors of the prim you are about to create (in which case you risk loading in a dangerously large amount of scene graph), or you unprune your direct ancestors, but prune siblings instead so that only the minimal set of stuff gets activated. But in that case, re-activating things becomes a _lot_ more complicated.
Solaris and Karma » Prune Deactivate
- mtucker
- 4435 posts
- Offline
Could you indicate which example file exactly? Was it used in a tutorial, or mentioned in a video? And if so, could you indicate where? This does not seem like something we should be doing, unless, as you say, iot is to show you what _not_ to do, in which case that should be made clear… Thanks!
Solaris and Karma » Prune Deactivate
- mtucker
- 4435 posts
- Offline
As is often the case, the USD Glossary provides a good (if dense) description of prim deactivation: https://graphics.pixar.com/usd/docs/USD-Glossary.html#USDGlossary-Active/Inactive [graphics.pixar.com]
Because USD doesn't compose (or really even look) inside deactivated prims, it also can't add or edit prims inside a deactivated branch. Deactivating a branch provides a performance advantage over simply making a branch invisible, with the downside that the deactivated portion of your scene graph becomes “off limits”.
Because USD doesn't compose (or really even look) inside deactivated prims, it also can't add or edit prims inside a deactivated branch. Deactivating a branch provides a performance advantage over simply making a branch invisible, with the downside that the deactivated portion of your scene graph becomes “off limits”.
Solaris and Karma » Solaris materials and lighting workflows -after sublayering
- mtucker
- 4435 posts
- Offline
3. The Light LOP can work in “Create” or “Edit” mode. In edit mode, it can be used to make edits to an existing light. If you right click on the light prim in the scene graph tree and choose “Edit Primitive -> New node” from the context menu, it will create the Light LOP for you, set to edit mode, pointed at the light prim, and with all the options set to “do nothing” by default. You can also use a Light Mixer node to tweak existing lights.
4. If you used Parameter VOPs or Bind VOPs to “promote” the settings you want to control onto the UsdShadeMaterial prim, you can again use RMB -> Edit Primitive to create an Edit Properties pointed at the Material prim, and with parameters for controlling all the parameters you promoted onto the material. For larger reorganizations of the shader, in some situations you can use a Material Edit node to instantiate a VOP network that describes the shader, and applies edits to the UsdShadeShader primitives. The “some situations” means this works reasonably well for UsdPreviewSurface shader networks, and RenderMan shader networks, and it may work for some other third party shader networks. But unfortunately at the moment Karma shaders cannot be reconsituted this way by the Material Edit not because Karma shaders are expressed as blocks of source code, not networks of nodes.
4. If you used Parameter VOPs or Bind VOPs to “promote” the settings you want to control onto the UsdShadeMaterial prim, you can again use RMB -> Edit Primitive to create an Edit Properties pointed at the Material prim, and with parameters for controlling all the parameters you promoted onto the material. For larger reorganizations of the shader, in some situations you can use a Material Edit node to instantiate a VOP network that describes the shader, and applies edits to the UsdShadeShader primitives. The “some situations” means this works reasonably well for UsdPreviewSurface shader networks, and RenderMan shader networks, and it may work for some other third party shader networks. But unfortunately at the moment Karma shaders cannot be reconsituted this way by the Material Edit not because Karma shaders are expressed as blocks of source code, not networks of nodes.
Solaris and Karma » hou.LopSelectionRule available outside of a node context?
- mtucker
- 4435 posts
- Offline
Yep. When evaluating a selection rule you have to give it a LOP node (so it has a stage to traverse and find matches), but the LopSelectionRule itself can live independent from any LOP nodes.
Solaris and Karma » Extract layer name
- mtucker
- 4435 posts
- Offline
render_dude
What I would like is to grab the layer stack values in the Solaris desktop (Scene Graph Details -> Layer Stack) without using the Solaris desktop (the USD files are large, and switching to Solaris consumes all the memory, most likely trying to populate the Scene Graph Details pane).
It is very unlikely to be the scene graph details or scene graph tree panes at fault. I've only ever seen the viewport take up large amounts of memory. So you could just add a scene graph tree and scene graph details pane to the current desktop if the information you want is already available in those panes.
But getting back to your python question, ext.GetPropertyStack returns a list, so the next line gives me an error:
AttributeError: ‘list’ object has no attribute ‘layer’
If I change that code to:
layers = list(entry.layer.realPath for entry in stack)
print layers, f*ts + to
I get reasonable looking results. Of course I can't vouch for what you'd be seeing without access to your USD files…
Solaris and Karma » Merge LOP order after SOP Create in reference mode
- mtucker
- 4435 posts
- Offline
Solaris and Karma » Farm Rendering with Solaris
- mtucker
- 4435 posts
- Offline
Solaris and Karma » Lops Instancers : Random start frame offset animated cache
- mtucker
- 4435 posts
- Offline
The Retime Instances LOP is the easiest way to provide a random starting frame for animations, but you'll want to use a Reference LOP pointed directly at your Alembic file rather than SOP Importing Alembic geometry loaded into SOPs. The added level of indirection makes retiming more challenging (or impossible), as well as being less efficient.
Texture variation can be added using a primvar on the point instancer, along with a shader that exposes the texture parameter through a primvar reader. The easiest way to set a per-instance primvar is in the point instancer LOP, add a SOP point attribute with the name you want to give the primvar, then on the Point Instancer LOP, specify this Point Attribute to Import.
Texture variation can be added using a primvar on the point instancer, along with a shader that exposes the texture parameter through a primvar reader. The easiest way to set a per-instance primvar is in the point instancer LOP, add a SOP point attribute with the name you want to give the primvar, then on the Point Instancer LOP, specify this Point Attribute to Import.
Solaris and Karma » Merge LOP order after SOP Create in reference mode
- mtucker
- 4435 posts
- Offline
Fantastic sample file. I suspect this hasn't come up before because I think it's relatively uncommon for a single prim to have multiple references added to is from multiple SOP sources in sequence this way. Or if it is done, I think usually there wouldn't be any overlap between the contributions of the SOP Networks (so the strength order wouldn't matter). Anyway, I think you're absolutely right that this should be controllable with a parameter on the SOP Import. While I'm at it I'll add the ability to choose between a Reference and a Payload (which I'f fairly suprised nobody has ever asked about).
Solaris and Karma » Farm Rendering with Solaris
- mtucker
- 4435 posts
- Offline
Thanks everyone. I'm fully convinced now that there needs to be a check box (on both the USD and USD Render ROPs) to control the behavior around Layer Breaks. I think the only question is what the defaults should be. Unless there is a strong argument against it, I would leave the defaults such that current behavior is preserved (strip layers for the USD ROP, don't strip layers for USD Render)…
Solaris and Karma » Farm Rendering with Solaris
- mtucker
- 4435 posts
- Offline
I'm with jsmack Why would you have Layer Breaks other than to restrict what data is written out by a USD ROP? There are cases where you branch from a node with a layer break on one branch (such as in for each loops, or add variant operations), but in my experience you would always merge those branches back together before reaching the USD ROP, meaning the operation of the ROP is unaffected by the Layer Break.
As in the hip file posted above you may have a layer break so that you can _choose_ to write out the post-break USD to a separate file while also wanting to be able to do renders of the fully composed scene. If the default was to write out the fully composed scene, that would be saying that by default layer breaks should do nothing, which seems weird… USD Render ignores layer breaks by default so that WYSIWYG when comparing to the viewport. Though maybe USD Render also needs a toggle to apply layer breaks instead of ignoring them…
As in the hip file posted above you may have a layer break so that you can _choose_ to write out the post-break USD to a separate file while also wanting to be able to do renders of the fully composed scene. If the default was to write out the fully composed scene, that would be saying that by default layer breaks should do nothing, which seems weird… USD Render ignores layer breaks by default so that WYSIWYG when comparing to the viewport. Though maybe USD Render also needs a toggle to apply layer breaks instead of ignoring them…
Solaris and Karma » Crowds in Solaris/Lops/USD
- mtucker
- 4435 posts
- Offline
And thank you for your patience
There's defeinitely a lot of new stuff hitting you all at once here. But I sincerely believe the end result will be easier to use than mantra with style sheets, once we get the kinks worked out…
If you are familiar with style sheets, you should also look at the Assign Material LOP. It can be a bit overwhelming, but it actually provides a lot of stylesheet-like functionality where you can use CVEX to create material parameter overrides, which are used to automatically create new materials with those parameter values, and assign the materials to the geometry all in one node.
There's defeinitely a lot of new stuff hitting you all at once here. But I sincerely believe the end result will be easier to use than mantra with style sheets, once we get the kinks worked out…
If you are familiar with style sheets, you should also look at the Assign Material LOP. It can be a bit overwhelming, but it actually provides a lot of stylesheet-like functionality where you can use CVEX to create material parameter overrides, which are used to automatically create new materials with those parameter values, and assign the materials to the geometry all in one node.
Solaris and Karma » Farm Rendering with Solaris
- mtucker
- 4435 posts
- Offline
Also, I think option 2 definitely makes the most sense. The USD ROP gives you the most control over how and where your USD gets authored (aside from this layer break issue). And even if you don't need that control right now, I suspect at some point you will…
Solaris and Karma » Farm Rendering with Solaris
- mtucker
- 4435 posts
- Offline
Ah yes, now I see where that is happening… At the moment there is nothing you can do to make one behave like the other other than, as you suggest, bypassing all the lay break LOPs. You can RMB on your layer break nodes, and under Parameters and Channels choose “Create Activation Parameter”. Then in that activation parameter use a context option expression (@saving==0). Set “saving = 0” as a global context option, then on your USD ROP add a context option value of “saving = 1”, which should deactivate the layer breaks during the save to disk.
But that seems like it should be unnecessary. I'll talk to some people here. Probably the USD ROP should just have a checkbox to ignore layer breaks…
But that seems like it should be unnecessary. I'll talk to some people here. Probably the USD ROP should just have a checkbox to ignore layer breaks…
Solaris and Karma » Crowds in Solaris/Lops/USD
- mtucker
- 4435 posts
- Offline
That last file was enough to make the hip file load and run and show some crowd agents. I changed the trouser and shirt materials to show solid colors instead of textures (because I don't have your texture files). Then I changed the vary material assignment node to affect both crowd agents, and choose between the trouser and shirt materials to be assigned to the trousers of each agent. This seems to work, although there are update issues with Houdini GL if you change the seed to re-randomize the assignments (already fixed for 18.5 FWIW).
In the specific case of the flags, you need to either use a path attribute at the SOP level to split the flag into multiple meshes, or you need to create groups at the SOP level, and import those groups as Geometry Subsets in the SOP Import LOP so that you can assign materials to each flag separately.
All that to say you were pretty close… The update failures I'm sure were a major impediment, though karma may do a better job of handling the updates…
I'm attaching a zip file with all files in the right places, and some paths updated in the hip file to refer to $HIP and make sure all the bits and pieces work together without needing to access anything outside the zip file. I hope you don't mind me re-posting your stuff - it's nothing you didn't already post, I just moved some files around…
In the specific case of the flags, you need to either use a path attribute at the SOP level to split the flag into multiple meshes, or you need to create groups at the SOP level, and import those groups as Geometry Subsets in the SOP Import LOP so that you can assign materials to each flag separately.
All that to say you were pretty close… The update failures I'm sure were a major impediment, though karma may do a better job of handling the updates…
I'm attaching a zip file with all files in the right places, and some paths updated in the hip file to refer to $HIP and make sure all the bits and pieces work together without needing to access anything outside the zip file. I hope you don't mind me re-posting your stuff - it's nothing you didn't already post, I just moved some files around…
Solaris and Karma » Farm Rendering with Solaris
- mtucker
- 4435 posts
- Offline
I do not recall writing any code, nor do I see any code that indicates that the USD Render ROP does anything special related to Layer Breaks. Which doesn't mean it isn't, but if you could provide a sample file that would help…
Also the USD Render ROP does the equivalent of “flatten all layers”, not “flatten stage”. Flatten stage is going to make enormous files by bringing all referenced data into the one uber-file. This is useful if your farm machines don't have access to the same network paths as the machines authoring the USD. Or if you are worried about the referenced content changing (and you don't have a versioning system in place). But if you have a common set of shared paths, and aren't worried about the referenced files being changed unexpectedly before the render happens, I'd recommend using “flatten all layers” to keep the USD files smaller.
Also the USD Render ROP does the equivalent of “flatten all layers”, not “flatten stage”. Flatten stage is going to make enormous files by bringing all referenced data into the one uber-file. This is useful if your farm machines don't have access to the same network paths as the machines authoring the USD. Or if you are worried about the referenced content changing (and you don't have a versioning system in place). But if you have a common set of shared paths, and aren't worried about the referenced files being changed unexpectedly before the render happens, I'd recommend using “flatten all layers” to keep the USD files smaller.
-
- Quick Links