Category: hou-usd

Archived post by lwwwwwws

I found if you sop import packed disk VDBs it happily does the right thing and you get instances referencing the original .vdb files, no extra caching required… so if you’ve got packed (non-disk) VDBs as .bgeo you should be able to turn that into a packed disk equivalent: – unpack 1 prim with Apply Transform disabled to get the original VDB – save it as a .vdb, load it back in as a packed disk with a File SOP – use Pack Inject to turn the packed VDB setup into packed disk VDBs – change or delete the path attrib, because packed disks have the file path in there and LOPs will use it to create a transform hierarchy from your on-disk folder structure which is just insanely confusing the first time you see it lmao

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20264106/10/26/Screenshot_2026-06-10_at_11.41.14.png

Archived post by mikael00794

Hehe yep. This is the painful part of working with the Sdf API. Sdf only works on individual layers, not the composed stage. Since you referenced in the .usd file to the /ROOT prim, technically the only defined primitive in the active layer is the /ROOT prim. The child primitives lives in the referenced usd file. So the steps to get the child prims is roughly: Get the /ROOT prim. Check the reference list for the primitive. Compute the absolute path to the reference usd file. Open the reference usd layer. Get the primitive from this layer instead. Something like this ish:
“`python from pxr import Sdf, Usd
node = hou.pwd()
layer = node.editableLayer() print(‘Editable Layer’, layer)
# This prim is defined on the active editable layer root_sdf_path = Sdf.Path(‘/ROOT’) root_prim = layer.GetPrimAtPath(root_sdf_path) print(‘Root Prim’, root_prim)
# Get reference list from prim on active layer root_prim_ref = root_prim.referenceList.GetAddedOrExplicitItems()[0] ref_layer_path = layer.ComputeAbsolutePath(root_prim_ref.assetPath) print(‘Reference Layer Path’, ref_layer_path) # Open reference ref_layer = Sdf.Layer.FindOrOpen(ref_layer_path)
# Get prim from reference usd. This will use the Sdf.Path from the reference usd layer ctrl_prim = ref_layer.GetPrimAtPath(‘/RIG_Main/carBody_CTRL’) print(‘ctrl_prim’, ctrl_prim) “` Fun times

Archived post by pixel_bender

Does anyone have a good approach to (in USD) – 1) Culling by object volume or 2) using %bound %closerthan over a shot range?

In SOPs I’d always trail and timeshift a camera frustum to the end frame – generating a shotlength frustum volume and cull objects based on it – in USD, as far as I can tell, this isn’t possible in any meaninfgul way – which is incredibly problematic

If I could cull by object volume, I could do the heavy lifting in SOPs by generating the frustum there

alternatively, if I could do a ‘cumulative closerthan / bound(cam)’, I’d get the same benefit

Oh shit.. maybe this is accounted for

well shit, this works amazingly

canera path and its prims

no time dependency introduced

`%bound(path/to/cam, bound = 20, t = ($FSTART, $FEND)) & %type:Mesh`

on a prune node seet to prune unselected

this is so great- beats even the sops workflow of frustum/trail/timeshift/group/delete

Here it is culling outside bounds, then using %closerthan in another prune to remove points getting to close to camera

seriously, beyond useful, and fast

Im just not sure if it works with instances…

Now the problem is with payloads and instances…

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20265503/24/26/image.png

Archived post by toadstorm

am i stupid? why is `gl_wireframe` somehow nowhere visible in the render properties shown in an Edit Properties LOP?

i’ve seen it done this way, i know i’ve done it myself in the past, but it’s like impossible to find in this mess of parameters. also, *why is it so fucking hard to show curves in the viewport without thickness*? why do i have to dig through this insane menu to do this?

i even tried adding the property as-is myself having memorized the name and it doesn’t fuckin work!

okay so after some digging, apparently this property has *never* been exposed by any menu and can’t be assigned at all unless you do it manually. so if you want guide curves in solaris, and you don’t want them rendered as big obnoxious ribbons, you have to use an Edit Properties LOP, manually drag an integer property from the USD Proprties list, and name it `primvars:houdini:gl_wireframe`, OR you have to do it via a wrangle: “` usd_addprimvar(0, s@primpath, “houdini:gl_wireframe”, “bool”); usd_setprimvar(0, s@primpath, “houdini:gl_wireframe”, 1); “`
brilliant UX

i find it really hard to believe this hasn’t been an issue for any other solaris users before. are guide curves really not used by anyone?