blackrack

Yes, I edited my post just now but I believe you didn't see it, for local space there are two cameras in KSP, one for rendering very near objects and the other for farther away stuff, atmospheric effects are only applied to the far camera since it only makes sense there, and that is why that issue only appears when zoomed out.

For the first image, that's shadow acne, only fix is to turn up your shadow quality (by turning up the KSP rendering quality slider). For the second one see below. These are limitations of the current godrays method that I'm still trying to get around. I explained them somewhat in depth here: http://forum.kerbalspaceprogram.com/index.php?/topic/103963-wip-scatterer-atmospheric-scattering-v00230-24022016-godrays-and-eclipses-preview/&do=findComment&comment=2417617 No fix for now but to disable godrays. It's also why the godrays are off by default and it says early WIP. Also, I believe the issue with the re-entry effects is fixed. The issue doesn't appear when it crosses the horizon like you said but rather when the craft moves out of the near clipping camera and into the far clipping camera (where all atmosphere effects are applied).

Indeed, I changed and refined the blending mode, the scattering no longer eclipses the original color of the terrain.

Wait, the alt-tab bug is back? Does it also happen with godrays off? Thanks. Glad you're enjoying this, glorious album btw.

New version is uploading. RSS seems to have pretty bad z-fighting so you might want to avoid this version if you're on RSS until I get it fixed. Godrays are disabled by default but can be enabled from the main menu. Eclipses (sky and orbit only), custom lens flare shader and terrain shadows are also included. Full changelog is in the OP. Have fun.

Which version of scatterer are you on? Edited: try this file: https://mega.nz/#!qEhECLYB!7lW3Uy1-HVzMz0Xf6RjHpQ9v46wvh4fBy3qIl8xEd2s

Well, the transparency could be worked around. The issue is that they render as screen-facing quads (I think) which I can't work with, now if you'd render them as spheres that'd work but also make them kill the performance (probably). I still have some things to figure out then I'll probably make a public release of some sort.

Don't really know how to fix that one. That would be asking too much.

@rbray89 This paper more or less describes your idea for adapting the godrays to the cloud shadows and for getting around that issue with the gaps, and also more or less my idea for additive blending and using backfaces and frontfaces: http://www.cse.chalmers.se/~uffe/volumetricshadows.pdf It will be ready Soon (TM)

Yes and yes, although I checked on mun and it was quite underwhelming still.

The most important information is in that 16 mb .raw file. You have to generate a new one with the config tool in the OP (a wise man once said "ah the OP, what wonders it holds") when you're done copy the files and the settings as instructed in the OP. You don't have to make the radius match that of the planet, it'll be rescaled automatically when you load the mod. Also the format has changed and I haven't updated the config tool, the mod no longer uses the xml format, just open the xml format and copy the settings manually to settings.cfg

Next version is looking quite good And some webms: https://gfycat.com/LightGrandAmericanmarten http://gfycat.com/SecondaryHandyCattle https://gfycat.com/WaryKeenHylaeosaurus https://gfycat.com/HiddenUnconsciousAfricanmolesnake

I would say that isn't really necessary, as long as we can get the distance that is lit correctly, we can do the blending directly depending on this length and the results of the scattering. Btw I switched the shader from alpha blending to soft-additive (1-dstcolor, 1), coupled with a multiplicative atmospheric extinction pass before-hand, like with the orbit shader, I think it gives softer and less foggier results and lets more of the original color shine through, but looks thicker around sunrises/mornings and sunsets, because of dimmer dscolor.

I didn't actually, it's just not too bad when you crank the terrain quality up. And i also thought the blur pass would help with the small gaps. It's still most noticeable when you look at the mountains near KSC from the launchpad and it looks pretty bad. I thought about the extruded mesh more, and actually it's a real issue what to do with vertexes that aren't over anything. With the ocean it's easier, you can use a mathematic formula to tell you where the horizon line lies and just drag all vertexes over the horizon line back to the horizon and it just works. I still don't understand how you plane to use the alpha value here.

Wait, I'm not sure whether you mean using this for "how transparent a cloud is", and making a godray equally transparent, or to compute the total length of lit distance. Btw I actually just noticed there are some directions in the Proland paper on how to handle godrays, I just ignored them before as I couldn't understand anything at the time except they used geometry extrusion.

Indeed, it's one of the reasons I picked it!

How would you get that value? Edited: Btw I think if we add all the distances to the backfaces and and substract all the distances to the front faces it should work.

Could you post some screens? Sounds like something went wrong. Btw I fixed having to set the map view scale manually, will release it in next update. This would work, I guess you'll have to set some kind of threshold though. Also, I have to talk about the current limitations of the method so maybe we could think of solutions, and also because they would be more obvious with clouds. I'll explain with some images as it's easier to get the point across, and also for everyone else who happens to read the thread: So basically when I do the scattering I get the scene depth from the depth buffer and compute the amount of scattering based on optical depth, assuming the whole segment is receiving light, pretty straightforward. Now when I want to render a godray, I have to get only the length of the lit section. For this I extrude the geometry edge along the direction of the light and write it to the depth buffer. This works nicely when looking straight into terrain and along the direction of the sun. However, say we are looking sideways from a sun, and a mountain in the distance is projecting a godray, we need the length of the two lit sections, the current method only returns the length of the first lit section. In practice this results in it looking like this, where everything behind a godray looks like it's in shadowa dn the transition is harsh. To get around this I though I'd render the depth of the backfaces separately and then using the depth of the frontface minus that of the backface I'd get the length of the unlit section, which I'd then substract from the total length, returned by the regular depth buffer. This should work nicely but I haven't tried it yet. And usually with terrain the viewing angles are limited enough that one godray+scattering in the background would look believable in the majority of views. However with clouds it gets really complicated, we now have an arbitrary number of godrays. This is what I'm thinking about now, how to get the lengths of all the lit or unlit sections. Hope this is clear for everyone. First idea that comes to mind is maybe we could do some sort of additive blending when we write the godray depths and then the same on the backfaces to get the total length or something. And also, the depth values aren't linear, which further complicates this.

It's a 7-zip file, download 7-zip (it's free, fast and handles all the common compression formats) or wait a few seconds, I'm currently uploading to spacedock. Edited: up on spacedock http://spacedock.info/mod/141/scatterer Edited again: Hmm, turns out the default shadow system can be used to make the terrain generate shadows, this complements the godrays nicely. Postprocessing disabled so you can see the shadows:

I still haven't received my spacedock email. Could you do something? Edited: nvm, seems I can login now without confirmation.

I think you're the first one to notice.

I wouldn't think it does but you're welcome to try. Last time someone had this it went away by switching to dx11.

Something is disabling mipmaps, try a different video mode (dx11, opengl), different KSP graphics settings and check your driver settings for anything that might be affecting mipmaps.

Not yet, I found a fast gaussian blur shader I'll try soon though. That is one of the good screenshots that don't show any issues Alright thanks a lot. Probably will never be "released" as the method has inherent limitations, but I'll try to have a test version out soon along with all the new features and changes. A lot has changed under the hood and most new features are only halfway there but I will need some public testing and feedback.

I'll just leave this here Could you please check if this happens on procedurally generated planets also? I noticed that some features are only enabled on planets manually created, for example, only Saturn's rings look different when seen from behind (not sure what the effect is called but it has something to do with transparency and the thickness of the rings).