# Limit to number of spotlights

There is an odd effect, when you add more than 4 total spotlights:

Note that the last yellow spotlight does not show up.
However when you decrease the external ones to 2 instead of 3, everything is fine.

Is there a maximum number of 4 spotlights? If, so this should be documented, e.g. in Spotlights.
Can one increase this number?

I did find now in the documentation

That 4 is the limit to the number of lights. It mentions that this can be increased, but not how.

â€¦ some warning â€śTotal number of lights exceededâ€ť may be quite usefulâ€¦

To increase the number of lights available at one time for some material, use

``````material.maxSimultaneousLights = 8;
``````
1 Like

Hi everybody,

I have the same problem than @RainerHeintzmann . In the docs, the max number of lights is precised for a standard material. But which max number of lights could we use for a PBR Material. Is it the same ?

See also this thread for the maximum value you can put in `maxSimultaneousLights `:

May be the documentation is not clear to me. I assume that Iâ€™m able to give a maxSimultaneousLights value to each material.

Hereâ€™s a PG : https://playground.babylonjs.com/#20OAV9#12950

there are 20 spots and 1 natural lights on 2 grounds with two different materials. Each material has a maxSimultaneousLights value equal to 10.

The first ground is well enlighted, there are 9 spots and the natural light

BUT :

Why the second ground is not enlighted with the spots ?

Second example : https://playground.babylonjs.com/#20OAV9#12951

each ground is enlighted BUT the total number of lights is still 10

It seems that the TOTAL number of lights has to be equal to 10 but not for each materialâ€¦

As an additional remark: Spotlights (with procedural textures) not showing up, as in my case can sometimes cause errors, which are extremely different to trace to the origin. The effects caused in the scene can be very indirect. If this had been an error showing up (Max number of spotlights exceeded) or at least a warning (which I might have overlooked), this could have saved me days of work. So maybe one can think about this in a future version?

@bvaisman `ground2` is still impacted by the spots 1-10, and because max lights is 10, spots 11-20 donâ€™t impact it.

You should indicate that spots 1-10 only impact `ground`, and 11-20 only `ground2`:

Yes, itâ€™s the same for all types of materials.

We canâ€™t really do that, because having more lights than `maxSimultaneousLights` could be done on purpose. For eg., you could define 10 lights and set `maxSimultaneousLights=4` for a material, knowing that only the first 4 lights will be used.

Could you elaborate on this one? I donâ€™t see the link between spotlights and procedural textures (?)

I donâ€™t quite understand why one would want to do this. But even if so, a warning would not really hurt, and one could also put in a way to disable the warning. I honestly think a default warning or even a default error would be the best, as I suspect many users already fell into this trap and many more will.

As for the remark to procedural light being even more difficult to detect: In may case, I blamed not seeing the effects caused one of the two procedural light always to some error of calculating them and it took me ages to understand that simple the whole spotlight was not showing. I actually fell into this trap now multiple times with a few month in between, which triggered me to suggest to raise a warning /error. In fact, I even read somewhere that it would raise an error, which it does not.

@Evgeni_Popov

Ok, I think I understand a little bit better. A light impacts a mesh even if it is not directly enlighted, is it true ?

If iâ€™m right, maybe the documentation (Limitation chapter) should be a little bit more precise.

2 precisions :

• Speaking of â€śStandard materialâ€ť in the Limitation Chapter is not useless because all materials have the same behavior about the maxSimultaneousLights limitation.

• Writing that a mesh is impacted by a light EVEN if it is not directly enlighted and give a piece of code with the includedOnlyMeshes property.

Maybe I can contribute to the doc if you think it is useful. Tell meâ€¦

To be more exact, a light impacts the material of a mesh.

@labris, youâ€™re right, a light impacts a material, thatâ€™s why all meshes are â€śimpactedâ€ť even if they are not directly enlighted. Am I right ?

I feel your pain, but Iâ€™m reluctant to add a new check in the hot path, as itâ€™s only for validation purpose, and in Babylon.js we generally donâ€™t validate inputs for performance reasonsâ€¦ I think improving the doc should be a good workaround.

Letâ€™s cc @sebavan to get his feeling.

By default, all lights (up to `material.maxSimultaneousLights `) affect all meshes. It would be too time consuming to calculate if a mesh can be lit by a light. Itâ€™s the user responsibility to do a better job if they know which lights are going to affect which meshes.

Yes, please, improving the doc is always a must!

No, a light impacts a mesh, but only the first `material.maxSimultaneousLights` lights. You can explicitely define the meshes that are impacted by a light by adding the meshes to `light.includedOnlyMeshes`. If you donâ€™t do it, the first `material.maxSimultaneousLights` created lights will impact the mesh.

Let s not add more code in the hot path and those lights scenarii are fully dynamic as you could rely on inclusion/exclusion to ensure a scene with 20 lights only contains materials impacted by 4 lights max for each of them so the check is more dynamic than simply at the scene level

I am not sure, but I can imagine that the current code anyway needs to check for exceeding the spotlight but the â€śelse branchâ€ť just ignores further spotlights. For this reason the overhead of throwing a warning or error may be minimal.
But then there may also be a chance to add code that checks this condition at the point of creation of the spot, which would then not be in the hot path and have the big advantage that the error/warning is only produced once. Since I fell into the same trap already twice, and it cost me days to find out, I think it may be a good decision to have such an error/warning.

No, the code is:

We canâ€™t do that, you could create 100 spots and assign them any way you like among your meshes (thanks to `light.includedOnlyMeshes`).

Thanks for looking into this. So â€śBindLightsâ€ť sound like a function, which is not really called on every rendering pass.

If this is true, it would not be a big problem to add just the check. `Math.min`, anyway calls something like an if, so it probably does not even add time to replace the `Math.min` with
` let warn_once = true; if (mesh.lightSources.length < maxSimultaneousLights) { len = mesh.lightSources.length} else { len=maxSimultaneousLights; if (warn_once) {console.warn("You used more lights than allowed by maxSimultaneousLights."); warn_once=false;}}`
or something along those lines.

it is called for all submeshes/materials on every frame which is on the hot path.

1 Like