More options for how "Glow" is applied from flats

[RockstarRaccoon]

I was messing with an old map and I was looking at a ceiling and thinking it'd look better with some sort of glow effect, but like, reversed, so it's darkening the edges instead of lightening them. I was thinking it'd be useful to add in some sort of flag that alters way glow is applied.

This was brought up in these threads...
Major Cooke in 2017 - viewtopic.php?f=15&t=58005
GENTEK, Jaxxoon, and abbuw in 2018 - viewtopic.php?f=15&t=60683

To give an example of how this looks and why it's useful, here's the room I was looking at when I thought about it...

---

...as you can see, there's this window in the ceiling where all the light is coming from, and this area which has a hanging feature between it and that window, which should be casting a shadow, but doesn't because the lighting is a manually-applied illusion.

If, however, I could give that ceiling a darkening "glow", either through a subtractive or tinting variant on the current version, that might look a bit like this...

---

...which needs tweaking, because the levels are off, but I think could add a lot in terms of making the room look like it's realistically lit (and give me that "dark corners" feel I'm going for).

Notes on the internal code...
Looking into the code for the glowing flats, I'm realizing this feature is pretty much ALL GL.

The UDMF flags are [plane]glowcolor and [plane]glowheight (implying the suggested feature here would use something like glowsubtract and/or glowtint, or perhaps just glowtype with 0/unset being the current behavior), which set the GlowColor and GlowHeight variables in splane.

This is referenced in p_sectors.cpp with CheckSpriteGlow and GetWallGlow, which is then processed in HWWalls.cpp, setting a flag in he_drawstructs.h's HWWall called HWF_GLOW, but that's just to make sure the hardware renderer knows this needs to be done. I don't think this part would need to be changed for this to work.

The actual glow implentation happens in HWWall::RenderTexturedWall, where SetGlowPlanes is used to build actual 3D planar light-sources for GL to render, kept in the StreamData struct in hw_renderstate.h, which gets tossed into the wall's shader in gl_renderstate.h and gl_renderstate.cpp.... and around that point, it gets lost somewhere in the GL and Vulkan renderers, which is where I stop understanding what's going on. My assumption, however, is that the glowing 3D plane that was built into the shader is used to apply a glow effect, perhaps by drawing a gradient on the lightmap, perhaps with a single GL command. Someone with more knowledge of that system might know more on this.


The actual mapping feature being requested
Now, to have this be usable, there are a few ways it could be implemented from a front-end perspective.

One is subtractive, in which the value that's put in removes light by some inverted value, such that #FFFFFF would do nothing, while #000000 would do a lot. The value should be one-to-one from the mapper's end, to make it easier to actually use, but it could be inverted (and any other math) when the data is loaded to avoid having to calculate during rendering. That would effectively be a subtractive planar-light coming from the plane.

The other is tinting, in which it just changes the color of whatever it's touching without actually changing it. This might not look as good, because I'm not sure how it'd play with other lighting, but it would work for the whole "make dark corners" thing people seem to want to do with it, and would be less mathematically intensive, as Rachel pointed out...

negative lights in general are just a bad idea. if you need shading just use real shading... the math on negative lights is really fucked
I'd rather it be a tint than straight up negative light but that's just me.
but tinting things is fine, darkening by shades (multiplicatively) is perfect.

Note that the code to check the glow would have to be modified for this, because #000000 is currently rejected as an invalid value. I propose removing the color-check and just checking the height, as that's really the only thing that would need to be set above 0 in 100% of use-cases, and I don't see why anyone would set that above 0 if they weren't trying to apply a glow effect.

I think the goal solution here should be to make both of them options, allowing mappers to select negative and/or tint either by using the UDMF flags of [floor/ceiling]glowsubtract and/or [floor/ceiling]glowtint, OR by making an integer variable named [floor/ceiling]glowtype with 0 being the current behavior. Perhaps some sort of intensity variable could also be added, so that greater control could be had for what goes on in that area between the plane and plane+height.



Anyway... I'm going real long here, and I don't know enough GL / Vulkan to actually propose a backend solution, I just noticed it'd be really useful and while people had proposed it, no one was going into detail on how to implement it.

[Rachael]

There isn't less mathematical intensity with tinted shades. It just looks more correct.

I don't know where people get the idea of using subtractive lighting - but trust me, it sucks. If you need it for shadows and whatnot, trust me that shading looks a lot better (but it's not available in GZDoom).

The reason is because when you get low enough in the gradient, subtractive lighting simply turns to black. It has no way to account for multiple shades in a single area without looking like crap.

All proper lighting that is done in games is done multiplicatively. It's multiplied by values greater than 1 to brighten things, and multiplied by values between 0 and 1 to darken or shade them. And this is part of the reason why a float-based rendering canvas (like GZDoom currently uses) looks better when using dynamic lights and glows, than an int-based one or one based on fixed point.

Subtractive lights are just utterly wrong. And the algorithm GZDoom uses to flip the hue of subtractive lights is utter crap, too, especially for intermediary (between primary and secondary) colors. They're mathematically fucked, and they look bad as a result.

[RockstarRaccoon]

You know what? You're right. There are a couple interesting effects that you can pull off with a subtractive light, but the multiplicative shading, with 255ths of 1, IS going to look better.

The only question is... how do we apply that to the existing GL shader code?

[Caligari87]

I don't know where people get the idea of using subtractive lighting - but trust me, it sucks. If you need it for shadows and whatnot, trust me that shading looks a lot better (but it's not available in GZDoom).

I think it's solely a verbiage issue. GZDoom got subtractive dynamic lights over a decade ago or something, and since then they've become synonymous with "darken".

Which, kinda tracks intuituvely because you add to make something higher, and subtract to make it lower.

When people say "subtractive", they just mean they want something that takes light away instead of putting it in, and they use the language that already exists in GZDoom even if it's not technically accurate to what they actually want. Virtually no one actually wants truly subtractive lighting, but it's what we got back in the day for whatever reason and the moniker stuck.

[Rachael]

Regardless of that, the sticking moniker has clearly caused enough confusion, that it is causing that "trend" to continue on with newer code submissions.

So I've created something that hopefully illustrates why subtractive lighting is bad. This just adds on to your Display Options menu. Hit enter to activate the commands - they are toggles. (It will likely work in Raze too)



The code is exactly the same for both shaders - except for one teeny tiny math operator. As NASA has learned quite painfully and expensively back in the day, the simple change of one tiny little math symbol can make all the difference in the world.

I hope this little demo file serves my point well.

[RockstarRaccoon]

Right, because subtractive hits zero at some point and makes everything full-black. I think that could be a neat effect, but yeah, the primary one here should be the multiplicative blending.

[Major Cooke]

YES PLEASE. I very much would love this!