NUKE leftover CPU lightGrid code, minor fixes and cleanup

[VReaperV]

• NUKE some code that was used before lightGrid was moved to the GPU, and which was now just waiting resources.
• Made r_forceAmbient (hopefully) work by actually using it with the GLSL lightGrid.
• r_forceAmbient and r_ambientScale changed to new-style cvars, +some cleanup.

[illwieckz]

If it WFY, LGTM.

[illwieckz]

Speaking of alternate lightgrid code, @VReaperV do you think it's technically doable to have a “lowest” lightgrid implementation (only meaningful for models), that would just sample the lightgrid color at the origin of the model (CPU side), and uniformly lit the whole model with that color (probably using the rgbgen fields), skipping entirely the lightgrid GLSL, relying on the fullbright GLSL code?

[VReaperV]

Speaking of alternate lightgrid code, @VReaperV do you think it's technically doable to have a “lowest” lightgrid implementation (only meaningful for models), that would just sample the lightgrid color at the origin of the model (CPU side), and uniformly lit the whole model with that color (probably using the rgbgen fields), skipping entirely the lightgrid GLSL, relying on the fullbright GLSL code?

Yeah, that would be easily doable. In fact, particles and trails already do pretty much that (but they interpolate between a few points) - which is kinda stupid, because it actually involves an IPC round-trip for no reason...
Why do the uniform lighting for models though?

[slipher]

If r_forceAmbient is overriding some value specified by the BSP, shouldn't the cvar be off by default?

[VReaperV]

Perhaps. I just used the value that was already there for it.

[VReaperV]

There's also the issue that there could be maps relying on it.

[illwieckz]

Why do the uniform lighting for models though?

Just as an ugly and cheap alternative for the “lowest” preset that would not be a cheat, because the model would still be dark in a dark room and lit in a lit room. It would save on GLSL processing and on GPU memory, and not involve 3D textures in GPU memory. Just a cheap alternative that would not be a cheat.

[VReaperV]

(rebased)

[VReaperV]

I'm merging it as is, if there are further concerns for the default value of r_forceAmbient, they can be fixed in a different pr, since it's just a single number change. This pr does not modify the default value, nor its range from what we already had (with reasoning outlined in the review).

[VReaperV]

Why do the uniform lighting for models though?

Just as an ugly and cheap alternative for the “lowest” preset that would not be a cheat, because the model would still be dark in a dark room and lit in a lit room. It would save on GLSL processing and on GPU memory, and not involve 3D textures in GPU memory. Just a cheap alternative that would not be a cheat.

You might be able to just use

Daemon/src/engine/renderer/tr_light.cpp

Line 188 in 5a071e2

int R_LightForPoint( vec3_t point, vec3_t ambientLight, vec3_t directedLight, vec3_t lightDir )

Interpolating probably shouldn't be too much of an issue? If it is, just simply getting the closest point can be done easily enough.