MirceaKitsune

Not that badly, sorry if I'm overthinking it. It's mostly that the same window models are used for static decorations that go into nothingness, as well as interact windows connecting buildings. What did help is functional windows were left semi-open by default so you could see them, that made it better.

Oh, that's definitely not a bad aim! If there's any actual critique, I'd say some paths could have been a bit more obvious: You need to guess which windows open and are required to go through, while some important ways or items are pretty hidden and take a bit of looking around to guess. The general idea of making it this way is otherwise a nice one, it made good use of jumping and mantling while having a very cozy feel; I think it could have used more open spaces too for alternation but that's just a personal taste thing.

A very nice and quality FM. The design is definitely interesting: I like how navigation is based on jumping between buildings and going through spaces connecting different locations, even if some are difficult to find and I needed guidance from here a few times. It's a difficult FM in general as spaces are tight and well lit, it's one of the maps I couldn't imagine going through without reloading nor getting spotted at any time.

Now that I understand what I'm working on better, I'm trying create a double use shader: It can be used as a view overlay material to get DOF by piping in the depth texture, as well as a surface material to get blurry glass (eg: condensation) by using a dirt map instead. heatHazeWithMaskAndBlur has a constant hardcoded blur, you can't use it to get dirty glass that blurs selectively, the same shader would thus allow glass windows with that effect. At least the shader will hopefully be acceptable. If for any reason we can't get DoF in the vanilla engine, I can at least create a simple pk4 mod for it this way, albeit that's a lot more limited so I hope it can be done the right way. This is something I've always wanted in TDM so in my book it's worth it, though only if I can get a beautiful and clean result... this will likely require using multiple samples where the image is offset in 4 directions for each one.

Fair enough. I started working on the custom shader... sticking to ARB with material overlay as I have existing examples to practically work with, it can be ported someday when the other stuff would be. This approach is especially handy as it allows using the shader on surfaces too, if you want to have a foggy window that selectively blurs what's behind it... won't include deform as that would make everything too complicated, that can be used on its own layer. The part I'm not fully clear on is how to scale the effect per pixel as it's still constant. Existing examples for deforms work by having a texture push the vertices around, in my case I want a constant offset to generate each blur pass but the distance of this offset needs to be based on the value on the Z buffer. Maybe I can just use the depth map itself as the deform texture, bur that's a grayscale image not a normal map. How would I read the intensity at a certain pixel of the second fragment map?

I remember now: There was a goal to convert every ARB shader to GLSL... the right way would be doing it all in GLSL from the start then. I'm not seeing any examples of this being done via material without requiring engine edits: Every vertexProgram / fragmentProgram entry in the default materials points to a vfp file. Does it support using glsl there? The issue with heatHazeWithMaskAndBlur is nothing seems to adjust the blur intensity. Am I missing a parameter in my test or is it simply designed this way and will need to be forked into something else? I definitely like it in-world too, but yeah I seem to be in a minority of TDM players that do. Hopefully no one would object to it being integrated into the engine, but I'll surely have to do the work for it which I don't mind as long as I can figure it out. And yeah: As a separate feature I was thinking if we should blur the background like we do underwater when the player is accessing a readable, which doesn't need to be DOF per say and is also easy to do with existing shaders. If others agree it would look better I can try that as a separate change sometime.

Making it static would be a dozen times easier too so I might do that after all. I'd like to only add some slight distance blur, possibly near blur too but only for very close objects like if you're standing as close as the engine lets you. For now I'm stuck understanding how shaders work. When do I even want glsl or fs or vs, how are they each loaded for which purpose? The proper way seems implementing it as a stage, using the quality gaussian blur shader already included... however this requires engine changes as each stage has its own C++ counterpart, also the only way to have it use cvar settings. I'd have to rely on the material trick for my implementation... then if what I get working would be good enough I'd need a dev to add it to the engine, which would require more changes to the shader so I dunno how to best go about it.

