Recently I have been trying to use “inverse square” lights and even though I understand they are loosing energy exponentially with distance and also how they light the scene greatly depends on the Eye adaptation, tone mapping and some other PP, but they still look to me a bit too dim.
If you put a spotlight into scene, set it to 1000 lumens, put it 1m above a square the size of 1x1m, which should lit the surface with 1000 lux and play with the tone mapping, eye adaption, it still somehow looks too dim compared what I would expect from a 1000 lumen light (or 1000lux for that matter).
I understand how hard, complex and complicated might be to transfer real life lighting into game engine, deal with eye adaptation to display where engine is doing another eye adaptation and so on 
.
So I guess I just want to be assured that there is no bug in the lights and “inverse square” feature before I go crazy with my inverse square lights in maps.
Sorry for the trouble.
The falloff is definitely inverse squared which is physically accurate. There is a factor that treats the falloff as if it is an area light so that is doesn’t go to infinity when the distance becomes zero. That factor will probably be exposed in the future. That will only have an effect when the light is very close to the surface.
The brightness on film for a light of 1000 lumens is a very fuzzy concept. To match a photo the amount of light gathered and attenuated from the camera lenses and body as well as the response of the film for a particular setup would have to be exactly matched. We don’t have exact matches to real world camera values for any part of the camera. We try to match behaviour in every respect that we can but matching values isn’t that important to us.
So that said, lumens to pixel brightness is a fuzzy concept. The general scale was eyeballed to roughly match a photo for a chosen exposure value. If you would like a different match you can easily adjust the exposure of the camera.
Thanks. Yeah, lumens, film sensitivity and all real camera features and parameters are pretty complex stuff and unnecessary complicated for game engine.
I guess it would be unnecessary to have some “global multiplier” for the light intensity in .ini file so one could setup the project to have “intuitive” values for lights when having lumens in mind?
Hi Tomas,
Thank you for your question. I have tested the inverse square falloff property and it looks like everything is in order. You can see how the brightness scales very differently if you download the ContentExamples sample project and open the Lighting.umap. In that map is a demonstration of inverse square falloff vs a regular spot light. You will see the standard light is ~6 lumen and the other light (using inverse square falloff) is set to ~197714 lumen to match the brightness against the far wall. I hope this helps to answer your concerns, please let me know if it does not.
Thank you,
Alexander
To be honest, I saw the ContentExamples and 197714 lumens is pretty huge. Afaik direct sunlight has around 100 000 lux and if you would spread the content example light over 1x1m from 1m distance it doesn’t look as if 197714 lumen light is lighting the surface.
As I said, I think I understand how much eye adaptation and HDR->LDR can affect lighting, but still the lights with inverse square falloff look like their intensity is fading much faster then would expect from a real life light with same lumen intensity. Put it other way, I would intuitively expect a 197714 lumen light to be much, much stronger then it looks in Rocket.
But well, if it’s working correctly (and if by some bug isn’t the inverse square further squared ) then I guess I just need to “adjust” my expectation (but… 197k lumens is really a LOT).