Simple question about dynamic lighting

[Graf Zahl]

Back to the original problem of this thread, I was looking for a solution to this too. To work around dynamic light 'bleeding' to the next room's floor and ceiling is to place a small sector in the neighbouring room that encloses the affected area and have an open script to tag that sector with Sector_SetPlaneReflection (<tag>, 1, 1). Apparently, sectors flagged with reflective surfaces will not pick up any dynamic lighting, even at its lowest value. It corrects those undesired light bleeds while keeping me free to light the next room any way I please.

If that is the case it's a bug. Better not make your map depend on it, once it gets investigated it will get fixed.

[Rev_Heretic]

..... It corrects those undesired light bleeds while keeping me free to light the next room any way I please.

For me, the only way to bypass those light bleeds is by moving the sectors apart by more then the lights radii.

The reflective floor ignores the dynamic light, but it still exists and the radius that reaches past the floor is visible. Where I mean you to put the sector flagged as reflective is around the floor the light actually reaches, like a towel on a spillage. It is a flawed work around as it only solves floor and ceiling leaks of light. I include a map demonstrating how the reflect sectors can act as a barrier and in my example it produces sharp shadows like it is passed through a stencil.

Usually I would opt for masking leaking light into a neighbour room by placing that room's light sources where the leak is, thus it just looks lit independently. If that next room is meant to be dark I'd try using subtractive lighting to cover it up.

Graf makes a point that we shouldn't rely on this. I've seen the issue with reflective floors and dynamic lights for years and I took it as a limitation. If Graf thinks this could be a fixable bug, perhaps its wiser not to use such a workaround.

[Graf Zahl]

OK, I just had a look. This was clearly an oversight in the flat renderer. This comes from the old, texture based lighting code which cannot render lights on translucent surfaces. The newer, shader based renderer can do that, though, but the flat renderer had never been adjusted for it. But seeing this map gave me an idea:

How about adding a bitmask property to linedefs, sector planes and light things (both map placed and attached to other actors, so that lights get discarded if both bitmasks ANDed together are not 0? That'd give mappers some control over certain parts of the map that get excluded by certain dynamic lights

[Rev_Heretic]

Would that give the same result as my example? If I understand you right, we'd still be using deliberate map geometry to occlude dynamic lighting, but using a flag and not this reflective floor exploit?

[Nash]

WOW so finally dynamic lights can appear on reflective floors and wall mirrors? I was beginning to lose hope. :D And I support the idea of the properties so that modders can control and optimize their map for performance.

[Caligari87]

How about adding a bitmask property to linedefs, sector planes and light things (both map placed and attached to other actors, so that lights get discarded if both bitmasks ANDed together are not 0? That'd give mappers some control over certain parts of the map that get excluded by certain dynamic lights

THIS WOULD MAKE ME SO HAPPY. Like seriously, in lieu of real dynamic map geometry shadowing, this would be the greatest.

[Rev_Heretic]

If Graf fixes the renderer to allow reflective surfaces to receive dynamic lights, that will greatly ease compromises I have to make on aesthetics I'm interested in how he will implement this bitmask property and what this will allow us to do. I'm glad I inspired his idea

[Graf Zahl]

Would that give the same result as my example? If I understand you right, we'd still be using deliberate map geometry to occlude dynamic lighting, but using a flag and not this reflective floor exploit?

In general, yes, but your exploit has one major drawback: It will also block all legitimate lighting, e.g. from projectiles the player fires. That's why I was proposing a bitmask to only exclude specific lights.

[Graf Zahl]

If Graf fixes the renderer to allow reflective surfaces to receive dynamic lights,

I had a look at it yesterday evening. It's doable but only for the WIP 2.0 branch. The current version needs to remain compatible with texture based lights for older hardware and won't be able to do it.

Even if I added it to the 1.x version it'd be GL 3.x only - and then only shader based lights which do not yet work correctly on all hardware (I have an idea why this screws up on AMD, but the fix for it will be in the 2.x version only.)

[Rev_Heretic]

I'm willing to continue to live with not being able to dynamically light reflective flats if it means breaking compatibility or stunting progress.
The bitmask idea, that has my support. I'd imagine the GUI to feature a check list of those dynamic light entities that mappers place in their maps for the line/sector to ignore.