UPDATE: Variable Dyn Light Brightness

Like feature suggestions, but you've actually written code to make it happen. More likely to make it into the game than some random request in feature suggestions.

Moderator: GZDoom Developers

Forum rules
Please see Code submission guidelines

GZDoom Status:
Image Image

Link to Legacy Repo

QZDoom Status:
Image Image

UPDATE: Variable Dyn Light Brightness

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

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 allExpand 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:
Spoiler:


Original Post:
Spoiler:
Last edited by Indecom on Thu Apr 11, 2019 3:54 am, edited 8 times in total.
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
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
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
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: nVidia with Vulkan support

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

Re: Overbright Dynamic Lights

Postby Indecom » Sun Apr 07, 2019 1:26 am

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

Re: UDMF Variable for DynLight Brightness

Postby Indecom » Thu Apr 11, 2019 3:45 am

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

Next

Return to Code Submissions

Who is online

Users browsing this forum: No registered users and 0 guests