Relighting v4.0141b - hotfix

Projects that alter game functions but do not include new maps belong here.
Forum rules
The Projects forums are only for projects. If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.
User avatar
Hey Doomer_
Posts: 64
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.013b

Post by Hey Doomer_ »

Dan_The_Noob wrote: Sun Nov 20, 2022 5:25 am
Hey Doomer_ wrote: Sun Nov 20, 2022 1:37 am Hotfix posted. Are you running the same mod, I wonder?

I'm going to have to rework the GLDEFS reading routine again. I didn't get any errors on my end with a dozen different mods, but there's still a lot of variation.
it's working now i think, though the load time is back to 10+ seconds. did you work off an older version or something?
I don't see any loading issues on my end. What are you running with it?
User avatar
Hey Doomer_
Posts: 64
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.0132b - added GLDEFS hotfix

Post by Hey Doomer_ »

:lol: OK figured it out duuuuuuuuuuuuuh. GLDEFS issue should be fixed now!

Really Boring Explanation
GLDEFS are generally well-formatted, but there is a lot of variation in where light definitions are placed with regard to objects and frames, and that is the issue. The end goal is something like this:
Spoiler:
... in which the object is followed by the lights attached to frames in the correct order. I assumed initially that light definitions had to appear before objects. That may still be true, but it isn't how all GLDEFS are written.


One other note: I usually test with vanilla Doom, vanilla Heretic, Brutal Doom, Beautiful Doom (those two seem increasingly alike it seems), an Obsidian wad or two, and whatever else people have mentioned. Obviously I can't test with every combination of mods. If you have a crash, it's helpful to also list where and what was running at the time so I can recreate the error and fix it. Many thanks.
User avatar
Dan_The_Noob
Posts: 624
Joined: Tue May 07, 2019 12:24 pm
Graphics Processor: nVidia with Vulkan support

Re: Relighting v4.013b

Post by Dan_The_Noob »

Hey Doomer_ wrote: Sun Nov 20, 2022 8:22 am
Dan_The_Noob wrote: Sun Nov 20, 2022 5:25 am
Hey Doomer_ wrote: Sun Nov 20, 2022 1:37 am Hotfix posted. Are you running the same mod, I wonder?

I'm going to have to rework the GLDEFS reading routine again. I didn't get any errors on my end with a dozen different mods, but there's still a lot of variation.
it's working now i think, though the load time is back to 10+ seconds. did you work off an older version or something?
I don't see any loading issues on my end. What are you running with it?
same stuff as i was with 0.12b
also 0.12b doesn't have the load issue, still near-instant.
so something changed between 12 and 13 gave it a nudge

--EDIT--
OK, I narrowed it down to my intensify mod causing the long load time... and that thing is a spaghetti code mess... so, if you can narrow down what changed between versions i might be able to fix it on my end.
though even vanilla, i get slightly longer loads than 0.012, but like half second maybe.
User avatar
Hey Doomer_
Posts: 64
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.013b

Post by Hey Doomer_ »

Dan_The_Noob wrote: Sun Nov 20, 2022 5:25 am --EDIT--
OK, I narrowed it down to my intensify mod causing the long load time... and that thing is a spaghetti code mess... so, if you can narrow down what changed between versions i might be able to fix it on my end.
though even vanilla, i get slightly longer loads than 0.012, but like half second maybe.
That is a puzzle. If anything I should have improved load times. I did correct several simple math errors that ensure the sector areas are analyzed correctly. Not sure if that has an impact.

I don't think the changes in GLDEFS parsing has an impact.
User avatar
Dan_The_Noob
Posts: 624
Joined: Tue May 07, 2019 12:24 pm
Graphics Processor: nVidia with Vulkan support

Re: Relighting v4.013b

Post by Dan_The_Noob »

Hey Doomer_ wrote: Sun Nov 20, 2022 7:26 pm That is a puzzle. If anything I should have improved load times. I did correct several simple math errors that ensure the sector areas are analyzed correctly. Not sure if that has an impact.

I don't think the changes in GLDEFS parsing has an impact.
yeah not sure what it could be in this case.
I am just using doom2 MAP01 to test so it's not the map.

there are a TON of GLDEFS in intensify because it's still mostly mish-mash. though i dont think having new ways to read them should make such a big difference to loads either.
User avatar
Hey Doomer_
Posts: 64
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.013b

Post by Hey Doomer_ »

Dan_The_Noob wrote: Sun Nov 20, 2022 8:29 pm
Hey Doomer_ wrote: Sun Nov 20, 2022 7:26 pm That is a puzzle. If anything I should have improved load times. I did correct several simple math errors that ensure the sector areas are analyzed correctly. Not sure if that has an impact.

