Final simplified lighting tutorial...
-------------------------------------
There are 4 basic core categories of lights, 2 dynamic and 2 baked:-
1> - Dynamic shadow-casting lights (always spot).
2> - Dynamic non-shadowing fill-lights (usually point, can be spot).
3> - Baked static lightmap (spot or point).
4> - Baked irradiance volume (point from lightmap).
Further categories can be assumed, related to their size and brightness, but these 4 are how they are technically classified.
Light entities should be named, organised (by layers) and exported according to these categories, to be independently processed.
These categories exist and coordinate to keep performance high and to support each other visually:-
- Category 1 casts shadows and can be dynamic but is constrained by memory concerns.
- Category 2 is used to "flesh-out" the starkness of relying only on category 1 but cast no shadows.
- Category 3 paints the walls with baked lighting to handle visuals away from player actions, with abundance.
- Category 4 tries to prevent dynamic objects becoming completely dark when too far away from category 1 and 2.
Depending on certain factors, category 1 lights are usually constrained to 4-8 lights per "area", possibly per sector.
Category 2 is just a little more, at 6-12 lights, but both of these categories are also governed by user settings.
These 2 categories use dynamic lights of which no more than 3 should overlap, a rule for all dynamic lights,
no matter of which technical category, or type of light, or even if they cast shadows or not.
In category 1 and 2, assume use of primary and secondary "stage" lights, with category 2 being more flexible.
Category 3 is the most powerful and can use theoretically unlimited lights of any type, cast shadows or not,
but is entirely static and basically baked to a texture that can not directly illuminate dynamic objects.
Lightmaps are able to use non-circular and textured lights, radiosity and global illumination, and even manually painted.
The downside is reliance and coordination with the next category, as dynamic objects are not affected.
Category 4 solves this but is the hardest to tame - irradiance volume that does a basic light pass on dynamic objects.
It's derived from the lightmap or a combination of all lights, but has a limitation of X number of lights per "cell".
While the compile process discards lights it can't support, those lights are simply taken from the highest index.
Therefore, as insane as a lightmap may become, the irradiance volume needs curation, to avoid unpleasant splotchy visuals.
The good news is that this would only really affect arrays of lights used to create non-circular patterns, such as trims.
The following images attempt to demonstrate these principles:-
(looking top-down into a room, the lighting might be something like this)
...(acceptable overlap of dynamic lights):
...(unacceptable overlap of dynamic lights):
...(the main shadow-casting dynamic spot-lights, with two facing the sides and two facing the center):
...(spot fill-lights that don't cast shadows to help flesh-out the corners):
...(primary point-lights that don't cast shadows, to support the main spots):
...(secondary optional point-lights that don't cast shadows, to support the main spots):
...(other lights used for baking the lightmap and irradiance volume):
...(an array of point lights packed together to appear as a streak of trim-lights):
...(a modest (potential) version fed to the irradiance volume compiler):
...(how the compiler will actually cull down the streak to the maximum number of lights):
...(how we want the compiler to cull the streak):
...
Some best approaches to having these kind of clinical patterns in a lightmap that will behave well with irradiance volume:-
Assume the cells, at the least, are about 128x128x256 units, with a maximum of 3 lights per cell. Begin by plotting those 3.
Now copy those 3 to offset them so that (evenly dispersed) it becomes 6, becomes 12, becomes 24, etc.
Irradiance volume options will likely be implemented, as high as 64x64x128 with 9 lights per cell, estimated.
As a last resort, the indexes could be randomised to avoid splotchy visuals, but it would likely still look messy.
Luckily, the irradiance volume compiling can be quick and not require rebaking the lightmap it's derived from.
.
.
.