Light tree: orientation cone of a reverse-sided light points the wrong way
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 76/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- cpp
- Domain
- computer-graphics
Research direction
Start with LightTreeCone(const Light*) in lib/rendering/pbr/light/LightTreeUtil.h and inspect how it derives the cone axis for reverse-sided lights. Reproduce with the issue’s eight DiskLights, spread 0.5 and adaptive versus uniform light sampling; done means the reverse-sided ratio no longer shows the reported 4% loss while regular-sided and wider-spread cases remain unaffected.
Written by the indexing model from the issue text.
Description
Summary. With adaptive light sampling, reverse-sided lights with a spread below 1 are under-selected: the image is about 4% too dark, and BSDF samples do not compensate. Version 2026.29.1, scalar mode.
Reproduce. Eight DiskLights (radius 0.2, spread 0.5) facing down onto a diffuse floor, max_depth 1, light samples only. Ratio of light_sampling_mode adaptive to uniform:
| lights | adaptive / uniform |
|---|---|
sidedness reverse |
0.9558 |
| the same lights with regular sidedness (rotated instead) | 0.9998 |
reverse, with bsdf_samples on too |
0.9559 |
With spread 0.8 or 1 there is no loss.
Cause. LightTreeCone(const Light*) (lib/rendering/pbr/light/LightTreeUtil.h) takes the cone axis from light->getDirection(0), the local +z, for every light. A light with sidedness reverse emits toward -z, so with a spread below 1 the tree's orientation bound excludes directions the light does emit into, and the importance of the light is underestimated.
Fix (untested). Use -getDirection() as the cone axis for reverse-sided lights (two-sided lights already set mTwoSided).
- Dominant language
- CMake
- Stars
- 4.7k
- Forks
- 321
- Avg merge
- 13m
- Merged PRs (30d)
- 3
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from OpenMoonRay/openmoonray
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
OpenMoonRay/openmoonray#320 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
OpenMoonRay/openmoonray#233 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 57/100
OpenMoonRay/openmoonray#331 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
OpenMoonRay/openmoonray#330 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
OpenMoonRay/openmoonray#329 ·
All issues in OpenMoonRay/openmoonray
Similar issues
-
Difficulty 1/5 1-3 hours Newbie friendliness 83/100
rive-app/rive-runtime#143 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
bug: get_image_info returns true after copying an uninitialised buffer into the caller's output when every UDIM tile is unreadablePossibly taken @lgritz claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
AcademySoftwareFoundation/OpenImageIO#5662 · 1 comment · 1 assignee ·
Maintainers usually reply within 2 days
-
bug studies ui
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
userFRM/egui-charts#2236 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
JiaFeiMiao-K-Cat/DiscImageStudio#132 · 1 comment · 1 reaction ·
Maintainers usually reply within 1 day