I don't think the changes in GLDEFS parsing has an impact.
yeah not sure what it could be in this case.
I am just using doom2 MAP01 to test so it's not the map.

there are a TON of GLDEFS in intensify because it's still mostly mish-mash. though i dont think having new ways to read them should make such a big difference to loads either.
Sorry for the late reply - working on a big update with many fixes and "baked in" sidedef lighting based on more light sources (surprisingly simple to code with no impact on performance that I can see). Looks great for the most part, but :shock: I've found many overlooked issues in initially rushing through some details. Some of the old code I borrowed from the old version is also buggy or incorrect. Ah well.

I don't think the number of GLDEFS matter so long as it isn't thousands of them. It IS looking at every sidedef and checking how light hits it, but I don't recall a delay in MAP02 loading. Are you running anything else with it?
User avatar
Dan_The_Noob
Posts: 624
Joined: Tue May 07, 2019 12:24 pm
Graphics Processor: nVidia with Vulkan support

Re: Relighting v4.013b

Post by Dan_The_Noob »

Hey Doomer_ wrote: Tue Nov 22, 2022 1:25 pm
I don't think the number of GLDEFS matter so long as it isn't thousands of them. It IS looking at every sidedef and checking how light hits it, but I don't recall a delay in MAP02 loading. Are you running anything else with it?
well the only thing causing it to take noticeably longer to load is Intensify which is weapons, enemies and items.
so i'm not sure what would be causing it. without intensify it's the usual ~1second, with intensify it's about as long as before 0.012
User avatar
Hey Doomer_
Posts: 64
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

WIWO for next release

Post by Hey Doomer_ »

WIWO
Spoiler:
A few examples of baked lighting with added dynamic lights:
Spoiler:
Many corrections to existing or older code as noted above. This is based on static map lights defined in GLDEFS that are in a sector on load (using sector thing iterator) or light sources added by the mod (using actor iterator). Light size is based on the perceived intensity of light color or sector light respectively and crudely applied using inverse square law. While I've added smaller lights to make this pretty, this doesn't rely on shadow mapping. For performance reasons this is done once at load and doesn't respond to barrels, missiles, and other such lights.

For example, E1M1 shot where column in the center is brighter on the right side because of light from the column actor to the right. Also be seen in E1M3 screenshot where the far wall that can see the light in the pit is somewhat brighter. Still testing this but it seems the most promising way to universally light textures. This should apply to anything, and the polylabel algorithm ensures correct placement of a light in any sector.

Authors tend to make sectors with "light" textures brighter, so any added texture dynamic lights are redundant.

As noted a few times there aren't many light sources in the game, but I've added plane lights if ceiling flats have a bright perceived light level. This is also done on the fly by reading flat lumps against the current palette (doing the same thing for textures isn't impossible, but flats are generally less detailed and easier to interpret). None of this is perfect but doesn't rely on specific configuration either.

Release whenever testing is completed. 8-) I just keep finding errors...
User avatar
mamaluigisbagel
Posts: 413
Joined: Wed Jul 09, 2014 7:25 pm
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: Relighting v4.0132b - added GLDEFS hotfix

Post by mamaluigisbagel »

Was testing Wadsmoosh a bit, and I got this crash when starting Doom 2: The Master Levels. Every other episode/chapter works fine, though.
You do not have the required permissions to view the files attached to this post.
meppycola
Posts: 1
Joined: Sat Nov 26, 2022 5:46 am

Re: Relighting v4.0132b - added GLDEFS hotfix

Post by meppycola »

so i've played this with doomreal/doom tournament and i keep getting this right at the start screen
You do not have the required permissions to view the files attached to this post.
User avatar
Hey Doomer_
Posts: 64
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.014b - w/ baked sidedef lights

Post by Hey Doomer_ »

Posted 4.014b that includes the following:

Corrections for lighting and geometry variations in maps. Sidedef lighting is baked and corrected using inverse square law; on load sector things that are light sources are included and tagged with additional lighting. I've tested this with many maps. Added a few line activation checks to correct sector lighting e.g. the donut in E1M2. Along the way also corrected the door light switches.

More bug fixes than I can remember, including the polygon area calculation (for reference the area under the lights at the start of E1M3 is about 58 square units). Some area calculations don't work, either because the polygon is not closed or vertices are not in order (clockwise or counterclockwise doesn't matter, but it must be one or the other). These exceptions are accounted for. Added dynamic light limits for improved performance.

An option to add red-green (default) or full rgb bleeding has been added to the shader, a subtle difference.

Tweaked defaults to produce more reflections for those of you who like reflections. The reflection strength itself is also tweaked depending on perceived brightness of the flat color e.g. FWATER series appears much darker than NUKAGE so needs a higher value. I don't see this impact performance on my rig.

