Relighting v4.0165b - blurry shadows w/ rlassets

[thugsta]

I hope you can still make this compatible with LZDoom or somehow a version for it while keeping everything that could work from GZ, as it would be great to see your work on wireless headsets that only have a port of LZDoom for example.

[Hey Doomer_]

I hope you can still make this compatible with LZDoom or somehow a version for it while keeping everything that could work from GZ, as it would be great to see your work on wireless headsets that only have a port of LZDoom for example.

What are the errors with LZDoom? If it's a ZScript issue that might be doable.

[thugsta]

Not currently at home but it was something along the line of dynamiclight.DontLightOthers if memory serves me correct. A substitute for this might be needed to keep the performance i assume. I removed those along with fixing the bugs you have documented here to test and it then works and performed great for the bit i tried it, hope you can do more then that with it.

Thanks heaps and keep up your fantastic work with this, highly recommended mod.

[Hey Doomer_]

Posted 4.01b.

Bug fixes include the above and others that improve performance. (Reflections are improved, for example.) On vanilla Doom I am getting 200+ fps most of the time; still testing. I am not able to fix the Vanguard map at this time; it may be the map itself. Support for 3d slopes is buggy. I gather quaternions and voxel pitching are being added to GZD. Hope springs like a pissed imp.

Polylabel lighting is far superior to CenterSpot or Centroid. Load times are increased but performance is otherwise unaffected. It does affect shadows (I think positively).

Also added player and monster shadows on other sprites. This adds a small subtractive light for a few ticks when a shadow is cast on a nearby actor, so don't get your hopes up. Early testing on this looks pretty cool, however, so I've put it in this version. This like most everything else can be turned off in Settings.

Thanks for the support, comments, and videos!

[phantombeta]

I noticed as soon as I started Vanguard, the sky texture was missing, and turning off Relighting restored it.

I've been looking at this. I don't know how this has anything to do with the reflection code. There are only a few tags on this map, and none of these conflict with Relighting. If I don't add tags it works, but if I remove this from MAPINFO it works also:

Code: Select all

map MAP01 "Overgrown Sepulcher"
titlepatch CWILV00
next MAP02
secretnext MAP02
music D_RUNNIN

Not sure why Relighting breaks this bad boy...

It's breaking because you're adding random tag numbers to sectors. And you're using texture indices as tag numbers, those are an entirely arbitrary, implementation-defined value - there's no way to ever guarantee these don't conflict with anything in a map.
Tags are meant to be used by the map to do things, not to store arbitrary data like this. I can guarantee this is caused by the added tags whacking some Transfer Sky special somewhere in the map, be it by messing the tags in the Transfer Sky action up or by giving a tag to sectors that didn't have one.

The reason it "works" if you remove the map definition from MAPINFO is because the MAPINFO doesn't define a map-wide sky, and by removing the definition you're making it default to the original MAP01 MAPINFO data, which does define one. It's still not the correct sky for the map.

The answer to all of this is Don't do that!

[Hey Doomer_]

It's breaking because you're adding random tag numbers to sectors. And you're using texture indices as tag numbers, those are an entirely arbitrary, implementation-defined value - there's no way to ever guarantee these don't conflict with anything in a map.
Tags are meant to be used by the map to do things, not to store arbitrary data like this. I can guarantee this is caused by the added tags whacking some Transfer Sky special somewhere in the map, be it by messing the tags in the Transfer Sky action up or by giving a tag to sectors that didn't have one.

The reason it "works" if you remove the map definition from MAPINFO is because the MAPINFO doesn't define a map-wide sky, and by removing the definition you're making it default to the original MAP01 MAPINFO data, which does define one. It's still not the correct sky for the map.

The answer to all of this is Don't do that!

Thanks I see how that's done now that I look at the map. Makes sense.

I'll think on this.

Edit
Hm. Not sure I can read Line Specials in the post processor. Still looking.

Edit
OK, figured out a clean workaround. No worries, this will be in the next maintenance release.

[kalensar]

This one has been purring like a kitten for performance. Well done!

[Hey Doomer_]

Quick post on an upcoming maintenance update with the following: added a quicksort for sectors by area & reduce light sources below the median; fixed transfer sky texture & unique tags issues; corrected dimness code; added optional simple shader for gamma, saturation, and color bleeding. Performance is likely improved on maps with many small, bright sectors in tandem. Fixed numerous bugs that affect visuals.

Color bleeding is what it sounds like; color channels are mixed together and the effect amplified or reduced by a factor. This effectively washes out colors in bright areas, which can look more realistic. Still testing and tweaking, but I don't think this affects performance. Release soon. Thanks for your interest and comments. That means a lot!!

