Add debug utilities to help debug dynamic lights and small fixes by DolceTriade · Pull Request #1908 · DaemonEngine/Daemon

DolceTriade · 2026-02-23T00:31:58Z

Add cvars to create a debug spotlight and a debug sun light.
Ensure that sun lights affect all light tiles
Add a debug cvar to help visualize spot lights and point lights
Stop segfaulting when running glsl_restart

src/engine/renderer/tr_backend.cpp

slipher · 2026-03-30T06:04:10Z

src/engine/renderer/tr_backend.cpp

+                        };
+						for ( int dirIndex = 0; dirIndex < 6; ++dirIndex )
+						{
+							addArrow( kOmniDirs[ dirIndex ], color );


The 12 tetrahedrons seems too busy to me. Maybe we could just draw a wireframe cube?

I kept tetrahedrons so I could show the direction of the light for projected lights and show that omni lights go in all directions. I also cargo culted the lightgrid code here.

I've found it helpful to debug dynamic light in my testing as is.

Sure, the shape makes sense for directed lights, I meant for normal point lights. When you have more than one point light they often overlap and it is impossible to tell how many there are with this visualization. Anyway since projected and directed are distinguished by color, how about just drawing one "arrow" with some arbitrary vector for point lights?

Ok, how does this look?

I think in order to draw in wireframe mode I need to do two passes.

slipher · 2026-03-30T06:11:59Z

src/engine/renderer/tr_backend.cpp

+			glState.modelViewProjectionMatrix[ glState.stackIndex ] );
+
+		Tess_Begin( Tess_StageIteratorDebug, nullptr, true, -1, 0 );
+		GL_CheckErrors();


Oddly placed GL_CheckErrors.

This is admittedly cargo culted:

Daemon/src/engine/renderer/tr_backend.cpp

Lines 2245 to 2246 in 29446db

Tess_Begin( Tess_StageIteratorDebug, nullptr, true, -1 );

GL_CheckErrors();

As a convention should I check for errors elsewhere?

I mean usually you would call that after finishing rendering something, rather than before starting.

Ok, I moved it after the draw call. I think that makes more sense?

src/engine/renderer/tr_scene.cpp

src/engine/renderer/glsl_source/lighttile_fp.glsl

slipher · 2026-04-02T04:42:18Z

src/engine/renderer/tr_backend.cpp

+			glState.modelViewProjectionMatrix[ glState.stackIndex ] );
+
+		Tess_Begin( Tess_StageIteratorDebug, nullptr, true, -1, 0 );
+		GL_CheckErrors();


I mean usually you would call that after finishing rendering something, rather than before starting.

slipher · 2026-04-02T04:43:35Z

src/engine/renderer/tr_backend.cpp

