blackrack

This issue has been fixed since v0.052, what version of the mod and KSP are you running?

It is in the works, I won't say more for now

@Xein That's not Duna. I don't remember which planet it is, but it's from a planet pack, and the author posted it a while back to show the differences with the setting on and off. I thought it was neat and shows the setting well so I saved it. Maybe someone here will recognize it.

The current version seems stable, I'm releasing it for 1.8, it's currently uploading on SpaceDock, I'll stick around to fix any issues. Enjoy. Also, I have to say the new terrain shaders and Unity update look great, can't wait to see if there are any new Unity features I can take advantage of.

Looks normal

Check if there isn't already an issue, but yes, you can.

I made a pre-release for the 1.8 version, I didn't test too much in depth yet, but it seems to be working. https://github.com/LGhassen/Scatterer/releases/tag/0.0541 Please try it out, I will finish testing and fixing any issues. I plan to include multiple stars, with colors. haven't thought of including intensity curves but a fixed intensity value per affected atmosphere, as I don't intend for the effects to be fully dynamic but manually configured. Well, as a first step I was planning to replace the PQS shaders and try to do some trickery with parallax mapping that would be procedurally generated and make the terrain look more detailed than it is. The new shaders introduced in 1.8 seem to do more or less what I had in mind. Later on, I would like to explore implementing my own terrain system (ie replace the PQS system with a custom terrain system), but not sure I'll ever have the time to do something so ambitious This is a limitation in how scatterer handles planets with a tiny radius and a (relatively) high atmo. No fix/workaround for now. Hmm, could you open an issue on github? I'll look into the cube mapped textures. Could you open an issue on github? I will look into fixing it. I ahven't maintained it in a while, it's possible something broke. I tried to do this before, let's say I ran into limitations and the wave bobbing was guaranteed to summon the kraken every time, in addition to tanking performance. The far clip plane will always be an issue. I was thinking about using the height map to affect the scaled Space rendering for a while, open an issue on github, I will look into it, though not sure it would work. I assume here that the earth scaled space model is a perfect sphere? Otherwise if you can have detail on the scaledSpace object, the scaledSpace shading will match it, provided the option "flatScaledSpaceModel = false" is set for that planet. i might be remembering this wrong, but I thought that the stock scaledSpace system could add detail from the heightmap. Anyway, here's how shading looks with the option flatScaledSpaceModel set to true (left) and to false (right).

Thank you. I appreciate your efforts and would welcome any pull requests, provided the issues are fixed correctly

Hi everyone, I was kind of busy lately, didn't even know 1.8 was out. A co-worker informed today an update is out. I still plan to update scatterer to the latest version and support/improve it, so be patient.

If you can manage to reproduce it on a save file using stock ships, and pass me the save file then I can look into, otherwise this doesn't give me much to go on and is going to be too time-consuming to reproduce. The white caps where never gone, but somehow I've had some reports from SVE a while back that they disappeared. Do you still get them with the stock scatterer config if you increase the settings like wind speed etc? There is no offset parameter, sounds like you are playing with a multi-star system, potentially the scale of which is breaking something. Do a full bug report please, including mods scale etc. What is UBI? I can't reproduce this with the default scatterer config. I'm curious if you have any mods changing anything, or if this happens in a specific condition or sunflare, please be more detailed, I really don't have this with the stock scatterer config. And btw @Gameslinx I'm still waiting for your zip/report on the scatterer effect killing performance with the custom terrain scatters.

Exactly. But before that fix trees rendered "behind" the scattering which looked wrong, after that fix they had their own correct scattering. Now they render "in front" with no scattering.

Yes, trees are ignored on purpose to preserve performance. I guess I can always add an option for them (at a performance hit) I'm not supporting 1.3.1, if this bug isn't on the latest version of KSP then i'm not going to look into it. I would have to look into it, is it still there when you disable EVE cloud integration? As you can see here: https://forum.kerbalspaceprogram.com/index.php?/topic/103963-wip161-scatterer-atmospheric-scattering-v00540-17032019-fixed-tsunami-bug-11/&do=findComment&comment=3598962I have disabled effects on trees to save some performance, maybe I included trees but not the rest of the scatters. If you can include a screenshot of terrain scatters clearly showing the scatterer effects on them I promise to fix it (move the camera out far enough to show the effect then narrow your fov/zoom in so it's clearly visible on the scatters). Yes, you are right on this, since I moved away from using the depth buffer (it has ugly aliasing around objects), the approach used is basically rendering opaque objects twice. I made sure to disable it on the cutout-style trees, if you make a detailed report as above I can disable it on the rest. Typically I would expect the bulk of the performance hit to be coming not from additional strain on the GPU but mostly from a lot more draw calls. These comments are completely unusable for me, if you're not willing to play around with settings and narrow it down I can't help you. Same as above. Known issue, the stock code for moving parts and cargo bays messes with the projectors, I haven't found the cause yet. Fixed with scatterer ocean, with stock ocean it isn't working very well, try forcing d3d11, it handles z-fighting better. Same as above. More details? possible video report?

Alright everyone, so as @Phineas Freak said this is an issue with the camera's far clip plane. Now, why do we still see the planet but not the scatterer effect after the limit distance you ask? It's simple, you are seeing the scaledSpace planet. Due to blending considerations, scatterer will apply the effect either in local or scaled but not the two at the same time, so when the clip plane of the local camera "eats" the local scenery, it eats the scatterer effect with it. To fix this, there are 2 solutions: 1) As proposed by @Phineas Freak here, we can increase the far clip plane. This is a good solution but also has a downside.. You see when we increase the gap between far and clip plane we "spread" the depth buffer precision even further resulting in potentially more z-fighting artifacts and blurrier shadows. 2) A second solution is to simply deactivate the PQS and switch to scaledSpace before reaching the altitude where we reach the far clip plane limitations. The issue with this is that we switch to scaledSpace sooner and so, we have less details to look at, at low altitude. Here is a MM Kopernicus patch I made (very quickly) to switch to scaledSpace earlier, I tested this on 6.4x rescale and it seems to be fine, although the transition could be worked on: @Kopernicus:FINAL:NEEDS[Kopernicus] { @Body[Kerbin] { @PQS { fadeStart = 40000 fadeEnd = 50000 deactivateAltitude = 50000 } @ScaledVersion { fadeStart = 40000 fadeEnd = 50000 } } } On 3.2x rescale the values probably don't need to be as extreme. You could probably get away with switching around 110km They are completely unrelated so scatterer doesn't take it into account. I could either implement a miminum value or try to use the existing brightnessCurve.

I can see it now, I was on my phone earlier and it darkens everything. Can you try with flatScaledSpaceModel=true in the planetsList?

Sorry, what is the exact issue here with the extinction?