Jump to content
The Dark Mod Forums


Development Role
  • Content Count

  • Joined

  • Last visited

  • Days Won


cabalistic last won the day on May 13

cabalistic had the most liked content!

Community Reputation

519 Legendary

1 Follower

About cabalistic

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location
    Germany, Munich

Recent Profile Visitors

349 profile views
  1. I think "conspicuity" or "conspicuity level" would be the most fitting term (as far as I can judge that as a non-native speaker )
  2. Don't really have an opinion on this - prior to this thread I hadn't even heard of Elbrus I don't see anything problematic in the patch. If it helps, by all means.
  3. I think we'll have to consider shadow maps an ongoing experimental feature. One significant hurdle (in my opinion) is that not all light types are implemented in shadow maps, which means that the engine will fall back to stencil for some lights and thus still generates stencil shadow volumes even when you select shadow maps. So in a way, you currently get the worst of both worlds with shadow maps
  4. Nvidia's SAO isn't really specific to Nvidia cards. All the techniques it uses are in some way also present in the FidelityFX implementation or Intel's ASSAO, those just add a couple additional advanced optimizations Reasons for SAO: it was well documented, had an OpenGL sample implementation, good license, was reasonably simple to implement in a reasonable amount of code (definitely much less than the afore-mentioned ones!) and offers reasonable quality at reasonable performance - not fully state of the art, but also significantly better than some basic implementations that you often find in tutorials (and which I started with in my first attempt)
  5. I've seen it, but there's only an implementation for DX12, and given the sheer size of the shader file, that would be a monumental task to port Also, it's using compute shaders, which we don't (yet) support in the engine. That's also what stopped me from using Intel's ASSAO, which seems conceptually similar, and going for the older, but simpler SAO.
  6. AO exclusively affects ambient lighting - if ambient is weak or overlaps with direct light, you won't see much of an effect. Also, a few missions have some AO already baked into the textures, reducing the difference. If you really want to see SSAO in action, I can recommend William Steele 5
  7. Not exactly a regression, no. Gamma/brightness were completely reimplemented and are no longer changing the desktop/OS gamma, but instead handling it ingame as an image post-processing step. Unfortunately, the consequence is that it no longer affects the menu. In all likelihood we'll remove the popups for this release, as it'll take some effort to make them work with the new implementation.
  8. They don't do anything in the menu, unfortunately, but they should have a clear effect in-game.
  9. Yes. Very likely a compiler optimization bug...
  10. If we enable depth testing and disable the custom depth culling, it looks like this: Unfortunately, while that works fine for this particular particle effect, it makes many others look very ugly (particularly steam). There is no easy and quick solution to this, I'm afraid. At least nothing that could be squeezed into 2.08.
  11. Yes, it's definitely soft particles. They are drawn without depth func always, i.e. ignoring the depth buffer, and then doing their own depth test inside the shader with the depth copy which is not AA -> there's your problem.
  12. No, it looks like it's the soft_particle shader. It's operating with a copy of the depth buffer, so that may well be the problem. Not an easy fix, unfortunately.
  13. @lowenz stgatilov may have found a fix for the SSAO issue, could you confirm if this fixes the issue for you, as well? Please download the attached shader file and put it into your darkmod\glprogs directory (create the glprogs folder if it doesn't exist): ssao.frag.glsl
  14. Thanks! Yeah, that might be a good start. I'll also try to think about what could possibly be going wrong and what else we could test to narrow it down. One thing you might try: in the shader, after the #fidef block from line 80 to 84, you could insert another line 'mipLevel = 1;'. This would force the shader to always look into mip level 1, and you could go through the levels individually to see if there's a specific one that looks obviously wrong, or if they are all bad.
  15. Can you try to play with the random factor in ssao.frag.glsl (line 168, randomPatternRotationAngle) and e.g. modify the factor 3 at the beginning, see if that makes any difference to the pattern (even if it doesn't immediately fix it)? This is one aspect from the original Nvidia implementation that I've had trouble with before. If the patterns are caused by that, we might need to find a different random pattern or even reintroduce a noise texture to get consistent behaviour on all vendors... If that's not it, you can try to change line 74 to 'const int u_maxMipLevel = 0;' as that will disable the most immediate difference between ssao levels 1 and 2/3. If it's not that either, then it's going to be more tricky since I can't reproduce it...
  • Create New...