+                        };
+						for ( int dirIndex = 0; dirIndex < 6; ++dirIndex )
+						{
+							addArrow( kOmniDirs[ dirIndex ], color );


Sure, the shape makes sense for directed lights, I meant for normal point lights. When you have more than one point light they often overlap and it is impossible to tell how many there are with this visualization. Anyway since projected and directed are distinguished by color, how about just drawing one "arrow" with some arbitrary vector for point lights?

slipher · 2026-04-02T04:52:31Z

src/engine/renderer/tr_backend.cpp

+				{
+					VectorSet( dir, 0.0f, 0.0f, 1.0f );
+				}
+				// idk why we need to negate here, but the arrow points the wrong way otherwise.


Surface normals point outward from the object. And a light is rendered when the product of its direction and the surface normal is positive. So the light direction vector has to point away from the source for it to work. But I think the negation should be dropped, so that it is consistent with r_showLightGrid. With the light grid visualization, the long skinny side shows the directed light color and direction.

hm...

This is what it looks like with the negation:

This is what it looks like without negation:

I think the rendering with negation looks better. I think that's what you're saying in your comment?

slipher · 2026-04-02T05:01:19Z

src/engine/renderer/tr_scene.cpp

+// Debug sun light (directional) injection
+Cvar::Cvar<bool> r_debugSun( "r_debugSun", "inject a directional sun light each frame", Cvar::CHEAT, false );
+Cvar::Range<Cvar::Cvar<float>> r_debugSunYaw( "r_debugSunYaw", "debug sun yaw in degrees", Cvar::NONE, 45.0f, -360.0f, 360.0f );
+Cvar::Range<Cvar::Cvar<float>> r_debugSunPitch( "r_debugSunPitch", "debug sun pitch in degrees", Cvar::NONE, -60.0f, -89.0f, 89.0f );


Seems counterintuitive for the "sun" to default to illuminating things from below.

I was thinking from the sun's perspective cuz the sun shines down, but if you want me to change it, I can change it.

Just let me know what you think makes sense.

When I tried it the ceiling was illuminated but the floor was not!

slipher · 2026-04-02T05:30:07Z

src/engine/renderer/tr_scene.cpp

+static Cvar::Range<Cvar::Cvar<float>> r_debugProjLightYaw( "r_debugProjLightYaw", "debug projected yaw in degrees", Cvar::NONE, 45.0f, -360.0f, 360.0f );
+static Cvar::Range<Cvar::Cvar<float>> r_debugProjLightPitch( "r_debugProjLightPitch", "debug projected pitch in degrees", Cvar::NONE, -60.0f, -89.0f, 89.0f );
+static Cvar::Cvar<float> r_debugProjLightRadius( "r_debugProjLightRadius", "debug projected radius (size)", Cvar::NONE, 100.0f );
+static Cvar::Range<Cvar::Cvar<float>> r_debugProjLightR( "r_debugProjLightR", "debug projected color R", Cvar::NONE, 1.0f, 0.0f, 1.0f );


The light intensity shouldn't be capped at 1

Added back intensity. I think it's weird to make RGB more than 1.

sRGB is in [0,1] but RGB is [0,…]

The lightmap themselves get multiplied by overbright and then are already in a range higher than [0, 1], also our whole pipeline uses HDR framebuffers so is ready for that.

This adds a debug cvar to draw a tetrahedron (similar to what you get when yuou enable r_showSkeleton) in the direction of a spot light or in 6 directions for an omnilight that is proportional to the radius of the light. This makes it easier to visualize dynamic lights and see what they should be doing, what direction they are intended to point, etc. Also, while here, normalize spotlight direction.

Makes it easier to test dynamic lights.

Directional lights should affect all light tiles, so set a really high radius to ensure they are included in all light tiles. Also add some cvars to allow adding a debug sun.

Switch to a wireframe cube to make omni lights less busy

slipher

I suspect something is wrong with the projected light math as a lot of times it doesn't seem to illuminate anything in any direction near the origin. It would probably be good to get rid of the projTarget etc. garbage from refLight_t and instead use the same parameters as in the GLSL

slipher · 2026-04-02T09:51:25Z

src/engine/renderer/tr_scene.cpp

+// Debug sun light (directional) injection
+Cvar::Cvar<bool> r_debugSun( "r_debugSun", "inject a directional sun light each frame", Cvar::CHEAT, false );
+Cvar::Range<Cvar::Cvar<float>> r_debugSunYaw( "r_debugSunYaw", "debug sun yaw in degrees", Cvar::NONE, 45.0f, -360.0f, 360.0f );
+Cvar::Range<Cvar::Cvar<float>> r_debugSunPitch( "r_debugSunPitch", "debug sun pitch in degrees", Cvar::NONE, -60.0f, -89.0f, 89.0f );


When I tried it the ceiling was illuminated but the floor was not!

slipher · 2026-04-02T10:08:45Z

I suspect something is wrong with the projected light math as a lot of times it doesn't seem to illuminate anything in any direction near the origin. It would probably be good to get rid of the projTarget etc. garbage from refLight_t and instead use the same parameters as in the GLSL

Never mind, I got it to work now. It's just confusing when the tetrahedrons are very big and I don't know which part of them the light is supposed to originate from.

DolceTriade · 2026-04-02T17:21:13Z

Never mind, I got it to work now. It's just confusing when the tetrahedrons are very big and I don't know which part of them the light is supposed to originate from.

Is there any further action to change?

slipher · 2026-04-04T02:19:21Z

Never mind, I got it to work now. It's just confusing when the tetrahedrons are very big and I don't know which part of them the light is supposed to originate from.

Is there any further action to change?

The only suggestion I had left was changing the default sun pitch angle so that the floor is illuminated rather than the ceiling. LGTM besides that. On the subject of the default values, the spotlight intensity could optionally be increased a little so that it's easier to see

illwieckz mentioned this pull request Mar 9, 2026

glsl_restart: Stop segfaulting #1926

Merged

DolceTriade requested a review from slipher March 28, 2026 09:25

slipher reviewed Mar 30, 2026

View reviewed changes

DolceTriade force-pushed the debuglight branch from c7aba11 to c94abc6 Compare April 1, 2026 06:51

slipher reviewed Apr 2, 2026

View reviewed changes

DolceTriade added 4 commits April 2, 2026 00:11

lights: Add cvars to add debug projected lights

7cd603a

Makes it easier to test dynamic lights.

lights: Fix directional lights and add debug cvars to add a fake sun

4fb5b96

Directional lights should affect all light tiles, so set a really high radius to ensure they are included in all light tiles. Also add some cvars to allow adding a debug sun.

lights: Change r_showDynamicLights to show a cube for omni lights

2d4e359

Switch to a wireframe cube to make omni lights less busy

DolceTriade force-pushed the debuglight branch from c94abc6 to 2d4e359 Compare April 2, 2026 07:33

slipher reviewed Apr 2, 2026

View reviewed changes

	Tess_Begin( Tess_StageIteratorDebug, nullptr, true, -1 );
	GL_CheckErrors();

Conversation

DolceTriade commented Feb 23, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DolceTriade Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

slipher left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

slipher commented Apr 2, 2026

Uh oh!

DolceTriade commented Apr 2, 2026

Uh oh!

slipher commented Apr 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

DolceTriade Apr 2, 2026 •

edited

Loading