In Fitz R_Marklights ...

[Baker]

In FitzQuake R_Marklights, what is the objective of the following code?

I notice this is removed in the RMQ Engine and nothing like this is present in DirectQ. There is already a distance check before this code.

Code: Select all

		// clamp center of light to corner and check brightness
		l = DotProduct (impact, surf->texinfo->vecs[0]) + surf->texinfo->vecs[0][3] - surf->texturemins[0];
		s = l+0.5;if (s < 0) s = 0;else if (s > surf->extents[0]) s = surf->extents[0];
		s = l - s;
		l = DotProduct (impact, surf->texinfo->vecs[1]) + surf->texinfo->vecs[1][3] - surf->texturemins[1];
		t = l+0.5;if (t < 0) t = 0;else if (t > surf->extents[1]) t = surf->extents[1];
		t = l - t;

		// compare to minimum light
		if ((s*s+t*t+dist*dist) < maxdist)
		{
			if (surf->dlightframe != r_dlightframecount) // not dynamic until now

[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).