blackrack

LoadDistance and unloadDistance in planetsList file/patch: https://github.com/LGhassen/Scatterer/wiki/PlanetsConfig#planets-list Just multiply it by 10 I guess

They will work, but old versions of the config tool left it up to the user to pick the atmosphere height, instead of matching it to the density scale heights entered. So depending on how the old configs were made, they may work fine or the scale may be completely different. On average I think configs will need to be readjusted. The good news is, readjusting is now much easier.

There won't be a difference in performance, only perhaps if enabling TAA but you can always use SMAA like now.

Giant post ahead So I've been working on a few things. The blending used in scatterer was rather primitive and relied on using the blend operations built-in to blend the results into the background without having to read back the background, this limits what we can do in term of blending to additive and soft-additive and alpha blending. However since the transition to depth buffer mode, and switching away from MSAA we can now use any blending mode we want. Here I manage to get HDR-like blending without applying HDR tonemapping on the background colors (the game's shaders aren't really built for HDR) This improved the colors a bit. I then revisited the config tool, I just wanted to modify it to not rely on compute shaders in the beginning. The config tool contains all the Proland code for generating the atmosphere and baking it into look-up textures, and I haven't touched it pretty much since the first version of Scatterer. As I got into it, I ended up doing a deep dive into the atmosphere code to try and fix some of the issues/artifacts it had. The original code had some imprecision issues at boundaries, often resulting in these concentric circles that get reported often as bugs: This was easy to fix, but a relatively more complex issue is this discontinuity and artifacts that occur around the horizon line: This is a well-known limitation of the precomputed scattering technique that Scatterer uses, to my surprise I found that the new version of Proland doesn't fix this Thankfully, there are smart people out there who propose a better parametrization of the precomputed textures to concentrate detail on the horizon. After some time implementing it and fixing various issues, it works quite well. Notice the clean horizon line in these screenshots: After that I still found several imprecision issues that result in these bands over the horizon whenever the atmosphere starts getting thick, making foggy atmospheres mostly unusable: I was able to track these down as coming from the precomputed extinction having some issues at boundaries. This is also fixes the small band that appears over the horizon and for which I had the "viewdirOffset" workaround. After fixing it I had some fun testing some foggy atmospheres (better click the gfycat link as the preview butchers the quality): https://gfycat.com/lastlavishasiantrumpetfish I also went ahead and simplified the atmosphere generation process, removing variables like Rt and RL, calculating the atmosphere height directly from the parameters you enter, and generating the atmo directly in-game. I'm sure you have seen this video: Now you no longer need to include .half files, they are simply generated on the fly when needed and cached on disk for reuse. Then I decided to try a different tonemap operator, the built-in proland/bruneton tonemapper being a bit washed out. I settled on using the well-known uncharted 2 tonemapping for now, here's how it looks (left: old, right: new) Note that this tonemapping doesn't affect the colors of the background/game, only the colors of the scattering and how it is blended to the background. After all this I still found that Kerbin in map view looked a bit bland, although it improved. Comparing it to RSS it seemed to me that earth textures had a lot more pop and more contrast: After comparing the textures, I decided that Kerbin needed a bit more contrast, and darker oceans, so I added a small configurable shader that modifies the texture in-game, here's how kerbin looks now: I was happy to get a more clear separation between land and sea, and a bit less haze when looking straight down. This should only be needed for stock planets, if you're creating your own planets you're free to create your scaled textures however you want so shouldn't need this, plus it duplicates the texture wasting VRAM. Also, TAA appears to be fixed in 1.12 so will now be enabled by default, looks better in movement than SMAA. Some screenshots: My favourite atmosphere views are probably on Laythe Comparing the same atmo to 5x stronger mie scattering: Different mie asymmetry settings to look more fog-like or more dust-like feel: Thanks everyone for reading and thanks for the support.

If you run scatterer on the integrated preset pretty much a toaster should handle it. You can also remove the planet configs (just delete the entries from the planetslist file).

Not sure what you mean but I think it might be EVE cloud shadows, some screenshots would help.

Sun behind Laythe is just night time. Sun behind Jool is an eclipse and eclipses currently don't affect the water and scattering on terrain so there isn't a fix for now. The terrain is dark here because of EVE eclipses, but it can't "see" the water.

Planetshine is planned after multiple-sun support, it's just a bit more complicated. I protoyped it back in the day but that's only a small part of the work needed, see: https://imgur.com/a/dTxPl

Allow me to demonstrate

Soon ™

This doesn't happen without scatterer? Looks fairly minor as far as issues go anyway.

