Daft Mugi

Thank you for the great explanation! Initially, I hoped to have a cvar that would restore the look of r9853 with stencil shadows, but now with more understanding, it seems that doesn't make much sense. Future maps are going to be built with the assumption that they exist (and probably not use that "using shadows in volumetric not required" option). Besides, volumetric lighting is growing on me. I think they look great in Iris and Written in Stone, and the performance cost is a little better than I originally thought. The cvar r_volumetricEnable is still incredibly valuable, and I'll continue to use that. From now on, I hope you don't mind me sharing bugs or rendering artifacts I find. I look forward to seeing volumetric lights get better and better.

In r9853, volumetric lighting (god rays) was presented as shadows maps have them and stencil shadows don't. I was using the terms/features as they were presented. The Written in Stone screenshot for r9853 was taken using stencil shadows, so I assumed volumetric lighting was not used. Hazard Pay and Iris don't have god rays when using stencil shadows. How is it that Written in Stone has them when using stencil shadows?

@stgatilov I've found a difference between r9853 stencil and r10159 stencil with r_volumetricEnable 0 while playing Written in Stone. (See screenshot.) How is there this difference? It seems WIS is using transparent geometry when using stencil shadows in r9853, but those don't show in r10159 with r_volumetricEnable 0. Can this be fixed?

Thank you! This is really helpful. I've bound the following, so I can easily enable and disable volumetric lighting. It's quite interesting to see the differences. bind "[" "r_volumetricEnable 0; reloadModels" bind "]" "r_volumetricEnable 1; reloadModels" I'd like to point out that r10159 power consumption has improved a lot since r9853. Awesome work! Iris (Moonlit Manse area) ============================= No Volumetric Lighting stencil r9853: 45 - 50 Watts stencil r10159: 35 - 40 Watts ----------------------------- Volumetric Lighting (r_volumetricSamples 24) maps r9853: 90 - 100 Watts stencil r10159: 60 - 70 Watts Yep, I don't like how shadow maps have edges with artifacts and as a whole can have other artifacts in some cases. I guess the increased power consumption is an issue as well. I appreciate your continued work on this. Cheers!

