Dynamic point lights

Advanced OpenGL source port fork from ZDoom, picking up where ZDoomGL left off.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Wiki] [Repo] [Bugs&Suggestions]

Moderator: Graf Zahl

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Dynamic point lights

Post by dpJudas » Sun Aug 21, 2016 7:15

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:
hqdynlights.pk3
Higher quality dynamic point lights
(3.45 KiB) Downloaded 108 times
Coming soon to a gzdoom near you! (aka. a pull request with support for the old shader as well)

User avatar
Nash
Developer
Developer
Posts: 1226
Joined: Sun Sep 25, 2005 1:49
Location: Kuala Lumpur, Malaysia
Contact:

Re: Dynamic point lights

Post by Nash » Sun Aug 21, 2016 8:06

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

Image

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Dynamic point lights

Post by Graf Zahl » Sun Aug 21, 2016 8:07

What's with this?

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);

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.

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Dynamic point lights

Post by dpJudas » Sun Aug 21, 2016 16:26

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...
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: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"...
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.
Graf Zahl wrote:If there's problems with the position they should be taken care of outside the shader.
Completely agree. This pk3 was mostly meant as a demonstration of the visual difference.
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?
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:BTW, on my system this creates a minor slowdown, so on weaker ones it may have more of an impact.
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.

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Dynamic point lights

Post by Graf Zahl » Sun Aug 21, 2016 17:36

Am I correct to assume that with vertex buffer normals there'd be less overhead?

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Dynamic point lights

Post by dpJudas » Sun Aug 21, 2016 20:24

Yes, the derived normal stuff wouldn't be needed there. Think that is probably what mattered the most speedwise.

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Dynamic point lights

Post by Graf Zahl » Mon Aug 22, 2016 8:55

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.

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Dynamic point lights

Post by dpJudas » Mon Aug 22, 2016 11:38

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

User avatar
Nash
Developer
Developer
Posts: 1226
Joined: Sun Sep 25, 2005 1:49
Location: Kuala Lumpur, Malaysia
Contact:

Re: Dynamic point lights

Post by Nash » Tue Aug 23, 2016 10:18

Sorry to sound too excited but... is this groundwork that will eventually enable models to be lit correctly from dynamic lights? =D

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Dynamic point lights

Post by dpJudas » Tue Aug 23, 2016 18:13

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. :D

User avatar
Nash
Developer
Developer
Posts: 1226
Joined: Sun Sep 25, 2005 1:49
Location: Kuala Lumpur, Malaysia
Contact:

Re: Dynamic point lights

Post by Nash » Wed Aug 24, 2016 5:39

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

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Dynamic point lights

Post by dpJudas » Thu Aug 25, 2016 5:51

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:
  • 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.
The specular highlight strengths are hardcoded for now, but maybe in a future expansion of the material system those could be picked up from pk3 files.

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Dynamic point lights

Post by Graf Zahl » Thu Aug 25, 2016 7:28

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.

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Dynamic point lights

Post by dpJudas » Thu Aug 25, 2016 7:40

Alright. Will resurrect this when we get to that. :)

NashMuhandes

Re: Dynamic point lights

Post by NashMuhandes » Thu Aug 25, 2016 10:58

Agreed... I'm willing to wait a little longer for GZDoom to have real normal support. Thanks for all this, Graf and dpJudas!

Locked

Return to “GZDoom”