I think I misunderstood what you were trying to do, I thought you were on 0.0722. Yeah on 0.0632 not sure what you can do exactly. Try reducing the cloudScattering and skyIrradiance values a bit, try changing the altitude of the clouds slightly or you may just have to generate a new atmo. There was just too many gremlins back then and I don't remember all the details.

Glowing clouds? Like on the dark side? Post screenshots and the duna config + the log file.

You have to readjust it, either cloud height or atmosphere height/thickness. I'd hold off on updating atmospheres until the next update is out though.

I've been working on some improvements to the atmosphere generation, I moved the atmosphere generation to be directly in-game instead of through a separate tool, and I fixed various issues with the atmosphere generation, rendering (most notably the horizon discontinuity/line and concentric circles on the planets) and blending. I will post more details soon but for now have some pretty (and foggy) pictures:

Underwater light dimming does not dim vessel's lights, only the sun's light, make a full bug report. Your sunflare textures are missing or the config/path is botched (seems to be the case as it's directly in GameData folder), specifically this file: [LOG 22:55:08.473] [Scatterer][Debug] Custom sunflare cannot be added to @Sun System.IO.FileNotFoundException: Could not find file "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\sunFlare.png" File name: 'C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\sunFlare.png'

The only solution is to disable city lights/textures, they simply can't see the displaced surface, unlike effects in Scatterer they need to apply explicitely to the terrain and not to any opaque surface so they can't just use the depth buffer.

Thanks for the detailed tests. That indeed sounds good performance-wise. I have a few more questions, relating to possibly using the data for visual mods in the future: I checked the api briefly and it seems data for cloud cover can be accessed locally point by point. I guess it isn't possible for now to access a planet-wide coverage map such as the gif in your first post: How much of a hassle would it be to expose a dynamic texture or rendertexture that contains the data for the whole planet at once (with a given workable resolution for graphics purposes say 2k or whatever) and that updates every frame with the correct data (or just exposing the next slice and giving the timestamp for it)? How big is the cloud cover data for a whole year for example and how feasible would it be to stream it in this manner? (Not asking you to add it, just wondering how all the bits fit together). The simulation itself requires a beefy CPU, a significant amount of RAM and significant amount of time to compute. This is fine for the stock planets since we only need to run them once, this would probably block adoption for mods and custom planets though. You mention using a cluster, I assume this means the algorithm parallelizes and scales well with more cores, in theory this could mean we can speed it way up by running it on the GPU instead, but it has to fit in video memory which sounds like a stretch. How much of your machine's 128 GB ram was actually used for the simulation and how much can this be reducd by "trimming the fat", lowering number of layers (eg 32 vertical instead of 55), using half-precision instead of full or double precision, discarding some factors etc? Considering a high-end GPU today has 8-16 GB VRAM, wondering if there is any leeway here.

Thank you, I haven't re-tested this mod since release so that sounds very good. Now that I think about it however, I believe that anything performance intensive shouldn't have anything to do with the calculations you're making, but with adding additional forces to parts and ships, I believe the game's physics engine is where things bottleneck. I assume forces are added to individual parts? With that said, in your performance test I see you're tracking CPU usage but I don't see any mention of framerate beyond the initial capture, I assume both machines are locked at 60 fps the whole time? In that case it may be better to unlock framerate beyond 60 and to compare max framerates directly instead of comparing CPU usage, as that doesn't tell much when performance is limited by a single-thread speed or a framerate cap. Also, the Aeris 3A doesn't have a lot of parts, I think ships with a 100+ and 400+ parts would be better for seeing how the performance scales. From memory I tested a 250-ish parts boat on an i7-3770 (so slower cpu than yours) and saw about a 50% reduction in fps when I enable the mod. I haven't tested the new performance improvements yet though.

Looks gui-related, I wouldn't even look into it unless it directly causes a crash. I believe it's an opengl only issue.

Can you try it with ocean shaders disabled?

It's up to you, I don't make the BoulderCo configs and you can make your own configs with lighter coverage. As for the "invalid name", no idea what that's about, I will check it out next time.

That's just how the BoulderCo config of eve looks from orbit. I can't tell much, can you post a video?

Was thinking about it but the performance hit of this mod was really heavy last time I tried it, and the fact that it's simulation data limits how much artistic control you have over the final result. Was thinking of adding my own simplified weather system instead that both EVE and Scatterer can use. I have a few things planned first though (true eve volumetric clouds and improvements+fixes to scatterer's atmo).

That's just an issue with the atmospheric scattering algorithm scatterer is based on. No fix yet. Disable this option: https://github.com/LGhassen/Scatterer/wiki/GeneralConfig#disabled-scaled-space-ambient-light-disableambientlight