UPDATE: Variable Dyn Light Brightness

[Indecom]

UPDATE:

I've done a lot of work this week. I've deciphered that adding a new UDMF var for light brightness is redundant. Instead light brightness can be defined by setting a light's R,G, or B values to magnitudes higher than 255.
In addition to this I have also implemented an improved, more natural looking light attenuation formula that can be enabled and configured through the following CVars:

Code: Select all • Expand view

gl_lightlinearattenuation
gl_lightattenuationcoefficient

By adjusting these values, and using my custom build of GZDoom, you can create natural looking lighting as such:


Further experiments I'm planning:

• Fully integrated self shadowing parallax occlusion mapping
• Rendering of volumetric materials/lights
• Advanced Specular and PBR materials for sprites
• Advanced rendering of image planes with PBR/Spec + depthmapping.

If you want to experiment with this:
GIT Repo

Previous Update:

---

I've taken it upon myself to begin implementing this feature in a separate branch of GZD, along with a bunch of help from Rachael, and we've managed to make a good deal of progress.

Screenshot_Doom_20190406_193031.png

As you can see, lights can be incredibly bright now, there's essentially no cap on how bright they can be.

The goal of this particular branch is to great a new variable for light definition in the UDMF format, called BRIGHTNESS, this act's essentially as a multiplier for the calculated lighting information in each of the material shaders. This is implemented in all shaders currently: Standard, Specular/Normal, and PBR.

Feel free to check out the fork here: https://github.com/Igameart/gzdoom/tree/overbright

We've hit a bit of a roadblock and that's got to do with finding the dynamic light parser for UDMF. Rachael can't find it herself, and I've only been coding in GZD for two days now so I'm of no help.

At this point in the juncture we need a little bit of guidance to finish our work, but once complete I'll submit it for PR and possible merge into master branch.

Original Post:

---

I'd like to preface this post by saying the the dynamic lights addition to GZDoom has been a godsend, even more so the addition of the DSN/PBR material systems. Along with the implementation of screen based shaders and going full GPL, GZDoom is now a nearly fully viable game development platform. This being said, there is a key feature that my project requires, that I'm, unfortunately, required to hack into my project. That being overbright dynamic lights.

In several places in my levels I need to have lights that are REALLY bright, but adjusting the intensity of the lights really just adjusts their range, they don't increase in brightness. In the image below, there's an incredibly bright light at the end of a corridor ( don't ask why, it just needs to be there lol )



In order to achieve this level of brightness I've had to stack about 5 lights together in roughly the same location, as well as modify the material_specular.fp shader file itself to remove light clamps. Below is the same location with just a single light source at the end of the tunnel with the same level of intensity.



Adding more lights has drastically improved the not only the brightness but the overall dynamic value of the scene.

So my proposal to fix this issue, without adding any extra variables, and would be fairly simple to implement, is to allow the RGB color values of the lights to go above 255. Say I've got a light that's RGB(510,510,510). That's one light now that's twice as bright, and has reduced the rendering overhead of accomplishing the same level of brightness with two lights literally in half. The light at the end of my corridor could be handled with a single lightsource with R,G, and B values of 1275. This will not only allow users to have better control over their scene's lighting (which I don't need to tell you is very important) but will also do so without having to calculate any extra lights or shadows.

I've been digging through shaders that come with GZDoom for a few hours now trying to figure out if the light color is being limited through the shader but at this point I'm beginning to think it's the actual application itself creating this limitation. I would love to fix this problem myself but I'm not sure where to look to solve this problem.

Thanks for taking the time to read through all of this. I hope that someone finds this to be as important as I do. If not for the official GZD branch, then maybe for my own.

[Graf Zahl]

Right now the main technical problem with this is not the lights themselves but the way multiple lights add up. There is a global clamp for the light level that affects a single pixel and removing that will cause major problems with existing light design because many things would become too bright.

[Indecom]

Is this global clamp done through a shader or in application code? I have no problem just tweaking that one bit for my particular project if it will save me processing overhead.

