Add light affect debug draw mode

[kaadmy]

Adds a new debug draw mode for viewports named "Light Affect", this is similar to overdraw but changes the color depending on how many lights currently affect the object being colored.

Currently this has only been implemented in the GLES3 backend (no other debug draw modes seem to work with GLES2 anyway, so I didn't consider this a big deal)

If the light count is increased, this will also need to change to accommodate a higher range.

• 0 lights: gray
• 1-4 lights: blue
• 5-6 lights: purple
• 7 lights: yellow
• 8+ lights: red

Leftmost sphere has zero lights, rightmost sphere has 8 lights

3D viewport settings

ZIP file for above scene
light_affect_debug.zip

[kaadmy]

So apparently there's no way to use unshaded mode in a shader with the light function, so the geometry is still lit from GIProbes, lightmaps, etc...

[kaadmy]

Screenshot of this debug draw mode with the TPS demo

For that screenshot I still needed to change environment settings to get the colors into a reasonable range (disabled color correction, reduced exposure to ~0.5, disabled DoF and glow)

[akien-mga]

Style issue here, there should be spaces around =. See http://docs.godotengine.org/en/latest/community/contributing/code_style_guidelines.html

[kaadmy]

Oops, missed that somehow, it wasn't intentional.

[kaadmy]

Should this PR also disable tonemapping/environment while the debug mode is enabled? It might be simpler since showing lighting isn't the goal here (could also make this more shaded, since it might get hard to navigate scenes with this mode enabled.)

Edit: Wording

[reduz]

This is pretty interesting, but not very doable on GLES2, not sure if it will be doable on Vulkan either (could try).

[kaadmy]

Just tested this, the light function doesn't actually override lighting in GLES2, since specular etc seems to be modified by the shader regardless of having a custom light function. This debug mode actually just uses a regular shader (same syntax as Godot's shading language), and can be used on any material when using the GLES3 backend. As long as Vulkan behaves similar to GLES3, it should work fine.

This running on 3.1 stable with GLES3:

[akien-mga]

Commits should be squashed together.

@clayjohn Any idea on the feasibility of this feature for GLES2?

[clayjohn]

@akien-mga I think it is possible. But most of the work would have to be in the cpp code. In GLES2 each light draws the object an additional time, so changing color based on number of lights doesn't quite work as each iteration of the light shader cannot rely on previous iterations as it does in this PR. However, you may be able to set a custom shader like this, say an unshaded shader, then set the albedo color based on the number of lights by providing a uniform.

That being said, none of the other debug draw modes have been ported over yet. So including this in GLES3 only isn't really a big issue.

[kaadmy]

Since there seems to be some activity for this PR I'll weigh in a bit and say that some like what @clayjohn mentioned would be a lit cleaner, ie. just pass in the light count as a uniform. I can't think of any other uses for the uniform but it'd be a lot simpler to port to other renderers.

[clayjohn]

IMO we should merge it as is and then deal with GLES2 at the same time as the other debug draw modes.

[kaadmy]

If this gets merged then maybe there should be a bit more work to get this to work well without environment changes by the user, for example right now this may require custom post processing/environment settings (see the notes on the above screenshot for the TPS demo) to work correctly.

[clayjohn]

I see, I missed that comment. Yea, more work will need to be done to disable those effects when using this draw mode. It should be possible to do it within rasterizer_scene_gles3.cpp though.

Let me know if you need some help finding where you need to disable stuff/change stuff and I can look into it a bit for you.

[aaronfranke]

@kaadmy Is this still desired? If so, it needs to be rebased on the latest master branch, and redone to support Vulkan.

If not, abandoned pull requests will be closed in the future as announced here.

[aaronfranke]

This PR has not received any new commits for over a year, closing. If this PR is still desired, it would need to be redone to support Vulkan as per the above discussion.