UPDATE: Variable Dyn Light Brightness

Forum rules
Please see Code submission guidelines

GZDoom Status:
Image

Legacy Status:
Image Image

QZDoom Status:
Image

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is ON
[img] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: UPDATE: Variable Dyn Light Brightness

Re: UPDATE: Variable Dyn Light Brightness

by Indecom » Thu Apr 11, 2019 5:11 pm

I added them as CVars because I've been in communication with many of the GZDoom developers who suggested it. My goal is to make this so that the end user doesn't have to do any calibration whatsoever. It will all be author side settings that in the end will be set for the end user to not have to worry about. This is still very much work in progress code. If this is the wrong forum for that then I'll ask to have it moved. But I feel this is more than just a suggestion since I'm actively implementing these features.

My next steps for this are to incorporate the light attenuation settings into mapinfo.

Re: UPDATE: Variable Dyn Light Brightness

by Caligari87 » Thu Apr 11, 2019 12:46 pm

That's not even remotely related to what I'm talking about.

8-)

Re: UPDATE: Variable Dyn Light Brightness

by Apeirogon » Thu Apr 11, 2019 12:22 pm

Caligari87 wrote:I would strongly suggest making the new lighting model a new type of dynamic light or light flag if you want this to have a possibility of getting accepted
I dont think this is a good idea.
I mean, most of gzdoom flaws can be easily fixed with something like this, but for some reason its still didnt fixed in this or another way. For example problem with the sign of pitch, which use left handed coordinate system to determine it sign (up negative, down positive) while all other gzdoom systems, and other programs and applications with space coordinate system, use right handed coordinate system which have reversed calculation of pitch (up positive, down negative).

Re: UPDATE: Variable Dyn Light Brightness

by Caligari87 » Thu Apr 11, 2019 9:22 am

I would strongly suggest making the new lighting model a new type of dynamic light or light flag if you want this to have a possibility of getting accepted. Light adjustment cvars were dropped some time ago because they basically meant that map authors could never guarantee how their maps would look. Dark days indeed when mods needed "light calibration" intromaps and "make sure your light intensity cvar is set to 0.72 because that's what I used to design this". Lighting attenuation like this must be a modder-side option, not a user-side option.

That all said, the new attenuation model looks amazing. I've been wanting a more realistic light falloff for a while.

8-)

Re: UPDATE: Variable Dyn Light Brightness

by Indecom » Thu Apr 11, 2019 4:10 am

Oh this is far from ready for submission. I have a lot of work left to do. I've only committed it to my own git branch as a way of backing up my work. I'll take a look at that link and see how I'll need to do it when I'm actually ready for a pull request.

Re: UDMF Variable for DynLight Brightness

by Nash » Thu Apr 11, 2019 3:54 am

Indecom wrote: If you want to experiment with this, have at it:
GIT Repo
You're not supposed to commit your locally-built files. :lol:

Only commit the modified source files.

See this for an example.

Re: UDMF Variable for DynLight Brightness

by Indecom » Thu Apr 11, 2019 2: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.

Re: Overbright Dynamic Lights

by Indecom » Sun Apr 07, 2019 12: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

Re: Overbright Dynamic Lights

by Indecom » Sat Jul 14, 2018 3: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.

Re: Overbright Dynamic Lights

by Urthur » Sat Jul 14, 2018 1: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.

Re: Overbright Dynamic Lights

by Elias79 » Tue Jul 10, 2018 11:34 pm

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?

Re: Overbright Dynamic Lights

by Nash » Tue Jul 10, 2018 7: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.

Re: Overbright Dynamic Lights

by Elias79 » Tue Jul 10, 2018 12: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

Re: Overbright Dynamic Lights

by Apeirogon » Tue Jul 10, 2018 4:37 am

Double this feature.

Re: Overbright Dynamic Lights

by Indecom » Mon Jul 09, 2018 2: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!

Top