Dynamic point lights
Moderator: Graf Zahl
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Dynamic point lights
While toying with that silly global specular light shader, I noticed that the dynamic point lights in gzdoom only do plain distance attenuation. Well no more! I present to you the physically correct diffuse point light:
Coming soon to a gzdoom near you! (aka. a pull request with support for the old shader as well)
Coming soon to a gzdoom near you! (aka. a pull request with support for the old shader as well)
- Nash
- Developer
- Posts: 1226
- Joined: Sun Sep 25, 2005 1:49
- Location: Kuala Lumpur, Malaysia
- Contact:
Re: Dynamic point lights
Can you explain the differences? I ran around with this and checking out the existing dynamic lights in maps but I can't quite pick out the difference... :S
Also, as an off-topic, would these kinds of lights be do-able in GZDoom with your shader wizardry? I imagine a new Thing type would have to be introduced to add additional parameters to control the shape of the "cone"...
Also, as an off-topic, would these kinds of lights be do-able in GZDoom with your shader wizardry? I imagine a new Thing type would have to be introduced to add additional parameters to control the shape of the "cone"...
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: Dynamic point lights
What's with this?
If there's problems with the position they should be taken care of outside the shader. Additionally, wouldn't it make sense to put the normals in the vertex buffer so that models can use the actual ones they were created with?
BTW, on my system this creates a minor slowdown, so on weaker ones it may have more of an impact.
Code: Select all
// Move light a bit because flasks/vials have their light source location at/below the floor
// Also move light just a tiny bit in general to avoid perfect alignment with any wall (doom loves integers)
lightpos.xyz += vec3(0.01, 5.01, 0.01);
BTW, on my system this creates a minor slowdown, so on weaker ones it may have more of an impact.
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Dynamic point lights
The difference is that the angle of the face (wall/floor) is being taken into account when calculating the strength of the light for each pixel. You easiest see it by watching the fireballs of imps through dark halls - the "shape" of the light is slightly different.Nash wrote:Can you explain the differences? I ran around with this and checking out the existing dynamic lights in maps but I can't quite pick out the difference...
Spot lights is a much bigger feature enhancement. In this case I just wanted the point lights to use normal point light math because I think it looks slightly better.Nash wrote:Also, as an off-topic, would these kinds of lights be do-able in GZDoom with your shader wizardry? I imagine a new Thing type would have to be introduced to add additional parameters to control the shape of the "cone"...
Completely agree. This pk3 was mostly meant as a demonstration of the visual difference.Graf Zahl wrote:If there's problems with the position they should be taken care of outside the shader.
Ideally, yes. I haven't looked that part of gzdoom's code yet to say how tricky it would be to add. I figured that face normals would at least be better than no normals.Graf Zahl wrote:Additionally, wouldn't it make sense to put the normals in the vertex buffer so that models can use the actual ones they were created with?
I'm not sure if the derived functions I use to calculate the normals are available on the lowest end we support. Probably needs an on/off option in the menus for everyone to be happy.Graf Zahl wrote:BTW, on my system this creates a minor slowdown, so on weaker ones it may have more of an impact.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: Dynamic point lights
Am I correct to assume that with vertex buffer normals there'd be less overhead?
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Dynamic point lights
Yes, the derived normal stuff wouldn't be needed there. Think that is probably what mattered the most speedwise.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: Dynamic point lights
Concerning normals I am thinking about saving buffer space. For walls and flats I believe it's ok to use glVertexAttrib3f, just like it currently does for vertex colors, to save buffer space and constant overhead when writing the buffer data, but for models they need to go into the buffer. Is it precise enough to use bytes here? That'd mean they'd only add 4 bytes to a vertex, not 12.
I have seen mods with many models which end up creating huge buffers.
I have seen mods with many models which end up creating huge buffers.
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Dynamic point lights
Good question. I think that a byte per component will be good enough. Opengl.org's wiki mentions storing a single normal as 32 bit integer using the GL_INT_2_10_10_10_REV format, which it mentions is a popular format for this purpose (not sure which version of OpenGL that format was introduced).
- Nash
- Developer
- Posts: 1226
- Joined: Sun Sep 25, 2005 1:49
- Location: Kuala Lumpur, Malaysia
- Contact:
Re: Dynamic point lights
Sorry to sound too excited but... is this groundwork that will eventually enable models to be lit correctly from dynamic lights? =D
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Dynamic point lights
At the moment it is just talking.
I think it could be really cool is gzdoom added a way to describe complete materials. Textures (diffuse, specular, normal map) and other properties like specular level, glossiness and possibly shader. Exactly how it should be done is the big question. One method would be to extend GLDEFS, or maybe look for lumps and use them if found. I.e. if DOOR01 also has a DOOR01_specular then it would use that. Once we have the normals we just need a way to bind the textures.
There is also the question of whether gzdoom should support GLDEFS post processing shaders. And if script should be allowed to use any of all this. I could see some use in advanced mods doing their own custom powerup fullscreen effects, or that retro shader that makes you want to turn in your LCD for repairs.
I think it could be really cool is gzdoom added a way to describe complete materials. Textures (diffuse, specular, normal map) and other properties like specular level, glossiness and possibly shader. Exactly how it should be done is the big question. One method would be to extend GLDEFS, or maybe look for lumps and use them if found. I.e. if DOOR01 also has a DOOR01_specular then it would use that. Once we have the normals we just need a way to bind the textures.
There is also the question of whether gzdoom should support GLDEFS post processing shaders. And if script should be allowed to use any of all this. I could see some use in advanced mods doing their own custom powerup fullscreen effects, or that retro shader that makes you want to turn in your LCD for repairs.
- Nash
- Developer
- Posts: 1226
- Joined: Sun Sep 25, 2005 1:49
- Location: Kuala Lumpur, Malaysia
- Contact:
Re: Dynamic point lights
Fair enough. It is exciting to see all this even in such preliminary stages and I'm excited to see what'll happen next. :)
Agreed on your idea on the concept of materials in the engine. Although whichever method is fine by me. I trust the GZDoom gods will decide what is suitable. =D
Agreed on your idea on the concept of materials in the engine. Although whichever method is fine by me. I trust the GZDoom gods will decide what is suitable. =D
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Dynamic point lights
Pull request: https://github.com/coelckers/gzdoom/pull/87
Okay, finally finished the branch adding the more advanced light math. A couple of comments about it:
Okay, finally finished the branch adding the more advanced light math. A couple of comments about it:
- Adds a Light Quality setting to the dynamic lights menu. The low mode is the original distance attenuation, medium is with diffuse point light math, and high is with additional specular highlights.
- I added a pixelnormal global variable in the fragment shader. It can be changed into an 'in' variable if/when the C++ part can feed it with real mesh normals in the future.
- Changed pixelpos and the lights in the storage buffer from world to eye space. This makes the specular math easier/faster, as the camera location and orientation gets baked into the positions.
- I'm still slightly offsetting the light positions, although now doing it in the C++ part. I'm not sure if this is the best way to deal with it, but basically the lights of vials and armor helmets have their center beneath the floor. Without the offsetting their glow effect is not visible.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: Dynamic point lights
I'm not going to add this now. Let's not jump to step B before step A hasn't been done. I'm all for the advanced lighting but I prefer to do it correctly from the start, i.e. make sure that everything generates proper normals instead of guesstimating them from the render data.
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Dynamic point lights
Alright. Will resurrect this when we get to that.
Re: Dynamic point lights
Agreed... I'm willing to wait a little longer for GZDoom to have real normal support. Thanks for all this, Graf and dpJudas!