color_bleeding (Phone) (Custom).png (70.88 KiB) Viewed 1456 times

[Dan_The_Noob]

I noticed 4.01b takes a few seconds longer than 4.0 did when initially loading up a map, did something get changed to add more checks?

Talking about MAP01 of DOOM2 here.

[Hey Doomer_]

I noticed 4.01b takes a few seconds longer than 4.0 did when initially loading up a map, did something get changed to add more checks?

Talking about MAP01 of DOOM2 here.

That's probably the iterative polylabel algorithm. Depending on size and shape this can take dozens to thousands of iterations to find the sweet spot to place a light source. You can see in the courtyard of MAP01, for example, how light sources are right where expected. Although load times are increased, I haven't seen anything else that does this quite so well.

Source and explanation are here: https://github.com/mapbox/polylabel

[Hey Doomer_]

Quick progress update:

https://i.postimg.cc/cH3F45Zm/effects.gif

The above shows some of the effects I've been working on, although this doesn't do the coloring justice. Recursive functions have been added to color and dim sectors. The shader has been tweaked to highlight reds and greens and dull blues. (This affects dynamic lights as well, a cheap perk! ) GLDEF objects now use defined colors (at least as far as GZDoom's GLDEF goes, since ZScript lacks regular expressions). Defaults have been adjusted. Numerous bug fixes, allowances for sector lighting specials, etc. Little stuff.

Some of this can be done through the menu settings as well (such as making various surfaces reflective). I've just been cleaning up the back end and fixing bugs in the code.

What isn't working: shadows on 3d slopes, multiplayer mode (which I don't play, so guessing on this). The big frame rate killers are still reflections and clustered objects or complex architecture. This can be affected by changing Performance Settings. There are only three things that are hard coded: Brutal Doom footsteps, flashlight classes & known animated flat names from the Wiki. Everything else is read on the fly from anything else loaded with this mod. This should be nearly universal. Still testing.

Will post an update shortly. Many thanks for your interest and comments!

[Dan_The_Noob]

this is all cool, but i'm still curious how much info a brightmap shares to any possible lighting... some lights' brightmaps would be cool to see emit actual colour grading etc.

[Hey Doomer_]

Posted 4.011b - maintenance upgrade as noted with a shader & gldef lights added. Bug fixes.

At this point I don't see features being added. I've tried to add small dynamic lights sparingly to moveable or disposable items to affect shadow mapping. Dynamic lights should be dynamic in other words. Look and feel can be tweaked through menu settings without affecting performance.

I'm still pondering adding some form of texture lighting. I just don't know if it's worth the hit. Shaders seems more promising.

Let me know what you think!

[Dan_The_Noob]

Posted 4.011b - maintenance upgrade as noted with a shader & gldef lights added. Bug fixes.

not sure what's happening but having the "shader" on causes some weird clashes with other shaders.
https://imgur.com/a/SoHhKAW

also initial load is still really long even on MAP01, is there a certain setting that will cut the loads down? it gets longer the bigger maps get.

[Hey Doomer_]

Posted 4.011b - maintenance upgrade as noted with a shader & gldef lights added. Bug fixes.

not sure what's happening but having the "shader" on causes some weird clashes with other shaders.
https://imgur.com/a/SoHhKAW

also initial load is still really long even on MAP01, is there a certain setting that will cut the loads down? it gets longer the bigger maps get.

It could be the order of load for the shaders or some other conflict. Other than that I'm not sure.

I'll look at load times again, but this is probably the polylabel setting (I'm getting around 12 seconds more). There are several recursive algorithms at work, and that's the likely culprit. I can expose the algorithm precision in settings, which may speed that up. I'll check that out. You can try centroid or centerspot in the meantime.

Edit
Still investigating.

Boring Explanation
The mod attaches unique tags to sectors (if reflections are selected), reads the last palette, all flat lmp files in the level, all animdef and gldef lumps, and then determines where to put light sources before bleeding dimness and color into back sectors. Recursive routines include the polylabel (which calls the centroid function for each polygon) and back sector searching, which is done twice. Sectors to be processed are sorted by area using a very fast quicksort algorithm. So far I'm not finding any one culprit. Extra loading time is probably a combination of the above, and depending on mods loaded with the game will burn cycles on one or the other of these routines more or less. The polylabel algorithm has the most iterations by far (back sector searching quickly reaches a dead end), but it's extremely fast and changing precision variables doesn't seem to affect load times.

I'll investigate optimizing these routines. I'm sure that's possible. Given all the mod does load times are bound to be extended unfortunately.