blackrack

This isn't a conflict and this isn't causing any issues, this is just the mod trying to update objects that don't exist yet or trying to deleted objects that have already been deleted...

You'd need to recompute the precomputed scattering tabels every time which isn't feasible ingame. Barring that, you could modify the postprocessing depth and the exposure settings but I don't think these can accomplish what you're looking for. Thirded

Seems like a very good machine to me, even for things like video editing it should do fine. Congrats!

Sorry, which solution? True, clouds are fine but some of the effects in wip-EVE completely cover up scatterer I guess, I would prefer if it was scatterer only or wip-eve without the sky effects in that case. I'd rather just have scatterer + EVE clouds or otherwise really subtle mods if possible. Try asking BrutalRip, he took those screens.

This is a bit of a personal request, but if anyone has any comparison pics with the mod on/off, or otherwise really good screenshots with scatterer, could you post your albums here or send me a link by personal message? If the existing one fails to read then yeah, the variables will take the init values, and saving happens automatically when you switch scenes so it overwrites your file. With scatterer, it already needs much of the other parts of the mod in it's rendering. Actually I think disabling anti-aliasing gives a pretty good performance boost for the ocean. There maybe some other things also.

That's just variable initialization, that is done before the settings are loaded and shouldn't interfere with it. Do the settings from the original file get loaded first or not? If not there maybe a file access issue. Look for issues in the log. For any respectable medium-range GPU there shouldn't be any performance impact at all (there was none on my desktop 560 Ti) because KSP doesn't really use any GPU power. On my laptop with a gt 740m (and an underpowered i3 ivy bridge @1.8ghz) it went from like 35 fps to 20fps. If you have memory issues it's now safe to switch to OpenGL and save half the memory usage.

Not sure about rescale mods because RSS seems to work fine. If you have any other mods, keep digging. Otherwise wait for a bit, I'm assuming this is related to the moire patterns and the "horizon break" issue and I might have a workaround up soon for these two. Not sure what the problem is, just make another png file with your texture. Tbh I have no idea why you guys are getting this problem now, I didn't even touch the dx9 shader or make any changes to the main plugin code except for adding a small delay function. To better isolate the problem, try downloading the new version and replacing it's scatterer.dll with the one from two weeks ago. Then do the same but instead of the .dll file do it with .shader files, tell me which one fixes it. I don't have any lying around now but have this instead. Note that I haven't done any additional work on the water and that it still has the same problems and isn't ready for release but far from it. Awesome plane (or bird) design by avera9eJoe

I've just put back a working link for the config tool, have fun.

It's next on my list, NathanKell told me recently that RSS actually changes only the CelestialBody's name to Earth and keeps the scaledSpace Object and the gameObject's names to Kerbin. Is this a special situation for Kerbin/Earth or does it also happen with the other planets? (I'm assuming it's the former). Also, yeah, there still seems like there is a small difference somewhere but I can't quite put my finger on it, both OpenGL and dx now look good enough though, and I might have a temporary fix for the horizon break thing.

Are you getting any issues other than the "break" in the haze you can see on the horizon?

What would be a good key combination for everyone? Alt+S? Sorry about the config tool, I may have messed up, I'll put it back up later.

I was actually thinking about doing a simpler approach with a multiplicative blending layer or something, I sent you a message asking about possible custom blend modes and if that fails doing a grabpass (might be performance intensive) and basically nullifying or lowering values below a set threshold. Both this and the moire patterns have something to do with the depth buffer, I already added it in the "known issues of newest version" section and will try to fix it soon.

No idea for now, I thought I fixed this on OpenGL.

Platform and renderer? Tested without any other mods? I pretty much can't think of any reasons other than conflicting mods because it's seems to be working fine for me and everyone else.

Well that made a dramatic difference. Looks like I'll be looking into the least performance intensive way to implement this soon. That actually seems like a huge difference to me. Also, imagine a modded gas giant with huge rings seen going vertically in the sky of one of it's moons.

This already looks much more realistic. Did you only remove the dark side or did boost the brightness of the other side as well?

No worries, it's something I was working on anyway as it's not very realistic currently. Also working on better eclipses but this might interfere with it. Just to get a quick idea, could someone photoshop Red's first image to show only the bright side of the mun? Can't do it myself for now.

If I'm not mistaken that's wip-eve default config.

It seems to me the dark side of the Mun shouldn't be visible in these conditions. I'm not sure if this is a bug, per se, or just a setting that can be adjusted. So far in all other ways the default settings seem very good (i.e. beautiful ). Well, it seems brighter than on my stock install for some reason, also, first pic seems more or less alright while second pic it doesn't even look like there's any blue on it. Anyway, I already have a way of dimming the mun and other celestial objects that I haven't released yet (and they get progressively dimmer the more they approach the horizon, you can see it on the previous Laythe/Jool screens that I posted a few pages back) so that may very well fix this but I'm not sure if I can make the dark side completely invisible as I don't want to turn this into a post-processing effect for various reasons.

Do you mean it's drawing in front of the atmosphere or it's just too bright? What about without any other mods? Post screen if possible.

I didn't say anything about this bug being fixed (it's not OpenGL-specific), also, it's still in the "Known issues of newest version" section of the OP, please check before posting.

Yeah, I will get it working as soon as possible. Cool, reference material!

For people who use OpenGL, does antialiasing just not work? Do I have to force it through the drivers?

So I just fixed the main OpenGL problems (rainbow colors, lines in the sky, moire patterns (also appears to be fixed in dx11)), OpenGL now runs and looks beautiful (at least on my machine, hope it runs just as well on Mac and Linux). Note this is just an OpenGL update, I won't be releasing multiplanets at this time as it's not ready yet. I'll be uploading a new build to Kerbalstuff in a few minutes. Have fun. Edited: There may be some new horizon artifacts around the ocean I will try to look into soon but they're nowhere near as bad as the old problems.

Yup, it is. Edited: So I just got rid of all the remaining OpenGL issues (wrong colors, artifacts, lines in the sky) but now some moire patterns started appearing over the ocean, just like in dx11