dof { description "Depth of Field effect." discrete nonsolid noshadows translucent { program heatHazeWithMaskAndBlur.vfp vertexParm 0 0 vertexParm 1 0 fragmentMap 0 _currentRender fragmentMap 1 textures/sfx/vp1 fragmentMap 2 textures/water_source/vp_water fragmentMap 3 _currentDepth } } With "g_testPostProcess dof" the following effect can be achieved: But the blur is constant, I can't find a way to tweak even the global intensity let alone per area: vertexParm 0 and 1 are the distortion time and strength, 2 and beyond don't appear to do anything. Each fragmentMap doesn't seem to be modifiable so it would be a constant effect regardless. Clearly going to need my own fragment / vertex program based on that, may work without needing a custom GLSL shader though.

Thanks again. It says "material not found" so it's probably named differently, but I tried it with other materials as a test and they show over the screen so technically this should work. Digging through the files now but once I find what I need I may just have the requirement to get me started. Once more never underestimate how awesomely idTech 4 was designed This is what I get with "g_testPostProcess xray_glasses_overlay_mixed_warped" for instance: I vaguely remember that long ago there was discussion about making water and / or stained glass blur with distance rather than constantly. Was this ever achieved to use as an example? It's what tdm_water.mtr - textures/water_source/water_blurred seems to be doing, it uses heatHazeWithMaskAndBlur.vfp which can probably be simplified as I only need the blur component. I can't find where vfp files are stored though, glprogs only contains fs / vs / glsl files.

Thanks, that's very useful! Does this mean it can be doable without requiring engine changes at least as an initial proof of concept? If so I could create this as a mod and pk4 addon at very least. Also is there a command to reload such effects in realtime, so I can alt-tab switch to make changes instead of needing to restart TDM for each test? I was thinking we already have a blur effect when the player is underwater: It's a constant blur but maybe not too hard to have the intensity adjusted by a range in the depth buffer? I'll have to find its file see how that's implemented and how to scale it per area. I wonder if it will require a script too, to read custom cvar settings or smoothly adjust focus based on the value of the center pixel... will have to see how much existing examples help when I'll look into it. Most engines use DOF for years, pretty much every AAA engine these days has it... I enable it in Godot where it's also a builtin camera effect. The best solution for non-VR is using the center pixel to measure distance and adjust, I've seen that approach before and personally like the feel; Ideally I could use the average value of a circle around the crosshair, the average grayscale value determining the focus point.

Personally I think it's unrealistic if it's overdone: It needs to represent not what a camera lens sees but what a person's eyes will, albeit that's different for individuals like people who wear glasses. Anyone can however notice that if you put a finger in front of your eyes then focus either on it or the background the other will become blurry: I don't think that's a bad effect to simulate, which would be both realistic and good looking... for our environments especially I think it would look incredible. It's very much a thing of taste though. Like I said I don't think it should be enabled by default, heck I'd be fine with it even as a hidden cvar I can put in my autoexec.cfg (seems frob highlight ended up like that). If so few others like this effect enough to want to work on it though, I may have to try it myself at some point; Wonder if someone could at least help with the code part so I could try doing the dynamic shader myself based on examples, plus confirm it would be accepted so I wouldn't work for nothing. Also do we still use ARB shaders? I thought we switched everything to GLSL years ago. Also curious if our shaders currently have access to the information needed to produce this effect, namely the Z buffer (grayscale depth pass). I wonder if using an independent resolution per area is possible though I strongly doubt it: I think it's an universal camera property, doubt it could be easily made to work per-pixel. It would be interesting since then it could also improve / recover some performance by rendering near / distant stuff at a smaller resolution? Is there anything left of that on the forum or elsewhere? Maybe it could help with a new implementation.

This is something I wanted to try implementing myself more than an year ago, but ultimately figured it's overly advanced engine stuff for me: If no one else wants to I may still attempt it someday, in the meantime I wanted to write and ask about it at least. I don't know if this was previously discussed and I hope I'm not repeating something old: I've been seeing all the amazing changes done recently like volumetric lights... watching how far TDM has come makes me excited to see it get even further and become even more amazing. One of the last remaining renderer features I feel we're missing is the Depth Of Field effect. I do believe having this would make every environment in each FM even more incredible and realistic, while bringing TDM even closer to having top notch visuals on par with most modern engines (if we exclude PBR materials). Existing shaders and tutorials for the GLSL implementation are out there possibly even an existing idTech4 port; Initially I hoped it might be as easy as grabbing a freely licensed shader and integrating it in the engine, but usually things are always harder in reality. For starters I'm curious if others are with me in wanting this, if there are any plans for adding the feature, and if there remain any major roadblocks in the engine preventing it... engine wise I know the shader just needs access to the Z-buffer and can typically work its magic from the depth map. The best implementation I'm hoping we can get is the dynamic one, which smoothly adjusts focus based on where the player is looking (distance of the center pixel in the middle of the screen). By default the effect definitely shouldn't be excessive, only blurring distant or near things very slightly unless you're looking at a surface right in front of you. I don't believe it needs to be enabled by default as long as it's in the menu, like the sharpness filter it shouldn't bother anyone who doesn't want it and make things look beautiful for those that do.

