blackrack

Members
  • Content Count

    1,791
  • Joined

  • Last visited

Community Reputation

3,305 Excellent

About blackrack

  • Rank
    Junior Rocket Scientist

Recent Profile Visitors

9,678 profile views
  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. I can see it now, I was on my phone earlier and it darkens everything. Can you try with flatScaledSpaceModel=true in the planetsList?
  6. Thank you. Did you change scenes after disabling the flare? Does it override the stock sunflare as well? Try both then open an issue on github.
  7. If I remember correctly you can remove the internal spaces from the list. Not sure what you mean about the haze, as it hasn't changed since previous releases.
  8. From your log It looks like you are loading something with them pre-activated, or something is activating them. Anyway, maybe try to test if you get the white sky while avoiding to use this part?
  9. @Gameslinx Were you playing with the new mk2 lander can doors when this happenned? It seems there is a big bug when activating them that kills most of the scatterer effects. I will investigate... It seems that this DragCubeSystem starts removing my commandbuffers and scripts from the cameras when the door in mk2 lander can is activated.
  10. Upon closer inspection of your log file, I see this error [LOG 10:21:40.599] [Scatterer] Multiple config files detected, check your install I see you have these config files [LOG 10:21:48.346] Config(Scatterer_config) scatterer/config/config/Scatterer_config [LOG 10:21:48.341] Config(Scatterer_config) BeyondHome/scatterer/config/config/Scatterer_config Shouldn't you have only one or the other? Shouldn't you have a ModuleManager patch overriding the stock one if that's what you want for your mod? Try deleting one of them. Although I'm not sure this is the cause, there were times before were people with duplicate installs had white sky, worth a try. Can you retest with the previous .dll also, this would be weird as the fix is still there in the new version. That's probably because it's from the days before the new parts. Search for their *.mu files in the Squad folder and add their paths in the ModuleManager patch you are using.
  11. 8x ingame, no AA settings in scatterer. When I said that scatterer supports AA it means there is no longer aliasing when AA is active, in previous versions there was. It works on dx9, dx11, OpenGL and GLcore. The answer is one post above you.
  12. Uploading a new release. Changelog: -Fix refraction/transparency artifacts in the ocean at altitude (swirly appearance) -Fix unnaturally bright scattering on the ocean and a small pop while transitioning to orbit -Fix white sky bug in some situations -Add trailing zero in version number for CKAN Should be up in a few minutes