Dark spots/edges near sky when using sky lighting in Quake2

[mankrip]

Aren't light-emitting surfaces simulated by a grid of point lights?

I don't know. But such point lights would be inside the sky plane, and the sky plane can't be reached by any raytraces from the edges that the walls shares with it.

The distance at the edges is always zero anyway, so there's no need to measure it. And this also makes it impossible for anything to obstruct the light, so raytracing from such edges is irrelevant.

A "if this point of the surface is at an edge that's shared with the sky, give it 100% of the sunlight value" solution is enough.

I'm not working on lightmaps these days, otherwise I'd give a shot at doing this in the actual code.

[jitspoe]

I've found that ArghRad has the functionality I need, so I'm putting this aside for now.

My guess is that it checks the trace to see if it starts INSIDE of the sky/light emitting brush, and counts that ray check as passing.

[mankrip]

Such a solution would only work for the Q2 BSP format, so you can test your theory by compiling the map into the Q1 BSP format.

Also, thanks for reminding me — most BSP compilers should have the "solid sky" bug fixed, by compiling the sky brushes as volumes instead of single surfaces. In that case, the sunlight darkness at the edges may be due to the sky brushes having a different pointcontents value (which may prevent the rays from crossing their surface).

[Jay Dolan]

I think I fixed this in Quetoo's BSP compiler by nudging all sample positions towards the center of the face.

[qbism]

I think I fixed this in Quetoo's BSP compiler by nudging all sample positions towards the center of the face.

Yes, I grabbed the source, NudgeSamplePosition Might spend some time to understand this. I notice the rebrand back to quetoo... is the quetoo tools source the same as q2wmap, or is it the 'old' tools? I recall q2wmap removed radiosity to improve compiling speed since it's not needed by the engine.

A funny thing is that I never experienced the dark sky-edge banding issue, so I've been using Jit's modifications to dewan tools. The splotchiness/ light leaking I see might be a symptom of the same issue, but the odds of seeing it are reduced as map complexity and point lights are added.

[Jay Dolan]

Yep, we renamed the project just to avoid having Quake2 (a registered trademark) in our name. Not that id Software was giving us a hard time or anything; it was just the right thing to do -- should have done it years ago.

So yes, quemap (might be named quetoo-map soon) is q2wmap. Same source. And you're correct, it performs direct lighting only, not radiosity. Removing it may or may not have been a mistake on my part. I go back and forth on that decision. Maybe eventually the engine won't even use lightmaps, and it'll be a moot point