Illumination measuring system to determine how "lit up" entities are

[Chubbygummibear]

Please bear with me since this is my first large PR and like 2nd PR ever for SS14/RT, so I expect I made a lot of mistakes that will need to be rectified upon review.

Overview

This is an entirely new system that is designed to serve as a tool for content systems that would like to know the illumination level of a given entity. This is achieved by querying a PointLightComponent Tree on the server to determine which lights are nearby, then uses a raycast query of the Occluder Tree System to check for occlusion. Any lights after that which are both in range and unoccluded have their light power multiplied by an attenuation function to get the final light value applied to the entity. Only the most powerful light value on the entity is kept. That value is cached in the corresponding component and returned upon calling the TryGetLightLevel function.

The system does nothing on its own and needs to be triggered by other systems calling TryGetLightLevel which will cause the light calculations to occur. There is a cooldown of 0.5 Seconds on getting the light level re-calculated unless a boolean to force the update is called. If many calls are made to the function in a short time span, the cached value will be returned without rerunning the calculation. This way, if numerous systems call for the light level in the same tick, and every tick. The most expensive operation will not be called every time.

Demonstration

2024-12-23.14-05-53.mp4

It does work with masked lights as well, although i had to refactor the way light mask prototypes work to accomplish this.

Limitations and concerns

• Naturally performance is a concern, as this is using raycasting frequently to check for occlusion. I did my best to mitigate the impact by implementing a cooldown for how often the system should be allowed to do so, as well as implementing the ability to define cooldowns on a per system that calls this system basis.
• Animations is a big one. With animations like spinning lights, flickering lights, and dimming areas being handled entirely on the client, there's no way to access this effectively on the server to know that the lights have changed in some way.
• Client and Server PointLightTrees function independently of one another. This is due to the fact that the SharedPointLightComponent is abstract, and ComponentTrees do not like abstract or virtual classes at all. To make these trees synced, all the Client and Server PointLightComponent attributes would need to be moved up into the Shared space. Which in and of itself is a large refactor.
• Small gripe but I'm not sure if LightSensitive makes sense anymore, because initially this component/system was going to send out networked events on regular intervals, but i later opted to just put the onus on other systems to call this one. Maybe it should be EntityIllumination or something

Anwyay, I did my best to bring back this functionality that was pretty core to old SS13 and hope we can work together to get this in and further develop with the new design space

[Fansana]

I would love this feature,