In Fitz R_Marklights ...

[Baker]

[Spike]

each surface is defined as a plane. it has a forwards direction, it has an s direction, and it has a t direction. forward=normal, s+t=texture alignment directions.

if you check light proximity purely against the plane, then you're going to light that plane even if the light is nowhere near the actual surface quad or whatever it is.
it clips the position based upon the texture coords. the l= lines are a classic plane equation, just with two distances instead of one.

imagine a huge wall 100000qu across (split into 18 lightmap samples or so along its length). fire your rocket at the middle...
that code means that you only mark/relight the surfaces in the middle, as opposed to all the way along the length of the entire wall/plane.

[Baker]

Ok, so it is doing what I think it is doing, but there is a reason for it. I didn't realize the distance check was using a plane, obviously.

[Spike]

aye, just a weird complex way to check 3 planes instead of just 1. kinda.

[mh]

I removed it from RMQ because it was imposing some extra CPU load there and the dlight implementation I had written just benchmarked faster without it. DirectQ recently got it back though. The moral of that story is that there is no 100% correct-and-appropriate-at-all-times "this is faster" approach; you need to take other factors into consideration and review/revisit something that may have benchmarked faster before in the light (pun intended) of new code changes.

If you compare with the code in R_AddDynamicLights you'll see that it's virtually the same - the only thing that looks anyway goofy is the "s * s + t * t + dist * dist" part, but that's just a standard distance calculation with the sqrt optimized out (note that maxdist is pre-calced as radius * radius).