Allow Lighting from ent files

[aepod]

If we could have lights here, we would be able to fix maps without having to edit/recompile. Many old maps are difficult to play on because of darkness.

I am looking at the Lokis Minions maps mostly, as it has a pretty active community still.

https://photos.app.goo.gl/Jbipn1TMjNTu2cfo9?fbclid=IwAR3d8OmFVROvIBdOit6AYPt18aocNDhb2W2DUxy23WrEdnX0Fs1XM4rSdTs

Here in the stills you can see dark areas. I also used an old demo from 1999, and the results look stunning, but you will notice the dark areas near the lava would make it near impossible to "play" this way.
https://www.youtube.com/watch?v=prNwu09khnA

{
"origin" "1448 968 -96"
"light" "100"
"classname" "light"
}

This is an example of a light from the ent file, new classname could be added for other types of lights, to accommodate quickly fixing older maps. I suggest doing different types of lights with some ability to change parameters.

[juks01]

The other way could be to update the client to support those original light sources (entity lights?).
It would probably fix the problem on almost every mod and map.

[aepod]

The original q2kpt had this issue and there was even a potential path forward outlined here:
cschied/q2vkpt#21 (comment)

As for the dynamic bsp lights: The indices in the instance buffer need to be added to the light list (https://github.com/cschied/q2vkpt/blob/a4de8e90ea86a31e0cc8c6f74303c2dd473a56ca/src/refresh/vkpt/main.c#L916) but for that to work as expected the bsp entity meshes need to be separated into lights and non-lights (https://github.com/cschied/q2vkpt/blob/a4de8e90ea86a31e0cc8c6f74303c2dd473a56ca/src/refresh/vkpt/bsp_mesh.c#L203)

I am trying to track down the light list, this has moved in RTX, looks like it should happen somewhere in this function: https://github.com/NVIDIA/Q2RTX/blob/master/src/refresh/vkpt/main.c#L1616
or in the process_bsp_entity() function.

The second item separating bsp into lights and non-lights also refers to code that was refactored to some degree.
bsp_mesh_create_from_bsp() function in
https://github.com/NVIDIA/Q2RTX/blob/master/src/refresh/vkpt/bsp_mesh.c#L1623

[savvykms]

I actually forked q2rtx specifically to take a swing at this:
https://github.com/savvykms/Q2RTX/tree/entity-lights

My current build doesn't seem to be functioning properly, however. I was also hasty in my design, so it's likely not the best approach. I'm just roughly mashing together the normal quake2 game logic's way of parsing the entity string from the loaded bsp_t object, caching it, and rendering it each frame. These entity lights would affect the static lighting in the map during compilation, and qrad3 (or similar) could have its settings adjusted when run, meaning each map could have different values - this is especially noticeable for maps created 2005+ where people really started tinkering due to better hardware.

I haven't addressed conical lights (e.g. when one targets another entity), "dynamic" entity lights (e.g. light styles with flickering etc), lightramp entity logic, lack of IR functionality, or significant changes to some dynamic lights that certain mods (e.g. gloom) used for lighting around player entities in certain conditions,

[savvykms]

I imagine a better solution is to provide property files for each map and create a tool that can analyze the original map, taking into account the original entity strings and lightmaps, to try to reproduce as close to original light settings as possible. The tool could be run independently or we could introduce logic to call embedded logic when the renderer is initialized for a given map - this could conditionally check for the existence of metadata indicating it's managed by only the tool; when someone tweaks by hand, they could introduce a setting specifying the tool shouldn't be re-run.

This allows for a high degree of caching behavior, the ability to update algorithms without worrying about system-generated content, and the ability for manual tweaks to be maintained; similar to entity override files provided by some popular quake2 clients like R1Q2.