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

https://github.com/user-attachments/assets/f04bca65-624b-4e4f-8698-29f814449d6c

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

[ghost]

I would love this feature,

[metalgearsloth]

Also I would note that content can entirely override this as it sees fit, e.g. they can draw directly to the light render target for tile emissive or rooves or whatever and it probably needs an event attached.

[metalgearsloth]

Note that I don't expect you to actually do it in this PR but I do expect content PRs to be frozen from using this until it is implemented.

[Chubbygummibear]

Note that I don't expect you to actually do it in this PR but I do expect content PRs to be frozen from using this until it is implemented.

i would be willing to try fixing this up in a more optimized manner and in a way that better fits into the content/engine schema, but I would definitely need help since I'm very unfamiliar with the ECS paradigm, and content/server/shared system. I have enough experience to get things working, but when you say like "consider parallelism", or when I should or shouldn't dirty a component, it's totally new to me.

[Lumminal]

it'd be amazing if this was finished properly, we really need it to unlock a new area of content (light-based mechanics). Author doesn't seem active on this anymore so its kinda sad

[Chubbygummibear]

it'd be amazing if this was finished properly, we really need it to unlock a new area of content (light-based mechanics). Author doesn't seem active on this anymore so its kinda sad

oh don't worry i'm still suffering away at this. it got review again because i poked different devs. i was pretty confused on what needed to be done and the best way to do it, so i needed head dev help. i've had like 2 different ss14 servers poke me recently asking if it would be possible to get a portable version of this, but not really without touching the engine, so i basically have to keep at this even though it's in a nightmare state of bandaids and workarounds