This post is quite frustrating for me, because it sounds quite critical. In person, it would be easier to point out the good parts and ask what's going on with other parts. Without that, unfortunately, it's just using this limited medium of text and a few screenshots to point out things and hoping there is a solution, which isn't an ideal way to communicate. Edit: The main thing is that I know that you, @stgatilov, did a lot of great work on this. I've seen the commits and improvements over time, and I appreciate you spending your time to improve this game we like to play. So, I really don't like to talk about aspects I don't enjoy, and unfortunately, I'm not enjoying volumetric lighting. The volumetric lighting in Hazard Pay has quite a few issues that degrade its look, but the one volumetric light I noticed in Iris (Moonlit Manse area) looks good. So, maybe it really depends on the volumetric settings in each map, and they can be tweaked/fixed. I'd like to see an option in the settings menu to enable/disable volumetric lights. Could you please add that cvar? Something like r_volumetricLights 0/1. This has three benefits: For those who prefer the look of the game without volumetric lights, they can turn it off. This is really not different from being able to toggle bloom, ambient occlusion, color precision, and shadows maps vs stencil shadows, so why not volumetric lights as well? It'll help those who are having performance issues or need to keep the temperature of their graphics card at a minimum. Volumetric lights (or maybe it's really the shadow maps?) add between 5 to 25 watts of power to the graphics card I measured. I imagine those playing on a laptop would be impacted the most. Others may get unwanted fan noise. It'll help with measuring and comparing the performance between volumetric lights off and on. As for player preference, the moving volumetric lights in Hazard Pay cast shadow maps with edges that wiggle/wave whereas stencil shadows are static/still. That wiggle/wave doesn't look good and is distracting. Maybe the shadow maps can be improved to fix that? It also has fog that has graphical artifacts that look like distorted waves, but those can be fixed/reduced by increasing r_volumetricSamples from 8 to 24 (screenshot #1). Other volumetric lights have fog with multiple ring artifacts that no setting I tried fixed/reduced them (screenshot #2 with ring pattern marked). The rings seemed to be where the fog touches the wall. There are some volumetric lights that make areas of a scene overly bright, especially when two volumetric lights overlap (screenshot #3). Given all that, the look of stencil shadows without volumetric lights is preferred. As for performance, it's probably pretty good to great, but I don't know how to quantify it other than that it adds 5 to 25 watts of power to my graphics card, generating more heat. (Again, maybe it's really the shadow maps?) The FPS is a steady 60 fps even with all settings maxed out. r_softShadowsMipmaps 0: Added ~10 watts in one scene. r_volumetricForShadowMaps 0: Turns off shadows completely where there is a volumetric light. Stencil shadows are not used/seen. r_shadowMapSize 512: Reduced ~5 watts in one scene. r_volumetricSamples 0: Can significantly reduce wattage (~10 watts in one case), but then it looks blocky, of course. Interestingly, when I set r_volumetricSamples from 8 to 100, it might add ~5 watts without an FPS drop. I hope volumetric lights can improve a bit more along with an option in the settings to enable/disable them.

Ah, sorry, I should have been more clear. As for performance using stencil shadows, the wattage sent to my video card doubled in some scenes compared to r9853/2.10 (stencil shadows / no volumetric lighting), and its fan goes from off to on.

@stgatilov I did some testing. The volumetric lighting does look significantly better! I appreciate the work you've done to remove the dithering artifacts. I also tested The Painter's Wife and could see all of the stencil shadow optimizations you've done have made a significant performance improvement! It's really impressive! However, volumetric lighting (r10157) causes significant performance degradation and still has some graphical artifacts. I'll post about those later. I tried out different volumetric settings, such as r_volumetricSamples, to compare performance vs quality. Even with higher settings, there are still graphical artifacts, unfortunately. As for performance, the wattage sent to my video card doubled in some scenes compared to r9853/2.10, and its fan goes from off to on. Being concerned with the video card wattage, heat, and fan being on (i.e. fan noise) may be ludicrous to some who are used to playing recent AAA titles, though. As things are now, I'd rather have volumetric lighting toggled off for improved performance (i.e. no fan noise) and no graphical artifacts (i.e. distractions). Could you please add a cvar for toggling volumetric lighting on/off? Even though I'd rather have volumetric lighting off, I do appreciate all the work you've done on this. It has improved a lot.

I tested it. Thanks for fixing this!

@stgatilov r10141 introduced some strange (collision/trace?) bugs. I first noticed that it was difficult to go down a ladder in Hazard Pay. At the second level (in the attached screenshot), it's really hard to go down or up. ]getviewpos 2482 1723 84.25 53.3 5.1 0.0 I've also noticed some clipping through walls and getting stuck in the floor while playing another mission, but I didn't take notes about those. r10140 is fine.

This still happens on a physical machine, though. It happens with the training mission and other missions. Oddly, it does not seem to happen with Hazard Pay.

@duzenko I tried to reproduce this issue using a virtual machine and could not. I don't get the distorted frame. I ran a virtual machine with Ubuntu 22.04 guest on Ubuntu 22.04 host.

@AluminumHaste The slow mo is pretty awesome. Good idea! Thanks!

If I "Start This Mission" and "setviewpos", message #2 fades in ok without issue. However, if I "Start This Mission" and traverse to that position, message #2 fade in has the issue. After seeing message #1, shooting a rope arrow, and climbing it, a save can be made. Then, that save can be loaded to reproduce the issue again and again. // Message #1 Look up for the wooden beam that sticks out. Shoot a rope arrow into it, jump on the rope, climb up, and jump off the rope to detach yourself. // Message #2 Jump onto the rope. Stay near its bottom end. Tap 'Attack' to swing. Repeat as the rope goes through its mid point to make it swing more. Then jump over the canal on the far swing.

Do you have a link to that? That would be helpful, so we can consolidate this issue and compare.

The "flash" I noticed turns out to be from the objects/solids becoming translucent. When they are translucent, they appear brighter. This can be seen in the screenshots.

Did you see the TDM main menu? The distorted frame shows after launching the game from the desktop and before the main menu displays.

Here's another example. Klatremus' Mission 2: The Tears of St. Lucia video linked at 1:15:59. I've attached a series of images that show a regular view, a translucent view, a loading screen, a translucent view, and finally a regular view. To see it yourself, you can step frame by frame on YouTube by first pausing and then using the "." key to step forwards (and the "," key to step backwards). Just translucent images as well, so they can be seen a little more clearly.

Here's another example. Klatremus' Iris video linked at 1:33:01. I've attached a series of images that show a regular view, a translucent view, a loading screen, a translucent view, and finally a regular view. To see it yourself, you can step frame by frame on YouTube by first pausing and then using the "." key to step forwards (and the "," key to step backwards). Just translucent image as well, so it can be seen a little more clearly. The object inside the chest can be seen.

When quick loading, the screen usually flashes a little brighter and shows something odd for a brief moment before and after the loading screen. I had trouble seeing exactly what it was until I recorded it. The attached image shows a series of screenshots that show the regular view, what looks like some sort of view where objects become translucent, the loading screen, a translucent view again, and finally the regular view. Note: I recorded this with my phone, so the translucent view is showing roughly 2/3 of that frame due to the camera and monitor being out of sync. (Recorded at 60 fps, Game 60fps) Edit: The "flash" that is seen is from the objects/solids becoming translucent. When they are translucent, they appear brighter. This can be seen in the images. Bug: https://bugs.thedarkmod.com/view.php?id=6149 This site recompresses uploaded images, reducing the quality a lot. I've attached just the translucent image as well, so it can be seen a little more clearly.

Indeed. I am cursed.

Another way to see this bug is to use the stealth stat mod that shows the stats as a message. I've seen this bug a lot in Klatremus' walkthrough YouTube videos where he used that particular mod. These days Klatremus uses a different stealth stat mod that replaces the loot stat instead. I've attached a series of screenshots from one of Klatremus' videos. It shows a blank message at 100% opacity and disappears. Then, the stealth stat message fades in. To see it yourself, you can step frame by frame on YouTube by first pausing and then using the "." key to step forwards (and the "," key to step backwards). The video link starts at 1:15:56 and the message appears during 1:15:57.

@duzenko No worries about being busy with real life stuff. I hope you found a microwave you liked. I've included a series of images that show the bug. I used my phone to record my monitor using 60 fps video capture and the game is running at 60 fps. The series of images shows that the previous message displays at 100% opacity and disappears. Then, the current message fades in over time. This was recorded on the training mission. ]getviewpos 1427 -359.26 560.25 3.3 176.1 0.0 Though, it is noticeable with most (or all) messages in that mission and other missions. @AluminumHaste Thank you for looking into this as well.

That readable's background is quite dark. I wonder if that filter is also applied to the readable overlay. So, the problem is that if brightness_ui and gamma_ui are applied to that readable, then it can become too dark.

So... I discovered another complication. Some readables have their own "filter" that darkens the screen. I've attached a readable from Volta 2 to show the "filter" (I don't know what to call it) of the readable. When the readable overlay is shown, the game world is slightly darkened. In this case, any reduction in brightness or gamma -- for example, the brightness_ui and gamma_ui cvars -- makes it look too dark. The screenshots both have identical gamma and brightness values. guis/readables/scrolls/scroll_hand_ellianerelle_smaller.gui

I agree. I tried this by making newspaper_bridgeport01.dds, newspaper_bridgeport02.dds, and newspaper_bridgeport03.dds darker, and it worked well. The result was better than I originally thought it would be, so thank you for suggesting this. As an experiment, I'm working on some code that adds "r_postprocessing_gamma_ui" and "r_postprocessing_brightness_ui" cvars. When the inventory, objectives, map, or readable overlay is shown, the values of "r_postprocessing_gamma_ui" and "r_postprocessing_brightness_ui" are used instead of "r_postprocessing_gamma" and "r_postprocessing_brightness". When those overlays are closed, the values of "r_postprocessing_gamma" and "r_postprocessing_brightness" are restored. The result works quite well and is predictable. I have this working already and need to clean up the code a bit before sharing it. An automatic way to set the gamma/brightness values would probably be better, but I imagine I would somehow need to sample the background texture ahead of time to get some kind of brightness value. That is something I don't know how to do or if it's even reasonable for this. I'm doing what I can. Maybe the code stgatilov mentioned can be used instead. Overall, a combination of altering the background textures and using the new cvars gives a good result in my testing.