Overbright Dynamic Lights

Remember, just because you request it, that doesn't mean you'll get it.

Moderator: GZDoom Developers

Overbright Dynamic Lights

Postby Indecom » Mon Jul 09, 2018 2:33 am

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.
User avatar
Indecom
Check out QuakenDoom 2, my Q2 TC for Doom 2
 
Joined: 13 Jul 2009

Re: Overbright Dynamic Lights

Postby Graf Zahl » Mon Jul 09, 2018 2:41 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Overbright Dynamic Lights

Postby Indecom » Mon Jul 09, 2018 2:44 am

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.
User avatar
Indecom
Check out QuakenDoom 2, my Q2 TC for Doom 2
 
Joined: 13 Jul 2009

Re: Overbright Dynamic Lights

Postby Graf Zahl » Mon Jul 09, 2018 2:46 am

It's in the shader, where the different lights get added together per pixel.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Overbright Dynamic Lights

Postby Indecom » Mon Jul 09, 2018 2:49 am

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.
User avatar
Indecom
Check out QuakenDoom 2, my Q2 TC for Doom 2
 
Joined: 13 Jul 2009

Re: Overbright Dynamic Lights

Postby dpJudas » Mon Jul 09, 2018 3:16 am

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Overbright Dynamic Lights

Postby Indecom » Mon Jul 09, 2018 3:20 am

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!
User avatar
Indecom
Check out QuakenDoom 2, my Q2 TC for Doom 2
 
Joined: 13 Jul 2009

Re: Overbright Dynamic Lights

Postby Apeirogon » Tue Jul 10, 2018 5:37 am

Double this feature.
Apeirogon
I have a strange sense of humour
 
Joined: 12 Jun 2017

Re: Overbright Dynamic Lights

Postby Elias79 » Tue Jul 10, 2018 1:59 pm

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
Elias79
 
Joined: 30 Jan 2017

Re: Overbright Dynamic Lights

Postby Nash » Tue Jul 10, 2018 8:20 pm

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.
User avatar
Nash
Nash Muhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia

Re: Overbright Dynamic Lights

Postby Elias79 » Wed Jul 11, 2018 12:34 am

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.

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?
Elias79
 
Joined: 30 Jan 2017

Re: Overbright Dynamic Lights

Postby Urthur » Sat Jul 14, 2018 2:57 pm

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.
User avatar
Urthur
 
Joined: 30 May 2018

Re: Overbright Dynamic Lights

Postby Indecom » Sat Jul 14, 2018 4:57 pm

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.
User avatar
Indecom
Check out QuakenDoom 2, my Q2 TC for Doom 2
 
Joined: 13 Jul 2009


Return to Feature Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest