Skip to content

solaris: fix light type mapping translation - #4

Open
aoblet wants to merge 1 commit into
OpenMoonRay:mainfrom
TheYardVFX:fix/houdini-light-type
Open

solaris: fix light type mapping translation#4
aoblet wants to merge 1 commit into
OpenMoonRay:mainfrom
TheYardVFX:fix/houdini-light-type

Conversation

@aoblet

@aoblet aoblet commented Jul 29, 2026

Copy link
Copy Markdown

Title

Fix moonray:class defaulting to the literal string "None" for:

  • DomeLight
  • DomeLight_1
  • DistantLight

Summary

The hidden class parameter on Moonray light nodes (which drives themoonray:class USD attribute) computes its default value via an embedded Python expression in moonray_Light.ds and its duplicate,HdMoonrayRendererPlugin_Light.ds.

When a light node has no lighttype spare parameter, which is the case for native single-purpose light LOPs such as Distant Light, Dome Light, the expression falls back to reading hou.parm("primtype"), but only had an explicit branch for UsdLuxDomeLight -> "EnvLight":

else:
    parm = hou.parm("primtype")
    value = parm.eval()
    if value == "UsdLuxDomeLight":
        return "EnvLight"
    # falls through here for every other primtype

Fix

Replace the single if/else with an explicit primtype -> class map covering all supported UsdLux types, Including both UsdLuxDomeLight and UsdLuxDomeLight_1:

  • DistantLight
  • RectLight
  • SphereLight
  • DiskLight
  • CylinderLight
  • PortalLight
  • MeshLight
  • EnvLight

Signed-off-by: Alexis Oblet <alexis@theyard-vfx.com>
@linux-foundation-easycla

linux-foundation-easycla Bot commented Jul 29, 2026

Copy link
Copy Markdown

CLA Signed
The committers listed above are authorized under a signed CLA.

  • ✅ login: aoblet / name: Alexis Oblet (e6af662)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant