Forums Solaris and Karma Purpose breaking computed extent.

Purpose breaking computed extent.

   493   9   1
User Avatar
Latimerias
Member
38 posts
Joined: Aug. 2020
Offline
 
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)
Edited by Latimerias - Aug. 27, 2025 19:39:42
 Report
User Avatar
mtucker
Staff
4551 posts
Joined: July 2005
Offline
 
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.
 Report
User Avatar
Latimerias
Member
38 posts
Joined: Aug. 2020
Offline
 
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?
Edited by Latimerias - Sept. 2, 2025 11:55:47
 Report
User Avatar
mtucker
Staff
4551 posts
Joined: July 2005
Offline
 
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.
 Report
User Avatar
Latimerias
Member
38 posts
Joined: Aug. 2020
Offline
 
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.

Edited by Latimerias - Sept. 2, 2025 14:11:16

Attachments:
broken_drawmode.hiplc (483.3 KB)

 Report
User Avatar
Latimerias
Member
38 posts
Joined: Aug. 2020
Offline
 
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?
Edited by Latimerias - yesterday 11:59:02
 Report
User Avatar
mtucker
Staff
4551 posts
Joined: July 2005
Offline
 
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.
 Report
User Avatar
Latimerias
Member
38 posts
Joined: Aug. 2020
Offline
 
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.
 Report
User Avatar
mtucker
Staff
4551 posts
Joined: July 2005
Offline
 
Unloaded payloads have always been drawn as bounding boxes only, and I suspect that will continue to be the case. I'm not aware of any plans to change it.

In my testing, the new hydra works find drawing bounding boxes for unloaded payloads as long as there are not per-purpose extents authored on the payload prim (meaning unloading payloads suffers from the same bug as setting the draw mode on a prim). This bug I'm hoping SideFX can address in a lot less than a year, though it may take some time for any such change to get adopted into the standard USD github repostiory.
 Report
User Avatar
Latimerias
Member
38 posts
Joined: Aug. 2020
Offline
 
I see, It was mentioned in the USD working group last year but a proposal was never drafted.
Edited by Latimerias - today 14:25:44
 Report
  • Quick Links