How can I support many point light sources in a dynamically-generated level in Unity?

Question

I'm currently working with a dungeon game which is similar to Dungeon Keeper by Mythic Entertainment. I'm using Unity and developing this game for Ipad 2 and above. Player can modify his dungeon, and I'd written a dungeon generator which creates it. In this case, I can't use lightmaps, because the dungeon has been created dynamically and player can tweak it. I also devised a way to combine separate game objects in a single mesh, so imagine that the entire dungeon (except special objects such as pillars, statues and mobs) is the single mesh. There's many point light sources (10-15 and above) on the stage, but Unity don't allow to use more than 8 light sources per object.

So, if all dungeon cells are separated objects, I can use the diffuse or even vertex-lit lighting, but if the entire dungeon is a single mesh, there's the hardware limit appears.

Ways to solve this problem I'd divised:

• Use separated geometry (tried) - bad, because it harms berformance because there's many-many-many drawcalls (16-17 fps on Ipad 4).
• Use deffered shading (tried) - bad, because it harms performance even more than separated geometry.
• Use a custom shader (haven't tried) - I don't know how.
• Don't unite all cells in the single mesh but unite groups of cells to reduce the number of separated objects (haven't tried)
• Use the light manager (haven't tried) - I don't know how.
• ???

How can I deal with it?

Answer 1

This would probably best be solved with a Scene Manager. Specifically a quad-tree. Which will probably require a little bit of scripting, but it'll help a lot.

A scene manager solves the problem of dividing the mesh, the problem being that there are too many draw calls. So what you do, is you divide the scene into small parts, and then only render the parts that are on screen. So since the rest of the scene isn't rendered, you have less draw-calls. You should be able to change what is rendered and not rendered by disabling the mesh renderer.

That's how I would do it anyway. Though I'm not very experienced with Unity3D, so the above answer is just generic game-dev theory.

Answer 2

Deferred lighting should be the ideal option here, along with perhaps better partitioning in your scene handling code (culling out objects that are far enough outside the view frame that they cannot impact the scene; this can be done with quad- or oct- trees for example

Deferring shading is a multi-pass technique that involves first "rendering" data for use in eventual shading computation into render targets, and then sampling from those render targets in a later pass to produce a final scene.

One of the particular advantages deferred shading offers is the ability to have an extremely high number of light sources, because the light source information is rendered into the early-pass targets exactly as you would render geometry; the cost per light is roughly akin to the cost of rendering a screen-space quad. The disadvantage is that it does not naturally support transparent objects, and if you need those, you need to apply additional techniques or render them in a non-deferred way.

Unity has a deferred rendering path you can look into.

I am suspicious of your claims that you tried and discarded the deferred approach because it was too performance intensive. iPad 2's aren't the best hardware these days, so you might have problems there, but the 4th generation iPad's should handle a well-constructed deferred renderer fairly well. I suspect that somewhere there is a bug or potential optimization in your implementation, and it may be worth posting a new question to explore that.