Increase 2D Light cap

[Crusher48]

Describe the project you are working on

A top-down 2D roguelite that makes heavy use of the 2D lighting system and shadows to drive its art style.

Describe the problem or limitation you are having in your project

During my project, I am constantly encountering issues with rendering related to the 16 light cap. Any time more than 16 light sprites intersect an area (even if most of them are occluded by the environment), disruptive visual artifacts appear that can draw the player's attention and disrupt the desired visuals.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

If the light limit was increased to a higher number, these visual artifacts would not occur and gameplay would not be significantly disrupted.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The current limit appears to be hard-coded into Godot's default shaders. A fix would involve increasing the light limit constants and increasing the amount of space allocated in shader uniforms for light data to be sent. If possible, this should be a modifiable parameter (reducing shader space allocation for projects that do not benefit from this change), but that may prove difficult.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It is possible to work around this issue by replacing lights with additive sprites when shadows are unlikely to be relevant to the object, mitigating the risks. However, if a project has a significant quantity of moving or moveable lights, this will quickly become prohibitive, as unless every possible situation where 16 or more lights could overlap is accounted for, there will be disruptive visual artifacts.

Is there a reason why this should be core and not an add-on in the asset library?

The fix requires a change to core shader code, which cannot be modified by an addon.

[JVMV]

I'm also having this problem and i require it to be fixed to procced with the game i'm making. Which i intend to open a steam page for soon. So a fix for this would be very much appreciated.

[Calinou]

Unfortunately, the way 2D light rendering works makes it impossible to expose this as a project setting. The number has to be hardcoded for reasons similar to the number of 3D lights per mesh in the Mobile rendering method. This is done to ensure the shader can run as fast as possible (since it targets mobile devices), and because a shader that caters to a high light count would suffer from excessively slow shader compilation times (web browsers often struggle with this).

The constant that defines the maximum number of lights that can affect a given CanvasItem is defined here:

• Forward+/Mobile: https://github.com/godotengine/godot/blob/29b3d9e9e538f0aa8effc8ad8bf19a2915292a89/servers/rendering/renderer_rd/renderer_canvas_render_rd.h#L114
• Compatibility: https://github.com/godotengine/godot/blob/29b3d9e9e538f0aa8effc8ad8bf19a2915292a89/drivers/gles3/rasterizer_canvas_gles3.h#L99

However, you can't just increase this constant and expect lighting to still work correctly (I've tried just in case 😉).

I suggest looking into an alternative solution instead:

• Use smaller sprites to receive lights, so that it's harder to reach the limit on the number of lights per CanvasItem. Reducing quadrant size in TileMap can help.
• Use software lighting instead of Light2D nodes to light up your world. This is how it works in games like Minecraft and Terraria. Each tile is given a color using vertex colors, or you can apply a large Sprite2D with multiply blending over the game world that acts like a lightmap.

[JVMV]

Ill try using smaller sprites, thanks

[Crusher48]

Would it be infeasible to support an alternative rendering pipeline that is identical to the existing Forward/Mobile pipeline except for supporting an increased amount of lights? Alternatively, code generation could be used to change the values in the text files necessary for compilation to match the exposed project setting.

Will be quite unfortunate if there is no workaround though.

[Zireael07]

"Alternative rendering pipeline" means basically "duplicate all the rendering code"

[jmarceno]

No justification for it when you can clone the the repo, change 2 values ( linked previously in this thread) and compile a version that fullfil your needs, without creating redundance and extra work for the team.
Doing that is a lot easier than it may look like and instructions are very nice.

[Zireael07]

@jmarceno To quote @Calinou above

"However, you can't just increase this constant and expect lighting to still work correctly (I've tried just in case 😉)."

[jmarceno]

Sure. I must have missed it 🙄.
But I would try anyway if I was in the author's position.

Either way, this shows how even more unfeasible it is to maintain this new "rendering pipeline".

[Avantir-Chaosfire]

It would be great to have a commit available that increases the cap so that it could be cherry picked for custom builds. That would probably be sufficient to solve this issue.

[AThousandShips]

As explained above it isn't simple to do, and 16 is a lot of lights and enough for the vast majority of situations, and especially heavy for some devices like older mobile devices and the web, and the solution is simple: Break your objects up into smaller parts and you can have more lights

