Handling lots of lights in a scene and lights with instanced meshes

I am making a scene where I will be using a lot of lights. However, I am currently running into the max 4 lights per material issue and seeking ways to overcome it. I have about 20 lights within my scene.


In my example, I’m simulating my code in a play-example of my issue. I want every individual skull to have its own light shining on it. If I use { doNotInstantiate: true } the lights will work for each, however if I set it to false, it does not work. (See lines 40 and 41 to change behaviors. Line 41 has what I want visually, but Line 40 has what I want with instances).

Other Materials:

This post seems to ask the same question, but resort to baking light in. However, scene I have has lots of lights that move, animate, etc.


  • Can I have instanced meshes with each having their own light sources shining on them?
  • I’m aware you can change maxSimultaneousLights to be higher, but I don’t really want to do that. Therefore, it would appear that the only way to allow many lights is to filter what meshes the light can interact with. How do folks handle that in an environment with lots of meshes: is there any good strategies for handling this? I have floor tiles, and i’m thinking that ill need to do distance checks from a light source to determine if it should be effected, does that sound correct or way off?
  • Is there any upcoming features to address the short comings of lighting? This seems wicked limited at the moment. I look at examples like Divine Voxel Engine - Voxel Engine Made With Babylon.js - Alpha 1.0 Out Now, and there appears to be loads of lighting within their scenes, so maybe I’m just going about this wrong.
  • What would it take to get BabylonJS improved in the dynamic lighting department? I’m sure its loads of effort, but curious what that effort actually entails for algorithms/features.

I’m NOT a game engine/GPU guy (but I’d like to be). Any education on this topic would be greatly appreciated.

This thread may help - Dynamic enable of point light
With real time rendering there always will be some limitations.
What is the use case and how much lights should be visible simultaneously?

1 Like

@labris Something like this youtube video would be the closest thing to what i’m trying to make, where these lights would be animated, flickering, and I wanted to have interactions where lights would completely turn off and turn on. I think at the moment, I was thinking ~20 in the room. However, rethinking the design could likely bring it down to ~10.


Why not? It would be the way to go and with this, you could push your lights to say 8. Of course, it will impact perf but it remains achievable. You would just need to control the use of other resources to have a minimal impact of perf.

I don’t know about the others, but I use identifiers in either the ‘name’ or ‘id’ of meshes or materials to make a selection. Say I want a mesh to collide, receive light from light source 1 and cast shadow. I would give an id or name to my mesh that includes these identifiers. I.E: “meshname_col_L1_S0” (where ‘meshname’ is the mesh name (lol), where ‘col’ means it’s a collider, where ‘L1’ means it receives lights from light source group ‘L1’, where S0 means it does not cast shadow (0 being a bolean, 0 to not cast shadows, 1 to cast). Then, at scene init, you can run a ‘split’ or ‘includes’ and through a forEach assign everything to your groups of meshes.

I’m not aware of that (but I’m not in the secret for everything :grin:) Though for having discussed this with the experts, I’d say it’s unlikely that you will be able to use a lot more dynamic light sources and shadows in a near future (my opinion only).

You did… Amazing piece of work, isn’t it? However you need to understand that this a completely revamped engine (created for voxels). In fact, it’s an entire new engine, as it name’s suggest. You won’t be able to implement this in a ‘regular’ BJS scene.

Interesting question. I will let the experts answer since I’m not qualified for this. What I can tell you is that there would be very deep implications in the logic and rendering. It would be nearly like writing a new engine in many, many aspects. I’m not sure this is the time for doing this. But as I said, I could be wrong (as often :joy:)…

You shouldn’t exclude baking lights completely in your strategy just because of that. You could animate a material, use a node material to simulate ‘lit’ and ‘unlit’. You could create a case where both baked and dynamic lights work together. I’m not saying, it will require some efforts but the performance gain shall be there.

1 Like

Great write up! This helps quite a bit :slight_smile: . In terms of why I don’t want to use maxSimultaneousLights is because it feels like i’m just kicking the can down the road. In a world where I have many lights, I would always be restricted to this number, which has a max value before it breaks.

I think one thing I’m not understanding is what are the limitations that cause such a strict dynamic lighting use in babylon. (FWIW, I’m no guru of GPUs or 3d in the web or 3D in general, so I really am just trying to understand)

fair enough. I’m also not the one who can answer this :grin: I’m just a humble user and servant :innocent:… If you really want to know more, all I can do is cc the true expert @Evgeni_Popov He might be willing to give you the explanation you are seeking. Just give it a little bit of time because he likely has more urgent matters to take care of :sweat_smile:

Though whatever his answer will be, I believe essential for you is to build a strategy using what is currently available. In that, I can eventually help you. As said, exceeding 4 lights simultaneously in scene will have a negativ (eventually heavy) impact on performance. Reason why, I would look on the side of baking lights, moving lights, and using node materials and eventually chanelling multiple lightmaps.

1 Like

Truthfully, moving lights and designing an environment around that idea seems the most reasonable based of what you said and @labris linked.

I am very interested in the expert opinion, but no rush on Popov’s answer. I got time to mull things over for a while :slight_smile:

Clustered forward rendering (you can search for the terms in Google, you will get plenty of references - for eg A Primer On Efficient Rendering Algorithms & Clustered Shading.) would be something nice to support, but would likely have some big implications on the current architecture…

1 Like

Here is the PG example with 70 lights (see console) - https://playground.babylonjs.com/#WJWSNL#12

1 Like