Waz

Bingo! I tried a few things, but never thought to suspect ResearchBodies (which I've only tried playing with once before).

I don't remember Kerbin being this glossy: Any clues if this is an SVT or Kopernicus issue, or something else? Looks to me like the glossiness is inverted (I'd expect the ocean to be glossy, not the land), as if that shaders have swapped from smoothness to roughness.

DDS can store images compressed (DXT) or uncompressed and EVE/KSP/Unity will load them as that. PNG files have to be loaded uncompressed, and AFAIK KSP does not compress the result (it could, with Texture2D.Compress). There is nothing in particular I did when porting that would have reduced performance - I mostly just fixed compilation problems. If there was a perf drop, it could be from KSP's port to Unity 5, some other change in KSP 1.2, or of course from something I missed or messed up.

I suspect you're pushing it well beyond intentions - volumetric layers are extremely expensive, and really need to be faded out to plain textures at some point well before entire orbits. Even if you get it working, most people will just scream at you (and then me) for how poorly it performs.

Very cool! The setting you're after is layerVolume.particleMaterial._InvFade, but this means they'll "pop" in and out, unless you make the layerVolume.area.x quite large. I've often wished Kopernicus could make asteroids via "ground" scatters.

Weird. So you only saw it work once? Does the BoulderCo config also give that problem for you? Kerbin and Jool should both show animation.

What do you mean by crank it down? In the config (or by the EVE button at KSC scene), you can remove stuff. Note that in lower detailDistance does nothing (it just changes are what distance which textures are used) and setting various things to 0 does nothing (it just means your GPU paints more transparent pixels). The most expensive thing is layerVolume, and in particular the second parameter of "area", which controls the number of subdivisions.

Do you mean that quitting KSP and restarting gives different results than the first run, or do you mean that after running KSP it works, but then after some actions in KSP it stops working?

Sorry, a joke at your expense on the difficulty of deleting files. Just move the cityLights.cfg file from GameData/BoulderCo/CityLights/ to somewhere else (or delete it).

If you mean because EVE default city lights look kinda sucky, I recommend the SVE citylights - way nicer and more realistic. Alternatively, I've installed a mod file on your computer called "cityLights.cfg" - if you move that file to your Documents directory, it will enable Clouds-only mode in EVE. :-)

Try this out and tell me what you think: https://1drv.ms/u/s!Ah0aNuGsTYhahGKPEtIKsGALK4Fb It's a build of EVE that uses realtime ("Universal Time") in the shaders. I've only done basic testing, but it should work. UVNoise animation should work for 2D clouds and their shadows (it has never been enabled for volumetric clouds).

Does it go away if you set UVnoise strength to 0? If so, try a value that is a simpler fraction, especially one that is a negative power of two.

I certainly haven't changed anything about how textures are mapped. Are you sure anything has changed - how long ago did you use it? I do know that there are multiple texture mapping techniques available, so probably one of them is whatever you are used to from the past, the others are just in addition to that.

In terms of implementation, UVnoise takes the lowest "bits" of the UV co-ordinates and uses them as an index into the UVnoise texture, the red and green values of which are then added to the actual whole UV co-ordinates. The effect of this is that at the finest detail when very zoomed in, instead of the fine values of the UV just giving you ever more clearly defined square pixels of the maintexture, you get warped pixels (that then don't like squares at all). Actually, Galileo probably explains it better.

If you mean flicker at the main menu, that's a known issue (caused by EVE not knowing when to create clouds on a planet and sometimes creating them twice when Kopernicus is fiddling with the main menu at the same time EVE is). I wouldn't turn off the shadowMaterial just to "fix" the main menu as the problem should never happen in-game.

SVE is EVE configs, Scatterer configs, and Kopernicus tweaks, that together Make Everything Better it requires both EVE and Scatterer to work, but Kopernicus is optional. Stock Visual Terrain (SVT) is actual terrain detail improvements (requires Kopernicus). I strongly recommend both. The default EVE configs (BoulderCo) is just an example, in my opinion. Certainly I don't change the configs and if someone wanted to contribute improvements, I'd probably just tell them to make their own config mod (except perhaps adding an aurora, because that is something that EVE tries hard to make possible but does not actually demonstrate).

I've seen similar issues when trying to change between EVE configs (eg. between BoulderCo which I test and SVE which I play). I don't know if it's bug in CKAN or in the NetKAN data for EVE. It seems CKAN only handles it well if you first uninstall things, then reinstall them. eg. uninstall EVE, then install SVE (which reinstalls EVE). Fortunately, CKAN caches the downloads themselves, so it doesn't take long. If you want to track it down permanently, you'll need to report to the NetKAN and/or CKAN developers, with a nice clean example (i.e. minimal mod selection) of what causes the problem.

With the "BoulderCo" (default) configs, there is only one cloud layer. Each layer spins at a constant speed and direction, so the clouds always appear to go over at the same speed. With multiple layers you'll see differences depending on which layer(s)'s clouds are passing overhead. In any case, I have not changed the configs since I started maintaining EVE with 1.2, nor how that part of the config is interpreted. If it's significantly different, that was an accident (but not one I would fix, since those who do write configs will have adapted by now).

I suspect this is purely a coincidence of when you happened to be looking. KSC has some days heavily clouded, others much less so.

Your known-issues is out-of-date: with the current EVE, clouds should always appear in the main menu. Even with Kopernicus, they will sometimes be doubled (visible as a shimmer), but never missing.

You'll need to trace the problem further yourself first. Start with the smallest file that shows the problem. What is different in that file versus the EVE configs that do work? etc.

The sphere upon which clouds are painted is a PQS (for non-modders: that's what KSP terrains are made of - a "Procedural Quad Sphere"), so it could have bumps, and instancing the volumetric clouds at that height would be no problem either. I'm struggling to see the use case though - fog tends to form at a height, with bumps in the terrain poking up through the fog. If we can find a use-case, defining the bumps would best be done somehow leveraging Kopernicus rather than duplicating that code, but inter-mod calls isn't a big deal, and surely anyone using SVE is also using SVT :-).

Use CKAN, search for "EVE", click it, choose which config you wish to use.

I should read READMEs and Known Issues before asking questions.

Is this necessary? @Scatterer_config:AFTER[StockVisualEnhancements]:NEEDS[PoodsOPMVO] { @integrateWithEVEClouds = False } With this, OPMVO is also "Stock Planets Visual Underhaul", which is a bad thing.