[Avantir-Chaosfire]

No, not a simple solution. I tested this, and it requires you to break up your object into more nodes. You can't just use one node with multiple calls to draw_texture. So with a sufficiently large area & dynamic lighting, you can easily end up with a need for 1000s of nodes to avoid crossing the light cap in common scenarios. That's not an acceptable solution.

16 is a lot of lights for the vast majority of situations, you're right. That's why I'm suggesting having a commit available to do this that people can cherry pick if they need to, instead of adding it into the core engine. I'm not suggesting that such a commit is simple to create - that's why it should be a commit, and not just a comment on a github issue.

[AThousandShips]

Anyone who wants to implement a higher light cap version is welcome to do so, and publish their custom fork! But making an official commit with those changes would involve testing and lots of extra work, and maintaining that as other changes happen in the rendering code, it's not just a change you can do once and then forget about it

I'd say most people:

• Don't run into this cap in the first place
• If they do normally do so because they have huge backgrounds or scenery in a single texture for a whole map, which is inefficient to begin with, and can just split it up
• The main area where it's difficult to fix would be lots of dynamic lights, but that's also a matter of design and handling the cases in code and design, avoiding these situations popping up in the first place, increasing the limit to, for example 32, will only help so far, you still have to avoid that limit, etc.

[Avantir-Chaosfire]

Also IDK if I just suck at testing this, but by my count in editor the cap is 15, not 16.

[Avantir-Chaosfire]

OK after working on this problem for awhile in my own project, I have some findings & thoughts to help other people encountering this problem:

• The 2D light cap is 15, not 16.
• The cap is per node - drawing multiple textures from the same node won't help. I think this is because the shader material is applied to the node itself, and that's what has the limit.
• The cap is not smart. It doesn't care if the lights are overlapping each other, and it treats every node as a rectangle. This means even if you have a non-rectangular polygon that is only directly overlapped by 15 lights, but there's a 16th light that doesn't overlap the polygon but does intersect the same rectangular area as your polygon, it will count towards the cap, and one of the lights actually on your polygon probably won't render.
• If you are using dynamic lighting, you have to limit yourself to a VERY SMALL number of dynamic lights. In my project, I can only have one dynamic light that can be arbitrarily instantiated, and fixed number of other dynamic lights. That limits me to about 10 static lights per node, assuming it's very unusual for there to be more than 4 of the arbitrarily instantiated lights.
• For most sources of dynamic lighting, you're probably better off using glow, as it has no such limit (but is much harder to control on a node by node basis and doesn't support shadows).
• If you're looking for more extreme options, you can:
  • Create a custom build of the engine and increase the light limit yourself (no idea how to do this, it would be nice if someone else could provide guidance)
  • Reimplement the lighting system on your own in-engine, using Node2Ds with a custom script to represent lights, and passing those to a shader via a buffer which you can choose the size of. I haven't experimented with this at all, but it should be possible. Basic, no-shadow lights should be pretty simple, but it's gonna get complicated if you want shadows.

[Avantir-Chaosfire]

Also an idea for improving this for the average user (I have little rendering experience, so someone please tell me if this won't work):

Godot could combine non-overlapping light textures into one and pass them as a single light to the shader. Shadow information would have to be combined & embedded into a separate texture too.

This should change the limit to only apply to overlapping lights, which would be a heck of a lot more practical. Nobody's going to care if lighting breaks down a bit when there are 16 overlapping lights. Heck, at that point you could probably reduce the light limit to 8 or so.

Also, if using that approach, instead of just not rendering the lights that can't fit in the buffer, you could still stitch them into the buffered textures, just overwriting any other lights at the same location. That could mean it would only be the overlapping portion that doesn't get rendered. Which, again, if there's that many lights overlapping, probably isn't a big deal at all.

[Calinou]

Godot could combine non-overlapping light textures into one and pass them as a single light to the shader. Shadow information would have to be combined & embedded into a separate texture too.

This sounds very slow to do because of fillrate requirements (drawing a large texture with large transparent areas is slow). Also, Light2D shadows are not texture-based shadowmaps - they are pixel-perfect. They're closer to vector-based shadows in that sense (e.g. stencil shadows).