The biggest eye candy boost is baked sidedef lighting applied to every sidedef; no impact on performance AFAIK. 8-) Seems like this could be added to GZDoom easily enough using the polylabel algorithm and a few CVars.

3d slopes are still broken. :roll:


Many thanks for your interest and comments. Amazing that this stuff is possible at all.
cosmos10040
Posts: 68
Joined: Mon Dec 20, 2021 6:16 am
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: Relighting v4.014b - w/ baked sidedef lights

Post by cosmos10040 »

Had a vm abort, ran the same mods as before:

VM execution aborted: division by zero.
Called from hd_relighting_EventHandler.stdev at relighting v4.014b.pk3:zscript/hd_relighting.zs, line -1
Called from hd_relighting_EventHandler.skew at relighting v4.014b.pk3:zscript/hd_relighting.zs, line 1269
Called from hd_relighting_EventHandler.WorldLoaded at relighting v4.014b.pk3:zscript/hd_relighting.zs, line 772
]
User avatar
Hey Doomer_
Posts: 64
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.014b - w/ baked sidedef lights

Post by Hey Doomer_ »

cosmos10040 wrote: Sat Nov 26, 2022 8:51 am Had a vm abort, ran the same mods as before:

VM execution aborted: division by zero.
Called from hd_relighting_EventHandler.stdev at relighting v4.014b.pk3:zscript/hd_relighting.zs, line -1
Called from hd_relighting_EventHandler.skew at relighting v4.014b.pk3:zscript/hd_relighting.zs, line 1269
Called from hd_relighting_EventHandler.WorldLoaded at relighting v4.014b.pk3:zscript/hd_relighting.zs, line 772
]
Interesting. That's a standard deviation routine to calculate skewness (checks for a tail on the curve) to correct the lower area limit of sectors where lights are placed. (Larger sectors generally don't hurt performance with this routine.) I haven't seen that in loading 100+ maps, but I'll check it out. In the meantime you can try changing the minimum and maximum sector size requirements.

A quick fix might be checking for size of the sectors array on line 772 to avoid the function (untested since I don't see this error) - maybe that will work:

Code: Select all

		double skewness = secareas.Size() > 1 ? skew(secareas) : 1.0;
cosmos10040
Posts: 68
Joined: Mon Dec 20, 2021 6:16 am
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: Relighting v4.014b - w/ baked sidedef lights

Post by cosmos10040 »

Hey Doomer_ wrote: Sat Nov 26, 2022 9:11 am
cosmos10040 wrote: Sat Nov 26, 2022 8:51 am Had a vm abort, ran the same mods as before:

VM execution aborted: division by zero.
Called from hd_relighting_EventHandler.stdev at relighting v4.014b.pk3:zscript/hd_relighting.zs, line -1
Called from hd_relighting_EventHandler.skew at relighting v4.014b.pk3:zscript/hd_relighting.zs, line 1269
Called from hd_relighting_EventHandler.WorldLoaded at relighting v4.014b.pk3:zscript/hd_relighting.zs, line 772
]
Interesting. That's a standard deviation routine to calculate skewness (checks for a tail on the curve) to correct the lower area limit of sectors where lights are placed. (Larger sectors generally don't hurt performance with this routine.) I haven't seen that in loading 100+ maps, but I'll check it out. In the meantime you can try changing the minimum and maximum sector size requirements.

A quick fix might be checking for size of the sectors array on line 772 to avoid the function (untested since I don't see this error) - maybe that will work:

Code: Select all

		double skewness = secareas.Size() > 1 ? skew(secareas) : 1.0;
Seems to work fine now. Will keep testing.
User avatar
Hey Doomer_
Posts: 64
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.014b - w/ baked sidedef lights

Post by Hey Doomer_ »

Working on performance issues.

Most map sector areas are positively skewed, which means more lights in smaller sectors.

This seems to help performance and looks better:

Code: Select all

		double min_area = skewness > 1.0 ? clamp(secareas[secareas.Size() - 1] * skewness * 2, rl_Cvar.rl_sector_area_min.GetInt(), secareas[0] * 0.25) : secareas[secareas.Size() - 1];
Boring Explanation
secareas is a descending sorted array of sector areas initially populated according to menu settings. "Skewness" is a measure of the tail on the curve, in this case a greater number of smaller sectors. Multiplying by skew is crude but does serve to cull the lower end of the curve in choosing a minimum area. Skewness varies obviously, but in general Doom maps have more little than large sectors with bright enough lighting for a light source actor.

This doubles the minimum area correction and eliminates extra lighting in smaller sectors that generally hurt performance. Changing the Settings option can cull initial values. I'll probably include this as a hotfix, but still working on it. You can try it out yourself in the meantime.

https://i.postimg.cc/rsTTqNfD/Screensho ... 130132.png

Return to “Gameplay Mods”