GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby dpJudas » Thu Jan 19, 2017 3:22 pm

Correct. The code in GZDoom is here: https://github.com/coelckers/gzdoom/blob/master/wadsrc/static/shaders/glsl/main.fp#L136. The pointLightAttenuation function listed just below it includes the full equation including the distance part (if attenuate is zero, then it uses the old light math).

If they are exactly parallel then the light level becomes zero, yes. And if the surface points away from the light it stays dark as well (because the dot product becomes negative and the max statement clamps that to zero).

Edit: just to clarify the variables:

lightpos.xyz is the position of the light in world space
lightpos.w is the light radius
pixelpos.xyz is the location of the pixel in world space.
attenuate toggles between normal and attenuated lights
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby Enjay » Thu Jan 19, 2017 4:28 pm

I have a much clearer picture of what this is all about now. Thank you. :D
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby ZZYZX » Thu Jan 19, 2017 4:37 pm

Are there GLDEFS updates?
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby Enjay » Thu Jan 19, 2017 5:02 pm

I can't see anything obvious option-wise; is there a way to force attenuation for all lights (console command, MAPINFO, whatever) to make an "easy to see the difference" option for any currently loaded light definition?
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby Gez » Thu Jan 19, 2017 5:09 pm

ZZYZX wrote:Are there GLDEFS updates?

Yes, attenuate as a keyword. See this for instance.
Gez
 
 
 
Joined: 06 Jul 2007

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby Nevander » Thu Jan 19, 2017 11:58 pm

Graf Zahl wrote:That is controlled by the light level. Which is precisely the problem with a Doom64 lighting implementation. It will require either some change to the lighting model or some explicit setting of light level and color values.

I probably shouldn't use the word "simply" but is it simply not possible to divide the sector light color choices into 5 different fields and allow them to be applied differently from one another per sector? I know it's not as simple as just doing it, but the engine knows what a flat is, it knows what a thing is, and it knows what a sidedef is. Is there no way to directly tell the engine to "render blue light color on floor only, and render green light color on things"?

For fading colors down a wall, I'd imagine you'd need to have a calculation to determine the height of the sector and split the height and give the top half one color and the bottom half the other as well as dynamically change the fade height with sector height changes, which is what Doom 64 does when a sector moves. You can see the gradient actually get larger.

But as I've said on multiple occasions, I know practically zilch about engines. :oops:
Nevander
Banned User
 
Joined: 06 Jan 2014

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby Rachael » Fri Jan 20, 2017 12:25 am

All you are asking for is very theoretically possible, yes. And from a pure rendering perspective it actually seems simple.

But when you get into the nitty gritty details - simple is exactly what it's not. First the structs have to be updated to support it, then the renderer has to be able to read said structs, then the renderer has to actually be able to apply the lighting non-disruptively and without breaking any other forms of light that might be in that location.

The problem is made a whole lot worse by the fact that in my experience, ZDoom does a metric fuckton of conditional checking everywhere, especially in the rendering code. Unfortunately, that's what happens when you simply pile on feature after feature after feature after feature after feature after feature .........

Let's just put it this way: There's a reason why the software refactoring hasn't been finished yet, despite going off and on for nearly a month now. And why it took me several weeks for me to complete my rgb666 submission. The amount of logic that the engine has to handle is almost overwhelming, and if it keeps going at this rate it will soon become unmanageable.

In the end you just have to realize that "cool to have" sometimes simply is not "practical".
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby Nash » Fri Jan 20, 2017 2:25 am

Enjay wrote:I can't see anything obvious option-wise; is there a way to force attenuation for all lights (console command, MAPINFO, whatever) to make an "easy to see the difference" option for any currently loaded light definition?


Sorry for the late response. Nothing like this exists in the engine, although now that the latest devbuild of GZDB supports attenuated lights, what you can do is make a map with two identical rooms, with one room using old lights and the other using attenuated lights.

Another way is to open up lights.pk3, and add the attenuate keyword to all of the built-in light classes (eg for the Doom torches etc), save that as a different WAD and load it up in-game.
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 GTX or Quadro with Vulkan support

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby Graf Zahl » Fri Jan 20, 2017 7:15 am

Nash wrote:Another way is to open up lights.pk3, and add the attenuate keyword to all of the built-in light classes (eg for the Doom torches etc), save that as a different WAD and load it up in-game.


Doom and Heretic are already done this way, if someone volunteers for Hexen and Strife, in general, radius should be multiplied with 1.5 and 'attenuate' added to every light definition, except maybe for some small stuff where the attenuation does not work that well.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby Gez » Fri Jan 20, 2017 8:03 am

Enjay wrote:I can't see anything obvious option-wise; is there a way to force attenuation for all lights (console command, MAPINFO, whatever) to make an "easy to see the difference" option for any currently loaded light definition?

Load this zip in Doom II. On MAP01 you'll see red and green torches alternating thanks to the magic of portals. Every parameters of the lights are identical (white light, not colored red and green), but the green torches are attenuated. You will easily see how the light falloff is more natural with the attenuated green torches, but the illumination radius looks smaller as a result (hence why Graf mentioned needing to increase it by about 50%).
Gez
 
 
 
Joined: 06 Jul 2007

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby Enjay » Fri Jan 20, 2017 10:46 am

Perfect demonstration, thank you. I can easily see the differences and they are exactly as described.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby Nevander » Thu Jan 26, 2017 6:28 am

So do you guys think that if the Doom 64 lighting ever does become a norm that we will be able to do a properties swap between sectors? This is how Doom 64 is able to change colors. They don't do stuff like SetUpperHalfColor or SetFloorColor... they do Sector_CopyLightsAndInterpolate and Sector_CopyLights. This basically changes ALL the color settings at once, and the interpolate variant fades to the other colors instead of a hard change. It gets the color information to copy from a dummy sector outside the map that has the properties they want to copy to the in-map sector. Is this feasible as well? Because it will be needed if you want to truly emulate the lighting style.
Nevander
Banned User
 
Joined: 06 Jan 2014

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby Rachael » Thu Jan 26, 2017 10:38 am

One step at a time, there, sparky! :shock:

If the light mode is ever introduced, I am sure that a mechanism will eventually be introduced to copy it from one sector to another, but it might now happen on the same day. :P maybe the same week...
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby ZZYZX » Thu Jan 26, 2017 1:17 pm

You'll be able to write it in ZScript
(probably)
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)

Postby Graf Zahl » Thu Jan 26, 2017 1:37 pm

Eruanna wrote:One step at a time, there, sparky! :shock:

If the light mode is ever introduced, I am sure that a mechanism will eventually be introduced to copy it from one sector to another, but it might now happen on the same day. :P maybe the same week...



I've been thinking a bit about the system and how to integrate it with the depth fading in Doom. How about this:

5 UDMF properties 'color_xyz = value' which just specify the color.
Plus another property 'color_absolute' which makes the light value not affect the color but only the depth fading. That way the color can be fully controlled but still be affected by depth fading and the depth fading be configurable.

About transferring these values from one sector to another, that should be doable with ZScript indeed, but first the thinker mechanism needs to be available so that scripts can create new thinkers of any class.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

PreviousNext

Return to Abandoned/Dead Projects

Who is online

Users browsing this forum: No registered users and 2 guests