Jump to content
The Dark Mod Forums

cabalistic

Development Role
  • Posts

    1443
  • Joined

  • Last visited

  • Days Won

    45

cabalistic last won the day on June 24

cabalistic had the most liked content!

1 Follower

Profile Information

  • Gender
    Male
  • Location
    Germany, Munich

Recent Profile Visitors

2429 profile views

cabalistic's Achievements

Advanced Member

Advanced Member (3/5)

938

Reputation

  1. I attempted a fix, but it didn't actually fix the issue, it just made it somewhat less visible. Previously, the AMD shader compiler confused diffuse and normal map lookups, which is very noticeable due to the green/red tint of the normal maps. Now, it confuses diffuse and specular lookups, which is not as obvious, but it's still just as wrong, unfortunately.
  2. Nope. There is no shader branch since 2.09. All shaders expect red-green-encoded input, normal map texture format is either GL_COMPRESSED_RG_RGTC2 or GL_RG8, depending on image_useNormalCompression. So presumably RGB normal maps would have to be converted upon load, though I'm not sure if/where that happens in code. In either case, precompressed textures should be uploaded as they are and not be affected by image_use(Normal)Compression. Edit: actually, no conversion should be needed as long as the RGB textures were normalized, I guess. They just get their B channel cut off, which is then recalculated in the shader.
  3. Less expensive, possibly, but again, it would depend how many pixels actually benefit from the less expensive model and what kind of effort you'd have to take to make the blend between the two not pop out too much. And exactly how much the difference between the lesser and the full model really is. As for rendering fewer pixels in the distance, that's not really possible, because GPUs traditionally don't really work that way. Or rather, it would require a very new feature called variable rate shading that is only supported by RTX and RDNA 2 cards. And only RTX cards support it for OpenGL. Don't think it's worth to implement for those cards alone
  4. No, I would argue that in most instances, steps 8 and 9 (or the alternative GPU operations for shadow maps) are more expensive than the rest, unless perhaps you have a very strong GPU or use a very low rendering resolution. Yes, you might potentially be able to create scenes which are CPU-limited rather than GPU-limited due to poor visportaling or some very particular circumstances, but in the majority of cases that I have seen, GPU time at least matches and usually overtakes CPU time at the moment. Therefore, if we want to find ways to reduce overall frametime that is as generically applicable as possible, then right now we need to find ways that reduce GPU time at least as much as CPU time.
  5. I'm afraid you're not. You are showing a standard scene and just hide a lot of its lights. It's very clear that this gives a performance boost, nobody doubts that. It's just also completely meaningless, because doing so alters the entire scene. And so it becomes a completely different scene and not merely a "performance optimized" scene. As such, it is *not* suitable to determine whether culling lights by distance is an actual usable performance optimization. As I already explained on the Discord, the influence of lights on performance correlates with the amount of pixels it touches, because the most expensive parts of lights are the calculations done in the pixel shader. As such, the amount of tris is not as important, so you are looking at the wrong numbers. However, this is also the issue: when a light is sufficiently negligible to a scene that culling it could actually be an acceptable performance optimization, it will invariably also be touching a lot fewer pixels to begin with. Certainly a lot fewer than in your test scene. And that changes the whole equation, because if it's touching fewer pixels to begin with, it will have less benefit to not render the light. All we are asking here is a demonstration that in a situation where a light is barely noticable (visually), it is still sufficiently impacting performance that implementing a distance-based culling system for lights would be worth the (potentially considerable) development effort.
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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).
  14. Did you enable 64 bit color buffers? Otherwise, there is no difference.
  15. 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.
×
×
  • Create New...