ZDoom

gl_lightlinearattenuation
gl_lightattenuationcoefficient

• 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.

Spoiler:

---

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.

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.

Spoiler:

---

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.

Nash wrote: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.