[Graf Zahl]

It's in the shader, where the different lights get added together per pixel.

[Indecom]

I apologize if you're busy, but is it in material_specular.fp? If you're open to a little guidance, I'd love to talk with you about this on discord.

[dpJudas]

The clamps in the shader are at line 70 and 71.

The intensity/color of the light itself is in C++ code. I believe the technical limitation there is that it is stored as a RGB byte triplet (0-255 range).

FDynLightData::AddLightToList is the function that adds lights to the uniform/storage buffer. It gets the light color from ADynamicLight, which loads it somewhere I can't remember.

[Indecom]

Thanks a ton dpJudas! I'm going to be spending some time looking this over. The light RGB values in the wads are all saved fine when I set them to a value higher than 255, so it's just a matter of loading that value into GZD in a way that doesn't limit it to the 0-255 range. If I get anywhere with this, I'll let you know. Ciao!

[Apeirogon]

Double this feature.

[Elias79]

Yes please this is what i am looking for as well.
We used to be able to adjust the global gl_lights_intensity in GZdoom but that feature was removed for some reason, it per Gl Light light intensity could be set a float then bringing back "gl_lights_intensity" could maybe be a simple fix
if the setting could be controlled by the mod or map, but really changing the main code overriding the limits per light would obviously be the best solution, good luck Indecom.

Related: viewtopic.php?f=4&t=56662

[Nash]

Elias79: Actually, no, this isn't what you are looking for. Overbrighting is a completely different and unrelated concept than whatever it is you are asking.

[Elias79]

Elias79: Actually, no, this isn't what you are looking for. Overbrighting is a completely different and unrelated concept than whatever it is you are asking.

Ok thanks for the information, i guess it just seemed similar as the results looks the same even though the tech behind is very different, so is Overbrighting more similar to faked HDR then?

[Urthur]

I've recently been experimenting with the use of over-brightness after examing the Quake software renderer's use of an extended Colormap. https://quakewiki.org/wiki/Quake_palette

And in 8bit sourceports you can squish the extended range into the Doom colormap, and force the engine's hand:


GZDoom/QZDoom obviously have a very different approach, so this requested feature would be quite handy, especially when working with darker texture sets.

[Indecom]

Elias79: Over brighting just means to have a light that is intensely bright to the point where the surfaces it illuminates turn bright white, just like the image I posted at the top.

[Indecom]

So with some help from our resident doomgal, Rachael, we've managed to implement most of what is needed to get light brightness added into the system. The only thing we're missing is the UDMF parsing of the variable, and then creating a custom table in GZDBuilder for the variable.

As you can see, lights can be incredibly bright now. Just need a little bit of help with the deeper stuff but we're most of the way there!

Screenshot_Doom_20190406_193031.png

[Indecom]

It's been a couple of days and I've been cracking away at this task even further. Turns out that setting up a new UDMF var for this is redundant. I've gone through the source code and altered the clamping values for dynamic light sources both while reading lights from the wad/pk3/and so on, but also at the shader level. This essentially reads whatever numbers you place into your light's R,G, and B channels and anything higher than 255 is now stacked rather than immediately clamped, meaning that you can now define insanely bright lights by setting their RGB values magnitudes higher than 255. Not only have I done this but I've also implemented an alternative light attenuation model based around quadratic attenuation plus a more natural attenuation to clamp the light's effective range to that of their radius. By default standard linear attenuation is disabled, but I've added a cvar to toggle that off, to utilize the new, more natural attenuation that I've defined. In addition to that I have also added an attenuation coefficient CVar that you can use to fine tune the light attenuation to get the look that you want out of your maps.



If you want to experiment with this, have at it:
GIT Repo

Further experiments I'm planning:
Fully integrated self shadowing parallax occlusion mapping.
Rendering of volumetric materials/lights
Advanced Specular and PBR materials for sprites
Advanced rendering of image planes with PBR/Spec + depthmapping.