cabalistic
-
Posts
1579 -
Joined
-
Last visited
-
Days Won
47
Posts posted by cabalistic
-
-
I might port it to TDM, if I find the time. But a generic non-VR mod is actually trickier to do than for VR, and I have too many other things to do
-
2
-
-
1 minute ago, peter_spy said:
Hmm, r_glProfiling 1 works on 2.08. Did something change in the meantime?
Yes, starting with 2.10 dev builds, it was replaced with an external profiler. I'll try to write up some documentation for it when I find the time.
-
1
-
-
It's not so much duplicating geometry, but it has to render it multiple times, once per light. And light interactions are usually the most expensive thing for the GPU to render, especially if your light casts shadows.
-
1
-
-
Yes, Bloom is a screen space effect. It does not work per light or anything. Instead, it looks at the final rendered image and determines bright spots on it, which are then "amplified" in a sense. As a consequence, it effects everything that is over a certain brightness threshold.
-
Even if they were to accept TDM, the Microsoft store is probably a rather difficult fit technically, because store apps are locked down quite significantly. That would probably cause issues with permissions and prevent the download of new missions - or even setting config options - to work without some significant work on our end.
-
2
-
-
Bloom effect depends on the brightness or luminance of the observed color. The green component contributes the most to the luminance, blue the least. Therefore the bloom effect should always be stronger for green color vs. blue color (for example), but white will obviously give the strongest effect.
Aside from that, there are a couple of cvars r_bloom_* that control the effect. If you ever messed with them in the past, you may want to delete them from your Darkmod.cfg to reset them to their default state.
Other than that, I'm not sure I see anything wrong with your initial green presentation? It shows a clear increase in the effect depending on the color strength. If the first one on the left is already with a factor of 2, then your initial color simply isn't that bright to begin with, so the strength doesn't look wrong to me.
-
6 minutes ago, Dragofer said:
I suppose you can work around it by making a material with forceHighQuality, but it doesn’t make sense to me that TDM compresses my .tga images. If I wanted that I’d use .dds images.
This is by design. Anything dds is uploaded as-is (i.e. compressed), but the remaining textures are auto-compressed unless forced to high-quality if image_useCompression is enabled (and similarly, image_useNormalCompression for normal maps). We can talk about whether or not that design is good, particularly given that compressing textures on the fly is slow and produces driver-dependent quality. But it was done intentionally (probably to save VRAM on older cards, I suppose).
-
1
-
-
6 hours ago, geegee said:
(I didn't see any difference between blend/add 1 and 20 - all seem to produce the same effect. Am I going crazy???)
Did you enable 64 bit color buffers? Otherwise, there is no difference.
-
I can't really help you with art design, I'm not an artist. But if the effect is overpowering, then your material is too bright, or you have set the Bloom effect slider too high - or both.
-
1 minute ago, STiFU said:
Is there any use porting it to TDM, though? I assume you will need a modern graphics card to even run this new feature and modern graphics cards can very well run TDM in maxed out settings in any resolution you want, sooooo.... ^^
For one thing, modern != powerful. FSR is usable on APUs, for example. But it does go all the way back to RX400 cards, and I've seen people experimenting with it on GT 700 cards, so it does work on older hardware. In all likelihood, the GPU needs to support compute shaders, and you're probably limited by VRAM.
As for whether or not it actually makes sense for TDM, that remains to be seen. Tests generally conclude that it works better at higher resolutions, so that may limit its use for lower spec systems. But it could help e.g. if you have a higher-resolution screen than your system can realistically power, because it should produce better images than our current resolution scaler alone.
I do think that there is a decent chance FSR could work pretty well for TDM, though. From all my impressions so far, FSR's strong point is upscaling of edges, whereas small detail in textures or e.g. foliage can end up blurry. But TDM is usually fairly low on such details, anyway, so there is not much to be lost to begin with. We'll see.
-
1
-
-
As for the frame rates, something doesn't add up. Bloom has a constant and fairly cheap cost (depending on render resolution), and there is no way that adding many lights could possibly be cheaper.
However, looking at your screenshots, your first shot without bloom (setup_e_8_noss_bloom_on.jpg) shows NO SHADOWS from the panels, whereas your direct comparison (setup_hdr_8_noss_bloom_on.jpg) does. Most likely, something went wrong when you took that first shot, and shadows were not rendering. That easily explains the framerate difference.
-
2
-
-
8 minutes ago, geegee said:
(Ambient occlusion doesn't seem to have much of a fps impact - esp compared to soft shadows. Soft shadows in TDM brings my pc to its knees.)
Soft shadows are definitely the number 1 frame killer, especially if you set the quality too high. However, AO is *far* from being free, it has a very significant impact even on strong GPUs. It does depend on your render resolution and AO quality level, though.
-
1
-
-
They'll only release the source code mid July, so not possible before then. Also, the official repository will only contain code for DX11/12 und Vulkan, so we'll have to port it to OpenGL, first. Given that the FidelityFX source code is typically very obfuscated, that will probably take a while longer than the couple of hours. But it is on my agenda, anyway
-
1
-
-
We already get the handle via a uniform buffer. Our issue is almost certainly a bug in AMD's shader compiler. I have found a partial workaround, but not a full fix (as of yet).
-
Probably because those are very different things. duzenko's attempt was actual volumetric lighting calculated from shadow maps, not a fake post-process effect. But no, it was never merged due to performance being poor. At some point, we may want to try that again.
-
Unfortunately, if a parameter is not present in a shipped shader, it is almost certainly not prepared for that shader and can therefore not be added without changes to the engine.
Given that we have multiple lights in the game, it wouldn't even be clear which one to send to a post-processing stage.
-
Sort of... you can set r_frobIgnoreDepth to 0, however, this increases rendering cost, and it does not exactly look great in all instances.
-
1
-
-
You need to reset your darkmod.cfg, or specifically you need to enable in_grabMouse.
-
4
-
-
14 minutes ago, MirceaKitsune said:
From what I'm seeing SMAA appears to look best, but this could mean it's also slower as some articles indicate, so TAA may be the ideal middle option.
It's not that simple. There are different sources of aliasing. TAA, as the name implies, specifically targets *temporal* aliasing artefacts, which happen when objects or the camera move. Neither FXAA nor SMAA (in its purely post-processing form) do anything against those artefacts, but you won't see those in a still image. They become really apparent for e.g. small objects in the distance when you move the camera - you'll notice a very obvious edge shimmering, even if in a still image it might look fine. A good example would be Skyrim when looking at some trees in the distance - here the difference between FXAA and TAA becomes very obvious when moving the camera around.
In its basic form, SMAA is just another purely post-processing effect like FXAA, so the same restrictions and caveats apply. It might do a better job at detecting edges to blur than FXAA, but it doesn't magically have access to any more information than is already in the rendered image, so it's still just blurring edges. It is almost certainly cheaper than TAA and easier to implement, but it also does nothing against temporal aliasing, so it will not stabilize images in motion. SMAA can be combined with MSAA or TAA, though, although at that point it obviously becomes a lot more expensive...
-
7 hours ago, MirceaKitsune said:
Is it also as fast? Also, regarding FXAA, on what Cabalistic mentioned earlier and in the initial chat: FXAA is supported by the video driver, however it's not an option you enable at runtime, I looked for a system parameter and couldn't find a way. The engine probably needs a flag to call OpenGL with this feature. If that's the case and I understood correctly, supporting it would be a matter of just implementing a menu option linked to a renderer initialization call. Don't know for certain if that's the case, just what I'm gathering so far.
No, there is no such option or flag for OpenGL. You can literally enable it in the NVIDIA graphics panel for any game. The Radeon software has a "morphological anti-aliasing" option that you can enable, although I'm not entirely sure which implementation it is.
-
5 hours ago, stgatilov said:
Temporal antialiasing uses information about velocity, and I think this information allows it to achieve good quality: it knows how current frame relates to the previous/next ones, so it blurs in such a way that pixels don't jump back and forth as you move.
In addition, TAA employs a sub-pixel jitter to the projection matrix. So each frame, the projection is slightly offset in such a way that you are looking at a different "subpixel", if that makes sense. So when combining the current and previous frames, it actually has some indirect access to subpixel resolution even in cases where MSAA does not (like edges in lighting). It does still blur the final image, but that can actually be counteracted with the CAS filter pretty well, and the anti-aliasing effect is very good - *if* the velocity buffer and frame reprojection are implemented well.
-
I've written this before, but personally I'm not a fan of FXAA. Due to its purely post-processing nature, it has no actual extra information to resolve aliasing artefacts, so all it can do is blur the image. Sure, it is a "smart" blur filter in that it's looking for edges in the picture, but still. This is (in my opinion) not true anti-aliasing.
Given that you can usually enable FXAA in the graphics driver for any game you want, integrating it directly into TDM feels like a waste of development effort to me. Although I'll concede it would be more convenient to have it as an ingame option.In my opinion, the only real challenger to MSAA is TAA, but unfortunately that one's the most difficult to implement, by far. Especially if you want to achieve actually good results. But we don't even have some of the prerequisites in place in the engine, so we can't work on this in the foreseeable future even if we wanted to.
-
4 hours ago, Sneaker said:
Hmmm, is it planned to "hide" the outline for parts of the object you shouldn't be able to see. I can see outlines of objects through chests and candle outlines can be seen from under desks (attaching screenshot of grate that sinks into floor).
You can set r_frobIgnoreDepth to 0. Note, however, that hiding parts of the outline is technically quite difficult to accomplish, and the solution that I've implemented is not perfect (and can, under certain circumstances, eat up quite a bit of performance).
-
1
-
-
Sounds like a bug, then. You could try the most recent dev build where the input system has been overhauled, perhaps that might fix it. If not, as a workaround you can always reassign the key or use the mouse wheel to cycle through weapons and eventually put them away.
hide_distance broken again?
in TDM Tech Support
Posted
But these screenshots look nothing alike. Surely that's not what a player would want to happen just by moving a certain amount beyond some arbitrary distance?!
Any LOD effects are usually meant to be deployed where a reduction in graphical detail gives a performance boost without being too noticeable to the player. Those lights being turned off is as far from not being noticeable as you can get.