-
Posts
2,533 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by blackrack
-
I see. Can anyone confirm it still works? Also can you confirm the setting isn't needed for scatterer itself anymore but useful outside? That way I can split it off into a separate mode and add options like build only, build+flight Please make a full issue report, look in the OP for how to report issues.
-
I'm guessing you are using a visual pack but a different scatterer version than the one for that pack, and so, the config is broken. This isn't something that scatterer does, you're supposed to see through the atmosphere. Unless you modified some of the sky extinction values, try with a stock install + stock scatterer to see if the issue goes away? I'm aware of this issue but I haven't really investigated it. If you find a workaround let me know. Read here: https://pro.arcgis.com/en/pro-app/help/mapping/properties/adjust-view-clipping-in-scenes.htm Overriding the near clip place allows the camera to get closer to objects without them appearing to be "sliced" but may negatively affect depth buffer precision and shadows precision (may cause flicker issues, z-fighting etc...). The setting isn't really needed for scatterer anymore, but typically builders still use this setting to get the camera closer to what they're building in the VAB/SPH, I may make it a separate mod that only works in these scenes. You'll have to take this to the RSS thread. Also, new cover art: Which is a quick photoshop job of the painting "wanderer above the sea of fog" but I'm happy with how it came out
-
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).
-
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.
-
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.