Hi Adrien,
Can you elaborate a bit more on the context in which you're running Python? Is it in a Python LOP? A Python pane?
If you're in a Python LOP, then `stage = node.editableStage()` should work. If you're in some other context (e.g., a Python pane), then:
1 - make sure you're trying to query the stage from a node (`/stage/some_node`) not the LOP network (`/stage`)
2 - consider `node.stage()` instead of `node.editableStage()` for querying
- Rob
Found 306 posts.
Search results Show results as topic list.
Solaris and Karma » Python : Returning cameras in scene graph Tree
- robp_sidefx
- 453 posts
- Offline
Solaris and Karma » Looping over contextOption values in Python
- robp_sidefx
- 453 posts
- Offline
Hi Tim,
Can you elaborate a bit more on where you're getting stuck?
I'm attaching a simple .hip file where a switch is driven by a context option. Then in a Python Shell I run this:
And get the following output:
It also works for me when dragging the script to the shelf, but I do observe it doesn't work as a Python LOP.
- Rob
Can you elaborate a bit more on where you're getting stuck?
I'm attaching a simple .hip file where a switch is driven by a context option. Then in a Python Shell I run this:
for i in range(2): hou.setContextOption('switchval', i) print hou.node('/stage/switch1').stage().GetPseudoRoot().GetAllChildren()
And get the following output:
[Usd.Prim(</HoudiniLayerInfo>), Usd.Prim(</sphere1>)]
[Usd.Prim(</HoudiniLayerInfo>), Usd.Prim(</cube1>)]
It also works for me when dragging the script to the shelf, but I do observe it doesn't work as a Python LOP.
- Rob
Solaris and Karma » Solaris crashes upon save
- robp_sidefx
- 453 posts
- Offline
Thanks for the heads-up! If you observe any consistent pattern, please let us know. It's proving a tricky one for me to reproduce at present.
Solaris and Karma » how varying materials with renderman
- robp_sidefx
- 453 posts
- Offline
Here's a slightly-modified version of your scene that will hopefully work for you. I changed the material network to use a PxrVary node, keyed off a “varySeed” primvar added in the instancer (similar to how you were adding “mix”). There's nothing special about the name “varySeed”, but it's important to note the wide range of values (as opposed to the 0-1 range you have with “mix”).
Let me know if you still have trouble with this!
Let me know if you still have trouble with this!
Edited by robp_sidefx - 2020年12月8日 06:18:47
Solaris and Karma » LOPS - Inline CPP
- robp_sidefx
- 453 posts
- Offline
Hi Aaron,
Sorry for the delay. In Houdini 18.5.387+ we've added hou.LopNode/LOP_Node translation so you can do things like:
Is this what you were after? If you have other workflows we're not supporting, please let us know.
Thanks!
- Rob
Sorry for the delay. In Houdini 18.5.387+ we've added hou.LopNode/LOP_Node translation so you can do things like:
node = hou.pwd()
import inlinecpp
inlinecpp.extendClass(hou.LopNode, "inlinecppTest",
function_sources = [
"""
int layerCount(LOP_Node *node)
{
return node->layerCount();
}
"""
]
)
print node.layerCount()
Is this what you were after? If you have other workflows we're not supporting, please let us know.
Thanks!
- Rob
Edited by robp_sidefx - 2020年11月4日 07:05:16
Solaris and Karma » Python lop taking multiple inputs/stages
- robp_sidefx
- 453 posts
- Offline
Hi Wayne,
Thanks for that example .hip; I can clearly see what you've described. I made some changes to your test scene to (hopefully) help illustrate a few things.
The good news (or bad news - depending on how you look at it) is that the behaviour is intentional.
The Graft LOP (now “Graft Stages” in Houdini 18.5) emulates an SdfCopySpec call on the (pseudo-)root prim, with the assumption that the source stage is fully self-contained and relocatable. We can't directly SdfCopySpec the ‘/’ prim, so we instead call it sequentially on all the root prim's children, and make a small change to the way we call it (I'll come back to this shortly).
In your example, you're calling SdfCopySpec on /geom which inherits from /_prototype etc. The inheritance path isn't updated because it (/_prototype) isn't a child of the thing that you're copying (/geom). There are two things I'd consider here:
1 - If you add /_prototype to the stage you're grafting, it's going to end up being relocated to /parent/transform/_prototype and now the inheritance path (if it doesn't update) will be pointing at the wrong spot. You can see this in the change I made to inlineusd1 (to add /_prototype) and copySpec (to more closely - but not perfectly - emulate what Graft Stages does). That's probably not what you want.
2 - If you changed the scene structure such that you had /copyMe/geom which inherited from /copyMe/_prototype and you called SdfCopySpec on /copyMe then the inheritance path *would* get updated. You can see this in the inlineusd2 change. I'm not suggesting you want to do this, but rather just trying to make it more explicit when paths do/don't get updated. Again, because we're trying to emulate copying the root prim in Graft Stages, when we use SdfCopySpec, we tell it to update all references under ‘/’ (as opposed to only updating references under the prim being copied). It's not obvious, but the code difference is here:
https://github.com/PixarAnimationStudios/USD/blob/release/pxr/usd/sdf/copyUtils.cpp#L827 [github.com]
vs
https://github.com/sideeffects/HoudiniUsdBridge/blob/master/src/houdini/lib/H_USD/HUSD/XUSD_Utils.C#L1942 [github.com]
The workflow in your example scene (which I appreciate may not match your production target) may be more amenable to Graft Branches (introduced in Houdini 18.5), which lets you cherry-pick specific prims to copy, and then only updates paths that contain said prim as a prefix (i.e., you can graft /geom and the LOP will only update paths that start with /geom, leaving ‘/’ paths as-is). Worded differently, this allows you to have relationship targets outside the prim you're grafting and those paths will be left intact. I'd say that your existing Python LOP more closely matches what Graft Branches does than what Graft Stages does.
I hope this helps! Please let me know if there's anything you feel is still unclear or unexpected or we should reconsider.
Thanks for that example .hip; I can clearly see what you've described. I made some changes to your test scene to (hopefully) help illustrate a few things.
The good news (or bad news - depending on how you look at it) is that the behaviour is intentional.
The Graft LOP (now “Graft Stages” in Houdini 18.5) emulates an SdfCopySpec call on the (pseudo-)root prim, with the assumption that the source stage is fully self-contained and relocatable. We can't directly SdfCopySpec the ‘/’ prim, so we instead call it sequentially on all the root prim's children, and make a small change to the way we call it (I'll come back to this shortly).
In your example, you're calling SdfCopySpec on /geom which inherits from /_prototype etc. The inheritance path isn't updated because it (/_prototype) isn't a child of the thing that you're copying (/geom). There are two things I'd consider here:
1 - If you add /_prototype to the stage you're grafting, it's going to end up being relocated to /parent/transform/_prototype and now the inheritance path (if it doesn't update) will be pointing at the wrong spot. You can see this in the change I made to inlineusd1 (to add /_prototype) and copySpec (to more closely - but not perfectly - emulate what Graft Stages does). That's probably not what you want.
2 - If you changed the scene structure such that you had /copyMe/geom which inherited from /copyMe/_prototype and you called SdfCopySpec on /copyMe then the inheritance path *would* get updated. You can see this in the inlineusd2 change. I'm not suggesting you want to do this, but rather just trying to make it more explicit when paths do/don't get updated. Again, because we're trying to emulate copying the root prim in Graft Stages, when we use SdfCopySpec, we tell it to update all references under ‘/’ (as opposed to only updating references under the prim being copied). It's not obvious, but the code difference is here:
https://github.com/PixarAnimationStudios/USD/blob/release/pxr/usd/sdf/copyUtils.cpp#L827 [github.com]
vs
https://github.com/sideeffects/HoudiniUsdBridge/blob/master/src/houdini/lib/H_USD/HUSD/XUSD_Utils.C#L1942 [github.com]
The workflow in your example scene (which I appreciate may not match your production target) may be more amenable to Graft Branches (introduced in Houdini 18.5), which lets you cherry-pick specific prims to copy, and then only updates paths that contain said prim as a prefix (i.e., you can graft /geom and the LOP will only update paths that start with /geom, leaving ‘/’ paths as-is). Worded differently, this allows you to have relationship targets outside the prim you're grafting and those paths will be left intact. I'd say that your existing Python LOP more closely matches what Graft Branches does than what Graft Stages does.
I hope this helps! Please let me know if there's anything you feel is still unclear or unexpected or we should reconsider.
Edited by robp_sidefx - 2020年10月20日 08:27:19
-
- Quick Links