How to support custom light type with Hydra2?

Community Hydra
1

It looks like lightAdapter.cpp used to instantiate a light Hydra prim but, with Hydra2, now instantiates an untyped Hydra prim (relying on the derived classes - e.g., distantLightAdapter.cpp to provide GetImagingSubprimType).

Is it expected that all custom light types deriving from UsdLuxNonboundableLightBase should now provide their own adapter. I look at, for example, PxrEnvDayLight which doesn’t seem to provide one and, perhaps as a result, seems to render black when USDIMAGINGGL_ENGINE_ENABLE_SCENE_INDEX is set.

#usda 1.0
(
    upAxis = "Y"
)

def PxrEnvDayLight "sky" 
{
}

def Sphere "sphere"
{
}
2

Still curious whether we need to have custom adapters, or if there’s a case to be made for amending UsdImagingLightAdapter with something like:

TfTokenVector
UsdImagingLightAdapter::GetImagingSubprims(UsdPrim const& prim)
{
    return { TfToken() };
}

TfToken
UsdImagingLightAdapter::GetImagingSubprimType(
        UsdPrim const& prim,
        TfToken const& subprim)
{
    if (subprim.IsEmpty()) {
        return HdPrimTypeTokens->light;
    }
    return TfToken();
}

Note that I’ve actually tried this and it didn’t seem to work :frowning:

3

Hydra2 lights are a bit weird because they’re following the UsdLux schema more closely now. If you look at cylinderLightAdapter, it basically just provides the type “cylinderLight” and the standard prim attributes (transform, visibility, etc, via lightAdapter). The real machinery is now in lightAPIAdapter, which compiles a light material and scoops up “inputs:*”, and which will overlay that data onto any prim with “LightAPI” applied.

Does KarmaSkyDomeLight apply LightAPI? If so, you could add an adapter to just provide the type and the standard prim datasource, and you can get the lightAPIAdapter to pick up the rest; if there are issues about which attribute namespaces it’s searching, we can brainstorm. If it doesn’t apply LightAPI, you’ll need to overlay that data yourself; you can reuse the datasources in lightAPIAdapter, if you want.

If your question is whether we could use lightAdapter to provide the type name, and get rid of your adapter, that’s definitely an interesting idea. I don’t think we currently support “light” as a type, and we do have hydra code filtering based on light type (especially around dome lights, but also in simpleLightTask for Storm). But we could talk about moving to “light” as a type or somehow grabbing the USD typename or something else. Long term, being able to support new light types without custom adapters is probably a big enough benefit to explore this concept more.

I’ll look into what’s going on with PxrEnvDayLight; I thought that was working!

Hope that helps!

Tom

4

FWIW, in the custom adapter I have in place I’m returning HdPrimTypeTokens->light (as opposed to a Houdini-/Karma-specific type) from GetImagingSubprimType and it’s working for us.