Finally finished it. What a beautiful FM! I can see a lot of effort and detail went into it including the dialogue. Things went on for longer than I expected and in a good way, really felt like you went on a great little adventure. You get hints for everything and won't easily get stuck, that's a mistake many FM's do having the player waste over an hour only to ultimately read the solutions to advance. I like how it not only gave depth to the main villain, but also the player as this nice Robin Hood type guy. It had a few rather unique elements and ideas, especially in the final areas, as well as...

Sorry about that: Thought it might also be map related and caused by custom def's, not easy to tell when it's a map issue or not. It doesn't seem to break anything essential in any case, so it can be played well even if you run into this issue.

Think I'm about halfway there. Found another bug in the meantime. Latest dev version of TDM if related.

Just started playing this amazing FM: Very impressive, love the atmosphere and detail and extra dialogue. Normally I post after I finish a FM, but I wanted to report an obvious and annoying bug I've come across... note I'm on the latest dev version of TDM so I don't know if it's just the map or something changed that's causing a mismatch.

Very nice FM, definitely one of the great ones! Nice way to get accustomed to the new volumetric lights, albeit the FPS was extremely low on this one whether for that reason or another. It was a nice change of scenery as we don't have maps in such a setting often. Also many nice unique assets... if license compatible I definitely see some making it into official, like the lights carts and shiny zombies. I only found a few issues, like if you climb in the wrong place and look up you can see some detached patches not quite touching the ceiling.

Right, that's another limitation: Stencil shadows can't produce shadows from alpha textures, alongside shadows not softening with length. So if you want maximum quality and realism you need maps, stencil may be faster in some cases though. Speaking of shadow maps: Is there a reason why "r_shadowMapSinglePass" and "r_shadowMapCullFront" aren't defaulted to 1? I almost lost them from my config and when I turned them on I noticed a significant performance boost, at least +10 FPS.

Wonderful, that seems to be working: I can now switch to stencil shadows with r_softShadowsMipmaps and see them just fine. If that doesn't break anything on other platforms it's good on my end.

Replaced every vec4 with uvec4 (left ivec4 untouched) in tdm_base01.pk4/glprogs/tiled_custom_mipmap.frag.glsl: Still would not work. Here is another condump with this change included: con.txt

Darkmod.cfg con.txt As my config is ancient I went for a fresh one only changing some menu settings: Same issue by default. They're two different implementations I believe: One isn't necessarily better than the other, it's whichever renders fastest and / or looks best, which until now changed with each release. Yesterday I got the impression stencil feels smoother in terms of FPS, but I don't get realistic shadows that soften with distance over surfaces so I wanted maps to defeat that limitation. Also I use fullscreen not borderless. Borderless helps with some issues... but IIRC it means the OS still renders the desktop and wastes resources, I use fullscreen to ensure maximum FPS.

A forgotten glprogs directory was causing colors to go crazy, removed that before I started testing. The update went well but just to be extra safe I did that cleaning as well, same issue after reinstalling. GPU driver is amdgpu, the default installed and used by the OS (not pro version). This is my system info from the KDE panel, Mesa is 22.1.7 with Amdgpu 22.0.0: Operating System: Manjaro Linux KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Kernel Version: 6.0.2-2-MANJARO (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 570 Series

Very nice for a small and simple FM, was a good way to quickly test the new dev build. There isn't much to say as it's pretty straightforward. Definitely more on the difficult side, didn't see a way to get no alerts and no kills / knockouts without using water arrows in several locations.

Just set the option to stencil and did a full restart: Same issue, no shadows with stencil and the new setting turned on.

Here's a proper screenshot of the broken version, managed to catch it using system printscreen instead.