3
\$\begingroup\$

I'm writing a top-down 2D tile-based game and I'm trying to decide on how to implement lighting and shadows. The game will have a large number of light sources, some static and some moving around the game world. However each light will only have a radius of a few tiles so I don't expect a large number of lights to affect the same pixel. Also, ideally, I'd like to be using normal-mapped sprites combined with the direction of lighting to give some depth to the lighting in the game.

My current plan is to render the whole screen to an off-screen buffer without lighting applied (diffuse) and at the same time rendering the UV normal maps to a similar offscreen buffer, much like in this excellent post from Wholehog Games.

enter image description here enter image description here

At the same time, I plan to calculate and store the geometry of areas that are to be lit by each light as a triangle-fan mesh, similar to this truly excellent post on 2D shadows by Amit Patel (Red Blob Games).

enter image description here

Given this set of light geometry and the diffuse and normal maps to work from, I believe I should then be able to draw the final scene to the screen, first just as the diffuse drawn with low ambient lighting, then blended with each light source using its geometry of which areas to affect and shaded using UV/bump mapping for that light source. This will end up rendering the light's geometry for each visible light to only the area it affects.

Does this seem like a valid approach to 2D lighting that's going to be performant enough with a lot of lights on screen? As a relatively inexperienced graphics programmer, I don't want to set off down this route without at least sanity-checking it with the community :)

Although I'm trying to keep this question platform-agnostic, I'm using Java/LibGDX/OpenGL on modern desktops only (so I'm not accounting for less powerful tablets and mobiles).

|improve this question
\$\endgroup\$

closed as primarily opinion-based by Stephane Hockenhull, Josh♦ Jan 15 '16 at 16:28

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ I don't really understand how to approach lightning well, however, deferred lightning is what this technique looks like... Supposedly, it allows a higher number of lights than normal forward lighting so the answer might be yes. \$\endgroup\$ – rlam12 Jan 15 '16 at 16:25
  • 1
    \$\begingroup\$ Yes, it seems functionally viable. Beyond that it's too broad ("how well/what are the tradeoffs") or too opinion-oriented ("will it look good") of a question in it's current form I'm afraid. \$\endgroup\$ – Josh♦ Jan 15 '16 at 16:29
  • \$\begingroup\$ I guess that's all I'm really looking for - that it's at least a feasible approach that won't require so much rendering effort even modern desktops are going to choke. I suppose my question is about the viability of the performance of the approach in an attempt to avoid being primarily opinion-based on the final result. I guess I'll just have to try it and see! \$\endgroup\$ – Ross Taylor-Turner Jan 15 '16 at 16:33
  • \$\begingroup\$ For those interested in the follow-up I did end up implementing this dynamic lighting model to great success, somewhat detailed in kingunderthemounta.in/dev-blog-2-let-there-be-light \$\endgroup\$ – Ross Taylor-Turner Dec 1 '16 at 10:38