Picking issue on geometry without authorred `extent`

Community Hydra
1

Context of the issue: if the geomoery has no authored extent attribute, the default extent while creating the boox for pixking test is [-1, 1]. This reaults the picking failed outsite the bbox even if the pick is on the geometry.

According to this comments, the default bbox is supposed to be [-FLT_MAX, FLT_MAX]. The codes use prim->GetExtent(delegate) to create the bbox. Unfortunately, the default extent is [-1, 1] if it has no authored value.

Apparently, I can fix the issue with two solutions:

  • Add a new function prim->HasAuthorredExtent(delegate) and then create bbox of [-FLT_MAX, FKT_MAX] if there is no authorred extent.
  • Change the fallback value of extent to [-FLT_MAX, FLT_MAX]

The first solution is not difficult, I just need to follow the calls of prim->GetExtent(delegate) and create HasAuthorredExtent(). The call stack is rather long and ugly but it is definitely doable.

I personally prefer the 2nd solution: change the the fallback value of extent to [-FLT_MAX, FLT_MAX].

Two issues I am having right now is:

  1. Will changing the default extent have unwanted side effects? To me, [-FLT_MAX, FLT_MAX] is clearlly a better default than [-1, 1].
  2. How to set the default value of extent? I traced GetFallbackValue() to learn how the fallback is stored. It looks like SdfFieldKeys->Default is used to set the field value. Unfortunately though, I did not find the codes that set the default extent.

My main question is on how to set the default value of extent. But also apprecicate feedbacks on other parts of my comments. Thanks,

2

Can you describe where the extent [-1,1] is coming from? From a quick read of the usdImaging library, if you don’t manually author an “extent” attribute on a prim, the library does indeed construct an empty GfRange3d, which is defined as [-FLT_MAX, FLT_MAX]. It sounds like the [-1,1] is definitely a bug but I’m not clear on where it’s coming from.

Thanks!

3

If you trace the execution to this call, if there is no authored extent, prim->GetExtent(delegate) will return [-1, 1] as the fallback value. This conflicts to the comments right above that line.

Another way to verify this is to create a simple usda file:

#usda 1.0

def Xform “hello”
{
def Sphere “world”
{
double radius = 2
}
}

Run the following commands in python:

from pxr import Usd, UsdGeom
stage = Usd.Stage.Open(‘HelloWorld.usda’)
sphere = stage.GetPrimAtPath(‘/hello/world’)
extentAttr = sphere.GetAttribute(‘extent’)
extentAttr.Get()

You will get [-1, 1] as well since there is no authored extent in the sphere.

The range is created with the min/max of the extent:

GfRange3d
HdSceneIndexAdapterSceneDelegate::GetExtent(SdfPath const &id)
{
TRACE_FUNCTION();
HF_MALLOC_TAG_FUNCTION();
HdSceneIndexPrim prim = _inputSceneIndex->GetPrim(id);

HdExtentSchema extentSchema =
    HdExtentSchema::GetFromParent(prim.dataSource);
if (!extentSchema.IsDefined()) {
    return GfRange3d();
}

GfVec3d min, max;
if (HdVec3dDataSourceHandle minDs = extentSchema.GetMin()) {
    min = minDs->GetTypedValue(0);
}
if (HdVec3dDataSourceHandle maxDs = extentSchema.GetMax()) {
    max = maxDs->GetTypedValue(0);
}

return GfRange3d(min, max);

}

Min/max are from:

HdVec3dDataSourceHandle
HdExtentSchema::GetMin()
{
return _GetTypedDataSource(
HdExtentSchemaTokens->min);
}

HdVec3dDataSourceHandle
HdExtentSchema::GetMax()
{
return _GetTypedDataSource(
HdExtentSchemaTokens->max);
}

I lost the trace here. Searched HdExtentSchemaTokens->max in USD but cannot find the codes that set the min/max value.

4

Hey Andy,

As it turns out, “Gprim” doesn’t define a default extent and when hydra can’t read an extent from USD, we use [-max, max]. However, “Sphere” does define an extent fallback of [-1,1]^3: https://github.com/PixarAnimationStudios/OpenUSD/blob/release/pxr/usd/usdGeom/schema.usda#L698 … This matches with the radius fallback, but if you define a radius and not an extent that would be badly-formed USD data and I wouldn’t be surprised if it was behaving incorrectly.

Are you seeing this with other prim types? And how hard is it to ensure your data comes in with authored extents? (Since that’s just a better packaging of the data anyhow).

Thanks!
Tom

5

Hi Tom,

It looks like all geometries (such as Sphere, Cube, Cone…etc) have [-1 1] as the fallback extent. The fallback extent though conflicts to this comment.

I had a fix right after that comment to check if the extent has an authored value. I pretty much just implemented that comment (the fix is not in the public repo yet). Though I feel fixing the fallback extent is a better fix for the picking issue.

I do understand that fallback extent [-1, 1] matches the fallback Sphere radius. So that kinda makes sense too. Though [-1 1] is not my preferred falbback. I would consider either one of [0 0] , [-max, max] or [max, -max] a better fallback as they have better logical implication.

I am simply a consumer of the scene so I don’t know the difficulty of having the authored extent. I guess it should not be hard for artist. They probably just use one of the usd autoring tools to generate the scene.

My opnion on this though is: fallback extent should not break the USD/Hydra’s behavior or functionality.

If I changed the fallback extent to [max, -max] (to abide by the comment), will it be accpted back to USD repo? I can keep my current fix (explicitly implement that comment) as well if that has a better chance to be accpted.

Thanks,

–Andy