Dynamic Lights "Bleed Through Fix"

[Baker]

The demo is thrgib1 from: http://www.quaketerminus.com/hosted/met ... hresh2.zip at 64:38 time in demo. There is a quadded player in the yellow armor/teleporter area. The dynamic light (gl_flashblend 0) is bleeding through to the floor above in the "not bleed-through fixed" shots.

See end for a question ...

Shot 1 With Fix: This screenshot has the "light bleed through fix":


Shot 1 No Fix: Same shot, without the bleed through fix. The floor above the dynamic light is improperly lit by it.


Shot 2 With Fix: However, you can see wall surfaces that none the less shouldn't be affected.


Shot 2 No Fix: Same shot, without the bleed through fix.


Code in question from Qrack is marked "// JT030305 - fix light bleed through" and "//Discoloda", the code goes in R_Marklights in gl_rlights.c

Code: Select all

   for (i=0 ; i<node->numsurfaces ; i++, surf++)
   {
      int sidebit;
      if (surf->flags & SURF_DRAWTILED) // no lights on these
         continue;
#if 1 // Light bleed through fix.  Baker: Interesting, but incomplete ... see demo thrgib1 at 64:38 gl_flashblend 0
     // The light doesn't bleed through.  But affects surfaces it shouldn't, none the less.
      dist = DotProduct (light->transformed, surf->plane->normal) - surf->plane->dist;      // JT030305 - fix light bleed through

      if (dist >= 0)
         sidebit = 0;
      else
         sidebit = SURF_PLANEBACK;

      if ( (surf->flags & SURF_PLANEBACK) != sidebit ) //Discoloda
         continue;
#endif

Question: Any way to stop the lighting from showing up in the wall where it shouldn't?

/ It sucks finding out about these fixes. You just want more and better.

[Baker]

Apparent this is from:

http://www.quake-1.com/docs/quakesrc.org/14.html

this will skip the current surface if the plane is not looking at the light. this is about it... next time i will show you how to skip surfaces that cant be seen by the light (a wall or a piller in the way). and dont forget to add "int sidebit;"to the top of the function:

Of course, I don't see a "next time" and Quakesrc.org is dead.

[mh]

This "fix" actually looks worse than not having a fix, as there are easily reproducable cases where you can have adjacent surfs with one lit but another not, owing to differences in the angle. Just run around a bit with the rocket launcher and you'll see. Also try chthon's fireballs in e1m7 to see how bad it can really look.

A fully robust fix would need an approach similar to shadow-mapping. You can hack something up using the PVS - mark which surfaces are in the PVS for a dlight, then skip ones that aren't in R_MarkLights - but you'll still find cases where that breaks too.

[Baker]

A fully robust fix would need an approach similar to shadow-mapping.

Apparently. I dug up the source to a few Q2 engines and some old DarkPlaces to see if this "extra fix" existed. It doesn't.

And by itself this imperfect fix can make things look very inconsistent. Too bad, because in some cases it does an outstanding job.

[Spike]

<cynical> deathmatch players would hate you for it. as its pretty much the only reason they still use dlights at all. </cynical>

[Baker]

A fully robust fix would need an approach similar to shadow-mapping.

Maybe create a second blocklights similar to stain mapping but only for dlights, draw it early with a stencil operation in place and then draw the rest of the map and brush models, discard where it zfails. I'm probably close in concept to something that might work. While that be a learning experience, it'd probably take a week (and not work) and I have other things to do. But at least I can partially visual some ideas that might come close. Yes, I guess this bothers me ...

EDIT: Actually my crappy stencil idea wouldn't work. It might work for that particular screen shot.

<cynical> deathmatch players would hate you for it. as its pretty much the only reason they still use dlights at all. </cynical>

Hehe. I can relate to some of that, but in different ways. ProQuake cheat-free and then a 5-year non-development gap, pretty much locked the NetQuake mindset down into stasis and a fixed-perspective of what the game is. And as a result, NetQuake doesn't have (m)any of the Quakeworld game-destructing expectations that would drive some into insanity. Implementing anti-wallhack out of FTE did eliminate the dlight method of spotting powered up players, and no one cared about the fringe cases.

At the same time, for about 3 years I did frequent updates to ProQuake and then when I stopped (since there was virtually nothing else left to do of any true significance), the lack of updates made some unhappy with me. Nevermind, I never stopped with engine development but wanted to accumulate the right kind of knowledge to take things up a level or 2, which isn't fast or easy.

[Spike]

you would be amazed how fast light.exe runs when given 8 cpu cores.

[mh]

There's a more general solution behind all of this. Take dlights, occluding world geometry, shadows, even the moving brush model stuff, and you begin to realise that you're actually nipping around the edges of real-time lighting and shadowing.

Current approaches to Quake (such as the "fix" in Baker's OP) focus on "make it look good with this type of geometry, in these type of conditions, but everything else still looks crap, and all you need to do is move another different type of model in and you break the spell". It's building up an architecture where every case is a special case and needs it's own handling that doesn't gel with anything else. That's where the inconsistency comes in and consistent-but-slightly-crap will beat one-thing-looks-really-good-but-everything-else-looks-out-of-place any day of the week.

You can take this even further and look at the stencil shadows in Doom 3. The normal reaction is something like "oooh, ahhh, stencil shadows, awesome", but take a closer look at how they fit into the world and you'll see one bunch of shadows with hard edges, another bunch (from the light projection/falloff) with soft edges and it just jars really bad. In many scenes Doom 3 actually looks better with stencil shadows turned off.

You can put a lot of effort into fixing up one particular occurrance of something in one map, then move to another map where the same thing happens but with different geometry and different models in different places and it's "holy fuck, this looks even worse than before". Sometimes you just have to accept that a problem isn't worth fixing without major architectural overhaul.

[Baker]

MH, your right but I just realized something after busting out "tool_texturepointer".

Those surfaces denied lighting by the light bleed-through fix can serve as blockers. The surfaces that shouldn't be affected have one thing in common ---- ALL of them have a backface (and actually a front face) between themselves and the light source. A plane test (R_Lightpoint) or traceline between the light source origin and the surfaces that shouldn' be lit would return false.

I'm not saying this idea is good, couldn't possibly look terrible and I'm not saying it isn't potentially a waste of time. I can see plenty of ways this idea would miserably fail, though especially with lighting as a radius.

I need to drop this idea and continue with the realistic set of my to-do list ...

[mh]

...I can see plenty of ways this idea would miserably fail...

Especially if one of those surfaces is actually in a func_wall.....

Just not worth bothering with Quake's architecture as-is.