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.
Locked
dpJudas
 
 
Posts: 3037
Joined: Sat May 28, 2016 1:01 pm

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

Post by dpJudas »

Correct. The code in GZDoom is here: https://github.com/coelckers/gzdoom/blo ... in.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
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

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

Post by Enjay »

I have a much clearer picture of what this is all about now. Thank you. :D
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

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

Post by ZZYZX »

Are there GLDEFS updates?
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

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

Post by Enjay »

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?
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

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

Post by Gez »

ZZYZX wrote:Are there GLDEFS updates?
Yes, attenuate as a keyword. See this for instance.
Nevander
Posts: 2254
Joined: Mon Jan 06, 2014 11:32 pm

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

Post by Nevander »

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:
User avatar
Rachael
Posts: 13531
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

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

Post by Rachael »

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
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

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

Post by Nash »

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
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

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

Post by Graf Zahl »

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.
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

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

Post by Gez »

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%).
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

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

Post by Enjay »

Perfect demonstration, thank you. I can easily see the differences and they are exactly as described.
Nevander
Posts: 2254
Joined: Mon Jan 06, 2014 11:32 pm

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

Post by Nevander »

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.
User avatar
Rachael
Posts: 13531
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

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

Post by Rachael »

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
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

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

Post by ZZYZX »

You'll be able to write it in ZScript
(probably)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

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

Post by Graf Zahl »

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

Return to “Abandoned/Dead Projects”