Question Why does not also a light source exist, that is not updated every single frame?

Baking lights bake a "fake" light into the texture, to make it look like, if there is a light burning...
But you can't change a baked light in the game, like turning a light switch to turn the light out!

And real-time lights are very performance heavy, because they need to update every frame. But if the light is not moving itself every frame, it feels at least for me like a lot of performance waste, especially if you need very much of them.

If you have a building for example with many rooms and the player should be able to turn on/off the lights...
What would be the best way to do it without wasting a lot of performance by putting a bunch of real-time lights in every room?
It would be great to have a light that is not permanent like a baked light, but is not always updating like a real-time light, something like how the real-time light works, but instead of updating every frame, why not updating it only if the "range", the "color" or the "intensity" was modified?

 

You should read up a bit more on how lights and lighting in general works. It's not that simple to just "leave" the effects of a light in place in the general sense.

 

I think the request is small scale light baking that updates the baked lighting at runtime when a change happens.

I guess the actual solution is precalculated light probes.

 

Even if the realtime light object isn't moving, the light source itself needs to give off light, don't you think?

Lights that do not affect the current scene are automatically culled if I remember correctly. It does however depend on the rendering engine and whether it's forward or deferred rendering. In one of the two modes (can't remember which, I think deferred) the number of light sources has no impact on render performance. In the other you are limited to at most x active lights (I believe it's 8 for URP). The rest just do not provide any effect to rendering, and the engine picks the closest and most intense ones first.

So ultimately, light count is mostly a time factor for baking lights, not so much a performance issue for realtime rendering.

Also, if you have fully enclosed rooms and can check the state of the only door leading into that room, you can write a script that disables most if not all objects in that room. Especially if you have lots of objects in there with scripts on them that have an Update method, and you also have lots of rooms and buildings too, that would be a sensible performance optimization.

 

Wouldn't it be at least possible to make a "Lite" variant of the realtime light, where the light makes a real fresh light calculation the first time like with realtime and then in each subsequent frame constantly recycles the calculated light data in a continuous loop until either "range ", the "color" or the "intensity" have been changed or the player has moved too far away from the light or is approaching it again. So whenever something happens or changes with the light, like the light, then recalculate and then always recycle the last light data in a continuous loop...

Would this work at least?

 

Sure, there's lots of ways to "do" light. The earliest way was just vertex coloring.

As long as nothing being lit in your scene changes or moves or rotates or anything.

The effect of light is dependent on far more than just the light, things like distance from light, angle of incidence, shader properties such as reflectance, specular, normal, etc.

To see what I mean, bake a cube in a scene with a light, then rotate the cube to see what happens.

Again, if you're curious about tackling this, don't start in a vacuum. Draw from over 60 years of some of the most-intensively-studied area of computer graphics. Lighting is a VERY well-traveled street, one I have barely even scratched.

 

As Kurt says, it's all been explored so you're not going to suggest anything new.

Calculating lighting in requires processing every object within range of every light source. If the content doesn't change, you only need do that once, record the results, and reuse those results. If the contents do change, you need to update. Depending on the complexity of your lighting that might be quick to do every frame or too time consuming.

An in-between method would be to record the baked lighting for different lighting states and show/blend between these states.

Another would be to perform the light baking process on a light change which, if the area affected is small enough, perhaps wouldn't take too long...although it probably would if rendering high quality bounced lighting and you'd have laggy lights.

Which is something we see in realtime GI systems that accumulate lighting over time, so they are dynamic and look great, but there's lag in the lighting and it's a moment between breaking a hole in a wall and seeing the light fill the room properly.

I'm not really sure what you're proposing though. Are you asking how to implement a new lighting mode in Unity as it is, or are you suggesting a change to Unity? I don't think either actually has merit short of writing your own Render Pipeline. Unless there are advanced light baking methods I don't know about that someone can explain enabling multiple baked lighting models and being able to swap between them.

 

Nope. There is no such thing as "previous data". The only data would be the previously rendered image in the frame buffer. Even if you were to preserve the previous frame's realtime shadow map as a texture - it would be null and void in the next frame if the camera moves even the tiniest bit - because there is no way to determine what new polygons have come into view that need to have updated lighting.

Read up on how rendering works, these are two great resources (for built-in and URP):
https://catlikecoding.com/unity/tutorials/rendering/
https://catlikecoding.com/unity/tutorials/custom-srp/

Generally speaking, you are on the wrong track with your basic assumption:

First of all, if you do have a performance issue: profile!

Secondly, whether realtime lighting is performance heavy depends entirely on the rendering strategy. If you use deferred rendering it doesn't matter whether you have 10 or 1,000 realtime lights. If you use forward rendering, consider switching to deferred unless you have a reason to use forward.

For example, if you are developing for mobile or WebGL you will have to use forward rendering, and should be extremely cautious with realtime lights to begin with. Here it's not a question of 10 vs 10,000 but rather between 1 and 10. Also, for those platforms URP really shines, particularly the new Forward+ renderer. I made this Forward+ lookdev test for WebGL and it runs at 120 fps (Chrome, start location) despite heavy postprocessing (Bloom, Depth of Field, Motion Blur, Tone and Color Mapping, Lens Distortion, ...) and 8x MSAA plus several realtime lights, likely a dozen or more.

 

Within Unity, perhaps. Conceptually, you can reuse data and some engines do - that's what temporal accumulators do for realtime GI. I don't know how theoretical LetmeDwight is going and if he's asking how to achieve what he wants in Unity or a feature request for Unity. But as a technique, you totally could use accumulated light data, rendering things that don't change once during runtime and re-rendering only when things do change, same as updating a BVH only when things change. Cacheing state is a commonplace optimisation. You could create lightmap textures, or light-probes, or the latest thing I've forgotten the name of.