Lighting limitations?

I had a couple questions about lighting limitations.



I’ve seen in other threads that lighting can be a stumbling block for decent frame rates, seeeeeew… I’m interested in hearing how other people are tackling this issue.



My thoughts were:



Defining a fixed number of point lights and particle emitters for lamps/torch light/etc. and positioning them according to where the player happens to be at the time. Since all light positions are predefined in my case, it would require distance checks… possibly line-of-sight checks past a certain distance… to know where to place the lights/emitters.



Right now… any given scene consists of: Single directional light (if outdoors), single ambient light source and a single point light that follows the player (enabled and disable depending on time of day/indoor or outdoor). Guess it is worth mentioning, that I am not using a shadow renderer… and don’t really have plans to add it.



Anyways… to the questions:


  1. What limitations (if any) have other people seen with number of lights used?
  2. Considering (a potential) 3 lights being used already… what is a safe bet for the number of point lights I could potentially use before a lower-end machine might start experience unacceptable FPS?
  3. I also have a control to adjust the lights size and color to approximate a torch’s flicker effect. I assume that this would not effect FPS, as the light effect has to be rendered whether or not it is constant. Is this an accurate assumption?
  4. Any other approaches I may want to consider? I looked into texture baking, cool… however, I am relatively Blender illiterate.



    Thanks in advance!

The variables are too abstract at this point to give you an answer. Even with “3 meshes, 500 triangles each, 4 lights”, the answer is still “test it”. It depends on not just the number of lights but the meshes being rendered, any shaders, any other code happening in your update loop, etc.



Texture baking is a widely accepted approach to reduce rendering load and a Google search would bring up loads of results on how to do this in just about any modeling tool you could conceive of :slight_smile:

1 Like

One thing we can say for certain, every light adds overhead. (After all, in multipass lighting it renders the scene once per light) Whether the overhead is acceptable in your case falls back on what sbook is saying.

Thanks much!



I appreciate the information.

@pspeed said:
One thing we can say for certain, every light adds overhead. (After all, in multipass lighting it renders the scene once per light) Whether the overhead is acceptable in your case falls back on what sbook is saying.


U sure?

One light and 2k boxes runs as fast for me as
2k boxes each with a light added to the box.
(>At least it did, made a test one year ago or so.)

I would guess the amount of passes are already minimized by using this.

Yes, and each box is only lit by the one light. So I would guess that can be done in one pass basically.



Add two lights to the root node of 2k boxes, I suspect you will see a performance difference.



But your point is valid, if you properly partition your scene and you can somehow arrange for your lights to never overlap or you somehow keep track of which ones overlap, etc. you can minimize the work done, I guess.



…baking in the lighting would be easier.

There seem to be changes going on. There is a deferred lighting material def in light but I don’t know about its status. It seems to be using multi pass lighting at this point.



Maybe this will be an alternative later.

deferred was just an attempts to deferred lighting. This feature has been postponed to the 3.1 release.



Deferred lighting computes lighting in screen space (like a post process filter), it’s a widely used solution to address this issue. For a forward rendering the complexity of the scene is nb object x nb lights, for deferred rendering it’s nb objects + nb lights.



Right now your options are :

  • Partionning your scene so that any object in the scene is never affected by more than one light.
  • Bake lighting into a lightMap. also that will only work for static objects.

Out of intrest, is there already a nice solution for transparent objects in deferred lighting?

Yes, it’s called Inferred Lighting (see here). I’m experimenting with it. You can only have a limited number of transparent layers though.

1 Like

Heh… I’m getting all sorts of useful info out of this.



Thanks a ton, all!



With the current setup of my scene graph, I will be able to limit the lighting to zone (landscape, structures, etc) geometry only… which should never really stress the render time, if I limit the number of lights and position them according to player position, direction, etc. I’ll look into baking textures as well, however, this solution would require that I have closer to finalized graphics… which I am no where near having.

This inferred lighting paper is really interesting.

@survivor said:
Yes, it's called Inferred Lighting (see here). I'm experimenting with it. You can only have a limited number of transparent layers though.


Well for most appliations 3-4 layers would probably be enough. (Or dynamic, you could basically get the maximum amount of needed layers from the geometry sorter, or am I wrong here?)