Light tree more noisy with saturated light and surface colors #112217

Open
opened 2023-09-11 09:12:00 +02:00 by Steffen Dünner · 2 comments

System Information
Operating system: Linux-6.4.15-x64v4-xanmod1-x86_64-with-glibc2.35 64 Bits, X11 UI
Graphics card: NVIDIA GeForce RTX 2070 Super/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 535.104.05

Blender Version
Broken: version: 4.0.0 Alpha, branch: main, commit date: 2023-09-10 22:17, hash: fca8df9415b1
3.6.2 release shows same behaviour
Worked: (newest version of Blender that worked as expected)

Short description of error
I built a simple scene for testing Agx vs Filmic vs ACES:
A simple grid and three point lights above it. The grid is saturated blue (RGB 0,0,1) and the lights are saturated red, green and blue.
Not really a real world situation but it unveiled a strange performance regression with the Light Tree.
If you only have a single light visible during preview rendering all is fine and snappy. As soon as you have e.g. the blue and the red or all three of them visible, sampling around the non-blue light sources becomes extremely grainy and takes quite a while to resolve.

Switching the Light Tree off gives instant and clean results.

This also happens in 3.6.2 and with CPU rendering.

Exact steps for others to reproduce the error

  • Open the simple test blend file Light_Tree_Strangeness_v01.blend
  • Start a preview render and depending on your GPU / system setup you'll see something like this which slowly converges to a noise free image
    image
    image
    image
  • Uncheck the "Light Tree" option and the image converges in the fraction of the time it took before.
  • Activate "Light Tree" again, rendering is slower / more grainy
  • Now switch off 2 of the 3 lights -> all is snappy again.

I don't know if this is really a bug or just a corner case of how the Light Tree works.

**System Information** Operating system: Linux-6.4.15-x64v4-xanmod1-x86_64-with-glibc2.35 64 Bits, X11 UI Graphics card: NVIDIA GeForce RTX 2070 Super/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 535.104.05 **Blender Version** Broken: version: 4.0.0 Alpha, branch: main, commit date: 2023-09-10 22:17, hash: `fca8df9415b1` 3.6.2 release shows same behaviour Worked: (newest version of Blender that worked as expected) **Short description of error** I built a simple scene for testing Agx vs Filmic vs ACES: A simple grid and three point lights above it. The grid is saturated blue (RGB 0,0,1) and the lights are saturated red, green and blue. Not really a real world situation but it unveiled a strange performance regression with the Light Tree. If you only have a single light visible during preview rendering all is fine and snappy. As soon as you have e.g. the blue and the red or all three of them visible, sampling around the non-blue light sources becomes extremely grainy and takes quite a while to resolve. Switching the Light Tree off gives instant and clean results. This also happens in 3.6.2 and with CPU rendering. **Exact steps for others to reproduce the error** - Open the simple test blend file [Light_Tree_Strangeness_v01.blend](/attachments/4fa13f66-1a0f-4f83-b820-48e3699e7cf2) - Start a preview render and depending on your GPU / system setup you'll see something like this which slowly converges to a noise free image ![image](/attachments/017b7870-c762-45f6-a87c-4350ecb9ad25) ![image](/attachments/8da5e8db-20fa-452b-8863-dca0d7f81b49) ![image](/attachments/b47631c6-2c12-49b1-8afc-fb51e2b2d021) - Uncheck the "Light Tree" option and the image converges in the fraction of the time it took before. - Activate "Light Tree" again, rendering is slower / more grainy - Now switch off 2 of the 3 lights -> all is snappy again. I don't know if this is really a bug or just a corner case of how the Light Tree works.
Steffen Dünner added the
Priority
Normal
Type
Report
Status
Needs Triage
labels 2023-09-11 09:12:00 +02:00
Member

This is a known limitation. When the light tree is sampled, different lights are assigned different importances based on their "perceived intensity" (based on the energy the light is emitting, and how far away the light is). At the moment, this calculation does not take into consideration the colours of the lights, or the shader of the object being sampled (with the exception of whether or not the shader on the object has a transmissive component or is a volumetric shader).

As a result of this, the ray hits the blue ground, and the the light tree calculates the importance of each light (ignoring the colours of the lights and the colour of the material being sampled), then samples the light. Due to it ignoring the colour factor, the red and green lights have high importance on the ground near them, meaning they get sampled significantly more than the blue light, which results in noise in this specific scene (Because the green and red lights contribute very little to the shading of the surface, while the blue light does. But the green and red lights still get assigned high importance).

Some work could be done to improve this (E.G. In the light importance calculator there is a "shader function approximation scaler" which scales the importance of lights based on the relationship between the shader and the light. At the moment it's always set to 1.0. But a function could be added to adjust the importance of different lights based on material and light colours.)
Note: The shader function approximation scaler is the variable f_a found in light_tree_importance() here: https://projects.blender.org/blender/blender/src/branch/main/intern/cycles/kernel/light/tree.h#L219

I'll leave the final call on this report to @weizhen or @brecht (Keep it open as a known limitation, close the report, or implement a proper shader approximation to handle cases like this better.)

This is a known limitation. When the light tree is sampled, different lights are assigned different importances based on their "perceived intensity" (based on the energy the light is emitting, and how far away the light is). At the moment, this calculation does not take into consideration the colours of the lights, or the shader of the object being sampled (with the exception of whether or not the shader on the object has a transmissive component or is a volumetric shader). As a result of this, the ray hits the blue ground, and the the light tree calculates the importance of each light (ignoring the colours of the lights and the colour of the material being sampled), then samples the light. Due to it ignoring the colour factor, the red and green lights have high importance on the ground near them, meaning they get sampled significantly more than the blue light, which results in noise in this specific scene (Because the green and red lights contribute very little to the shading of the surface, while the blue light does. But the green and red lights still get assigned high importance). Some work could be done to improve this (E.G. In the light importance calculator there is a "shader function approximation scaler" which scales the importance of lights based on the relationship between the shader and the light. At the moment it's always set to 1.0. But a function could be added to adjust the importance of different lights based on material and light colours.) Note: The shader function approximation scaler is the variable `f_a` found in `light_tree_importance()` here: https://projects.blender.org/blender/blender/src/branch/main/intern/cycles/kernel/light/tree.h#L219 I'll leave the final call on this report to @weizhen or @brecht (Keep it open as a known limitation, close the report, or implement a proper shader approximation to handle cases like this better.)

Thanks for the clarification. I never had any problems with this in real production scenes so far.

Thanks for the clarification. I never had any problems with this in real production scenes so far.
Brecht Van Lommel changed title from Performance regression with Light Tree on to Light tree more noisy with saturated light and surface colors 2023-09-12 16:53:03 +02:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#112217
No description provided.