Jump to content

blackrack

Members
  • Posts

    2,533
  • Joined

  • Last visited

Everything posted by blackrack

  1. Ah yeah, that's no longer the case so I will change it. What exactly does "indexing it as an adoption" mean?
  2. Just replace the "EnvironmentalVisualEnhancements" folder. This uses the same configs as regular EVE so you don't need to replace those.
  3. Hey guys, so if you've been following the scatterer thread, you know that I've recently found some solutions for depth precision issues: https://forum.kerbalspaceprogram.com/index.php?/topic/103963-wip19x-110x-111x-scatterer-atmospheric-scattering-v00723-31122020/&do=findComment&comment=3908432 It's now time to use the same solution in EVE-Redux. In the last release cloud shadows suffer from some precision issues in the distance, which you can see in the weird patterns in this image: You can also see that they're no longer visible in the distance, this was my current work around to hide the precision issues where they intensify. Using the depth precision fix: With this I've also fixed this bug https://forum.kerbalspaceprogram.com/index.php?/topic/196411-110x-eve-redux-performance-enhanced-eve-build-v11111-26082020/&do=findComment&comment=3853706 Additionally, I went ahead and modified the eclipse shading to have the same soft shading as scatterer (left is last release, right is new version): Those are pretty much the "last pieces of the puzzle" that were missing. So with that said, I will be maintaining EVE moving forward, and @R-T-B and @BIOZ can always contribute. I'm going to go ahead now to add this on spacedock and CKAN. I really have no idea what's going on here, but it sounds like you simply deleted the cloud configs, probably by adding a ModuleManager patch which overrides them or deletes the existing nodes. I would say to check the land textures and the configs that you added for any deletion they might be doing.
  4. I tested KWP when it was first released and didn't have this issue. At first glance it looks something is wrong with the KWP .dll, maybe a corrupted file? I'm not sure what would cause reflection to throw an exception when simply checking the type.
  5. Clouds now receive lighting correctly based on their altitude. The higher the clouds are, the more light can still reach them (they will not be in the shadow of the planet) so the terminator will appear to move back. In previous releases I had fudged it so that clouds just behaved as if they were at sea level, to make it easier to get those colored terminators, but that doesn't cover all use cases and types of clouds, and resulted in some issues.
  6. Why would you commit such a thing? In all seriousness, It's likely that the bug was always there but was less visible on the old, flatter wave config. Can you try setting AMP to 1 and wind speed to 5 in the new version and see if that fixes it?
  7. I wanted to mess around today with HDR rendering and tonemapping after playing with a certain cosmos simulator. As you may or may not know, the scattering shaders produces colors in high dynamic range, which I then tonemap separately and add to the scene with blending functions that attempt to "emulate" HDR by giving them a soft look. Results are okay but often produce faded or bleached colors that differ quite a bit from the original color. When using HDR or tonemapping through other post-processing mods, scatterer still does this simplified blending, so the results aren't as good as they could be. True HDR is not supported in Unity when using MSAA, however since I'm ditching that with the new depth buffer approach, I decided to give it another try. I explored the topic a bit before and the results were always inconclusive. This is still the case, it looks a bit off, the contrast looks a bit weird and I can't put my finger on what exactly is wrong. However I noticed some small improvements and wanted to share with you these screenshots and see what you think about them: Left is regular, right with HDR and tonemapping. HDR one looks softer and slightly more balanced somehow but not a big difference overall Colors and gradients on the godrays look more natural here, notice the soft runway lights also The blue color of the atmosphere seems better preserved, the contrast looks unnaturally strong though
  8. For now you could disable long-distance shadows, godrays and ocean surface shadows. Or just wait for next version which will improve performance a bit and come with quality presets.
  9. In my experience this happens when the paths to the .half files are wrong or the files are missing. So yeah a reinstall/cleanup is needed.
  10. This is off-topic guys so please take this elsewhere. Yeah, wave interactions are a new feature. You can disable it from the KSC options menu, or lower the wind speed fom kerbin's ocean config (in the scatterer folder). For scatterer there shouldn't be a difference on the performance you get anywhere. I'm guessing you have EVE and the default BoulderCo with it's 4 layers of clouds on eve? File is not public
  11. It sounds like you hit the refresh rate cap without godrays, at which point the GPU proceeds to "idle" for the remaining 10%, but once you enable godrays the GPU tops out and you're unable to hit the refresh rate. That's just it, the GPU is doing a bit more work. I'm not seeing exactly why you are reporting this? Anyway, I always say that if you're not hitting 100% GPU usage you overpaid. CPU wise it's true that's only 30% but that's actually close to topping out because KSP doesn't use more than 2 cores, and that's on Directx11.
  12. Yes, graphical features use GPU. Your GPU will hit 100% as long as you don't hit your refresh rate/framerate cap or your game doesn't hit a CPU bottleneck. Also that graph is not really useful without associated framerates or CPU usage.
  13. Thank you guys Hmm well now that I think about it that sounds about normal with those mods. All I can suggest is lowering the settings for both Scatterer and Parallax a bit, and switch to EVE-Redux if you are using EVE, also lower the settings for the stock reflection probe. If I remember correctly, BH uses the previous version of Parallax, which has improved in performance since, and the next version of Scatterer will give a performance bump as well (see above post).
  14. So, I’ve been working on some performance and rendering improvements. If you remember earlier versions of Scatterer, they used used the depth buffer to apply the main scattering effect. This was a big source of issues, low depth-precision, no anti-aliasing support, depth artifacts etc… Let me just jog your memory with this one image: A few versions back I switched to using a “projector” and got rid of the depth buffer. It’s essentially just a way to re-render all opaque objects in the scene with a different shader, in this case, the scattering shader. This fixes aliasing and depth related issues, but it is wasteful of CPU and GPU power (re-rendering opaque objects is expensive, this was one of the things I fixed in EVE-redux that boost performance) and couldn’t handle special cases, like terrain scatters/trees and Parallax displaced terrain causing them to not have scattering on them or only partly: While trying to fix these issues, I decided to re-visit the depth buffer approach as it doesn't have those issues and could help improve performance. First attempt using the depth buffer came out as broken as expected: I won’t get too deep into the technical details but there is two main methods to reconstruct the world position from the depth buffer and both have issues with large distances. If you’ve ever seen this issue in EVE-Redux: This is the same issue. I work around it in EVE-Redux by fading out shadows in the distance, but this can’t really be done here. At first I thought it must be the depth buffer precision that just sucks, as it always has. But how could this be? Unity switched to reverse-Z buffer recently which is renowned for good precision, and used in pretty much every large open-world or planetary rendering engine. I decided to take a closer look at the depth buffer, and it looked completely fine, precision looked good, so the position reconstruction methods must be flawed somehow. Initially I came up with two over-engineered reconstruction methods, one involving an iterative search, and the other involving emulated double precision in the lossy operations. One of these worked very well (I’ll let you guess which one). However I later thought of just combining the two original methods from above, simply using one to get the direction and the second for the distance. This ended up working perfectly and being very simple and cheap. So now we have precise positions reconstructed from depth, this means that the main scattering shader will get much cheaper, and won’t have to re-render god knows how many objects, reducing both CPU and GPU usage. Added bonus is it now works with Parallax and the terrain scatters so they get correct scattering as long as they write correctly to depth: It also gets rid of these z-fighting artifacts which sometimes appear in the distance with the current method: Tested it with RSS and Rescale and it seems to hold up as well. For long-distance shadows also there is the partial depth buffer which I was rendering to cover the areas where depth reconstruction precision of the old method degraded for shadows, though in practice that was relatively fast, we can get rid of it now as well. This method can also be used in EVE-Redux as well so cloud shadows can cover the whole scene and not just ~5 km around the camera. Another advantage is that we can now use the same method as EVE-Redux’s volumetrics: Render the scattering effect at ¼ the screen resolution for performance. On the left is is how it is really rendered at low resolution, on the right is the final result after doing depth-aware upsampling and compositing with the rest of the effects: This approach (1/4 resolution scattering) is however incompatible with godrays (at least for now), so it will auto-disable when using godrays, I’d also argue that if you can afford godrays you probably won’t need this. Now there remains the issue that the depth buffer can’t be anti-aliased, while the main scene does, resulting in these lines around the scattering effect if AA is used: Unity doesn’t expose a multi-sampled depth buffer, and while I managed to find a way to force it to render to one, and to resolve it manually in my shader, this pretty much broke other mods that use depth effects or image effects. The only other solution available was to disable hardware MSAA and use a post-processing AA. If you care about MSAA though don’t worry, depth-buffer mode can be disabled and you can keep the old MSAA-friendly mode, though that means giving up on the performance and compatibility improvements. So, my first choice was to go with temporal Anti-aliasing. TAA is pretty good these days, in some cases better than MSAA because it offers temporal stability which MSAA does not. I got it working pretty well and was happy with how it looked, however due to a bug in unity when setting custom projection matrices (which TAA needs for slightly offsetting temporal samples) with a high far/near ratio such as in KSP, shadows flicker from some angles: So that makes TAA not really usable, until Unity fixes this at least, though I will keep the option available for those who want to try it anyway. My second choice was Subpixel Morphological Anti-Aliasing (SMAA). It is quite good and has different quality levels, in some regards it is better than TAA, and in every regard better than FXAA as it never blurs over details or textures. Overall I feel it looks very similar to 2x MSAA, which is mostly sufficient if you play at high resolution. Here are two screens, one using the new method with SMAA, and one using the old method with 2xMSAA, can you tell which is which? The second one is SMAA, and in this particular instance the SMAA image looks cleaner: May be it would be better compared with 4xMSAA, though it varies a bit in motion. An added bonus is that it also fixes the aliasing that the volumetrics of EVE-Redux introduce around crafts (if you’ve ever noticed that). So now we can put it all together and see how it runs. Let’s test something really low-end, here we have a weakly i3-3217U @1.8 Ghz and and its integrated HD graphics 4000, this is an old laptop, and it struggles just loading up KSP. Though it has a gt 740m (which is a bit faster but still slow) I'm going to test it on the integrated graphics. Testing with just the scattering shader + sunlight extinction (which isn’t expensive), everything else disabled. Stock terrain at low. Running at 720p with no AA (because let’s be honest here we can’t afford much with integrated), running with these settings (hard shadows and all): Stock gets ~30 fps with these settings, so we’re off to a bad start. Previous release of scatterer gets 23 fps New version gets ~24 fps (though I forgot SMAA enabled here but it barely removes 0.5-1 fps) That's barely an improvement over last version. However now we can enable 1/4 res scattering and get 27 fps, that's already much closer to stock's 30 fps, and a 17% improvement over last version. So there you have it, much closer performance to stock on the low-end settings. Alright now something faster On a GTX 1080 at 1440p and everything enabled, we go from 85 fps to 108 fps on the ocean surface with no AA, a 27% improvement 84 fps to 102 fps when zoomed out, a 21% improvement And although it’s not a completely fair comparison, let’s look at 2x MSAA on the old version, and SMAA on the new one: 75 fps to 106 fps, a 41% improvement. MSAA is expensive Oh and also, I tested with OpenGL on my main PC and it went from 35 fps to 64 fps (makes sense since this frees up some CPU overhead as well and OpenGL KSP is running on a single core for some reason), but I didn't take screens so the two guys playing on OpenGL will just have to try it for themselves :p Now with all these new settings, it can become complicated to pick and tune your settings, so I’ve added the ability to load quality presets from config files: I defined a few logical presets, each one tries to aim for the best quality/performance ratio, in increasing quality. The mod will default to “Low” from now on, which is just the ocean (with transparency and foam), the scattering at 1/4 res, and the non-expensive effects. Feel free to pick the preset that suits you best from the UI, you can go lower or higher, and a restart is no longer needed when changing some settings like ocean or terrain shadows. A few effects like long-distance shadows might be completely fine with stock but scale badly with with other mods, so keep that in mind. Thank you for everyone who read this wall of text, I still have a few things to fix/test but I will be posting a build on Patreon soon, and making a public release as soon as this is all polished and ready Check the links in the OP, there is a section about the Config Tool you can use to export atmosphere files, and the rest is in the wiki.
  15. You can't disable one and keep the other, unless you want parts to stop casting regular shadows too, besides parts don't really add much performance hit to the godrays, the bulk of the hit comes from the shadows and the godrays covering 50km distance. And godrays are somewhat less expensive than the ocean. Anyway, I'm a bit skeptical about your performance figures, you claim that scatterer takes the performance from 70 fps to 25 on a GTX 1060 3gb. I had the exact same card (in fact I still have it, but a friend lent me his old 1080 which I'm using for now) and it ran much better. What resolution are you running? Can you test scatterer alone with no other mods?
  16. These are godrays and the shadow of the planet can appear that way due to the way shadowmaps work. You can just disable godrays if this bothers you.
  17. You can make a bug report too, I haven't yet decided what to do with those other parts though, so I haven't updated the source yet.
×
×
  • Create New...