DjangoBB LoFi version

Full Version: Purpose breaking computed extent.

Root » Solaris and Karma » Purpose breaking computed extent.

Latimerias

2025年8月27日 19:04:12

Using the component builder for example with a basic cube for both render and proxy. If you have a parent prim /ASSET or /geo that you want to compute the extentsHint of and it has the child prims /proxy and /render which have their purpose configured.

Without purposes assigned the computed extent is

[(-0.5, -0.5, -0.5), (0.5, 0.5, 0.5)]

with proxy purpose assigned

[(-0.5, -0.5, -0.5), (0.5, 0.5, 0.5), (3.4028235e38, 3.4028235e38, 3.4028235e38), (-3.4028235e38, -3.4028235e38, -3.4028235e38), (-0.5, -0.5, -0.5), (0.5, 0.5, 0.5)]

with proxy and render purpose

[(3.4028235e38, 3.4028235e38, 3.4028235e38), (-3.4028235e38, -3.4028235e38, -3.4028235e38), (-0.5, -0.5, -0.5), (0.5, 0.5, 0.5), (-0.5, -0.5, -0.5), (0.5, 0.5, 0.5)]

Am i making a user error? I am currently manually copying the extent from the boundable mesh to the root component which i am unsure is a valid workaround but is needed for proper Draw Mode card rendering.

from pxr import UsdGeom

stage = hou.pwd().editableStage()

# The prim to copy the extents from
extent_reference_prim = stage.GetPrimAtPath("/ASSET/geo/render/shape")
# The prim to write the extents to
prim = stage.GetPrimAtPath("/ASSET")

# get the actual extents coordinates
reference_extent = extent_reference_prim.GetAttribute("extent").Get()

# create the geom model api schema
model_api = UsdGeom.ModelAPI.Apply(prim)
model_api.SetExtentsHint(reference_extent)

mtucker

2025年9月2日 11:43:14

The extent attribute is more complex than you think

I think the values you posted there are fine. The best description I could find on the format of this attribute is here: https://openusd.org/dev/api/class_usd_geom_model_a_p_i.html#a4aa8b1f29a3097fe08da868bd2b8b259 [openusd.org]

Basically it contains an array of bounds, one for each purpose. If a given purpose doesn't have any geometry, then invalid bounds will be authored into that "slot" in the array.

Latimerias

2025年9月2日 11:54:01

Thank-you for the reply, I could not put together that its an array bounds, per purpose! Is there a recommended Solaris workflow for setting up the extend for card draw modes? If the values are expected does that mean that the card draw mode issue should be dealt with elsewhere?

mtucker

2025年9月2日 13:02:11

Generally speaking, I'd let the Set Extents LOP or the Configure Primitive LOP calculate the bounding box for your prim on which you want to set up the cards draw mode. These LOP nodes should just do the right thing. There is also the Draw Mode LOP that puts all this stuff together into a single node.

Latimerias

2025年9月2日 13:16:47

I see, it sounds like my problem stems from something else then. The actual problem I'm having is that the draw mode doesn't render when the extents hint contains the invalid entries. If im making assets from scratch i can compute the extents before the purpose, but most of the times i try to use the component builder and try to make minimal modifications, which in this case was just using that python snippet at the end.

Latimerias

2025年9月3日 14:35:26

I tried this setup in usdview 25.05 on windows and the cards are rendering with proper bounds, so it seems like this is a hview issue?

mtucker

昨日 12:37:53

There does seem to be a bug here, and I must point the finger squarely at the new Hydra...

If you are using a usdview other than the one that ships with Houdini, it will still be using the old Hydra architecture, so you'll get proper bounding boxes. Houdini (and the usdview that ships with Houdini) automatically set the environment variable USDIMAGINGGL_ENGINE_ENABLE_SCENE_INDEX=1, which enables the new Hydra architecture, and breaks how the extents are interpreted when setting the draw mode on a prim. I'll be submitting a bug for this.

Latimerias

昨日 12:45:26

Thank-you for looking into it, i was using a different build of USD! It seems there are a few kinks to work out with draw modes on unloaded payloads as well, so I'll keep structuring components with the assumption that these issues with USD/Hydra will be resolved over the next year or two.