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

[jitspoe]

If you have a wall directly up against a sky ceiling, you'll get some weird shadowy edges on it. I'm pretty sure ArghRad fixed this, and maybe some other compilers. Anybody know how this fix was done?

[qbism]

[qbism]

[jitspoe]

Hmm, changing that would effectively change the falloff of light in general to be less accurate, wouldn't it?

[qbism]

[jitspoe]

I'll try to play around with this soon.

I would have thought the problem would come from the DotProduct check, as the black edge would be where the dot product is at/near zero. I wonder if adding a small fraction to the DotProduct result would help with this (but might cause light to bleed into areas it shouldn't).

[qbism]

You might be looking at a different artifact if it's a completely black area vs a gradient. What I'm seeing with DeWan tools is like a series of point lights around sky openings and large light-emitting surfaces, and the points get further apart with larger -chop sizes. When I tried the code above it 'works' near these conditions but produces splotchy dark patches elsewhere. So next I will try 1/sqrt(dist) for patches and the original 1/dist for spots and point lights.

I haven't been able to find any other Q2 code that deals with altering radiosity. Alien Arena and q2world tools have modified features but both source code bases remove emitting surfaces.

[jitspoe]

This is what I'm referring to:

If I put a sky (or I guess any light emitting surface) flat along the top of a map, I get this (note the dark edges):


It's possible to work around this by building the sky up vertically (building walls of sky) and having a higher sky ceiling:

[qbism]

I haven't run into that type of artifact. I built a little test map and tried 'flat sky' vs 'raised sky' but no edge problems on the test map. On the other hand, I was able to find an example of seemingly random splotchy or linear lightmap artifacts that I've been getting. Screenshots below- the first is vanilla GPL map tools and the second is modified DeWan qrad3, currently: inv =3.0f / (dist * sqrt(dist)) and emit_surface scale = (l->intensity * inv * 0.3) * dot * dot2

Since I compiled both from scratch, I wonder if it is related to the floating point Quake lightmap glitch posted around here a few months ago.

[qbism]

OK, so I added a long skinny brush on the wall to eventually make it a light. But simply adding the brush made the artifact disappear. This doesn't solve the underlying issue but it shows the nature of the problem.

[jitspoe]

I noticed a similar issue (horizontal line on a wall) in my test map. Not sure what causes it. Maybe it's at the max edge when the lighting util is forced to chop the geometry? Maybe adding another brush caused qbsp to break the geometry up differently?

There are certainly some weird little nuances that are difficult to debug.

[mankrip]

[Spike]

aye, a co-planar ray tracing issue will do it.
your traceline will have start==0 and end==0 as it traces horizontally along the plane. if your code considers dist=0 to be an impact then it'll consider the wall to be behind the sky instead of infront, and thus won't light those light samples.
you can change your code to consider both start and end equal to 0 to not be a trace, but doing so potentially allows leaking light due to tracing between brushes.
probably the easiest/safest way to fix it is to nudge the world coord of those surface points towards the center of the wall polygon somehow, avoiding the worst of any coplaner issues, but can still have precision issues, and might give neighbouring surfaces different light levels for the same point (resulting in harsh lines at the boundary between light/shade).

[mankrip]

[qbism]

Aren't light-emitting surfaces simulated by a grid of point lights? The top edge of the wall should see a point light as well as any other point on the wall. Can the sky plane itself obscure a light-emitting point on the plane?