rbray89

Hah, wish I had thought of that. It's why I implemented the configuration UI though. Got fed up manually editing configs with typos and errors, then when config fields blew up, added the reflection/fields stuff to auto-gen the UI.

This was always the most difficult part to solve. Other games still haven't really solved it either from what I've seen.

I think the issue is that the clouds are all uniformly very dense. You have no "whisps" or foggy clouds.

I think I can get this done over the long weekend.

It is set up so that whatever was x is now red,y is now green etc. So I guess yeah, it needs to match. It isn't so much being ignored but more along the lines of "this isn't easy to answer in a short period of time kind of question" Long story short: there is no "quick" way to increase the cloud cover. I hope to be able to address this in the future. In the meantime I'd recommend SVE for configs and textures as it seems to strike a good balance for cloud cover.

Yes, this is in play in the latest BoulderCo Package. It is just the two textures and the texture config for them.

That's actually the point... Just as Eve is supposed to be the Venusian proxy, it has a thick atmosphere of very dense clouds. To land, I recommend either going in blind and then targeting your approach once through the clouds, or better-yet, use scan-sat to see the body through the clouds.

Fixed the link. Thank you for pointing it out!

*SIGH* Did you read the OP and ignore it or just not read it at all? I need logs to diagnose things. http://forum.kerbalspaceprogram.com/index.php?/topic/83212-how-to-get-support-read-first/

Did you get the latest release? The mun shouldn't have lights on it anymore.

No... there is only one set of geometry for clouds...

Enhanced shading to the particles so that they have a "scattering" and "spherical normal-map" effect.

I don't know why in the world you'd want to do that... It would look pretty terrible... but you'd want to do that you'd want to change noiseScale to very small values. I think it should work if you make them 0. All GPU.

Yeah... Once I realized what I had created I was rather surprised it works so well. It does require people to tweak it for the best effect, but as you've shown, it can look fantastic when used properly

That is odd... One thing you can try is using the "Debug" build instead of the "Release" build. I setup pre/post build commands for the different projects. _BuildManager should create the .mdb files using the mono pdm2mdb util. Then substitute the KSP.exe file with the Unity dev build runtime: Not sure why other mods would affect this, but this is likely a small order issue with the Remove function. So I've brought in the changes from the amazing @Waz into the mainline. You can get the new clouds here: https://github.com/rbray89/EnvironmentalVisualEnhancements/releases/tag/PRE-1.1-3 I'd like some feedback before they get merged into the standard release.

RGB=XYZ in that order one set is for + the other for -. Yeah, this was to try to provide a way to supply the dev builds without publishing a new release all the time. I really didn't want to add the build products to source, but there wasn't any other good way of doing this. The current build process is to use the Unity 5 compiler. Unfortunately they removed cgbuild in Unity 5. Hoping to find a better build process for Unity going forward. See above. I think I'm going to get rid of the interim builds in the repo to make it easier to push/pull/clone. I think I know where this is coming from now... The PQS texture isn't fading out... I think this is an easy fix.

Updated: https://github.com/rbray89/EnvironmentalVisualEnhancements/releases/tag/EVE-1.1-2 Bug fix for rando city lights, enhanced cloud shading.

This is probably a shadow config issue... Delete the shadow config or edit it to fix the body references for celestial shadows.

Oh, now that's clever. I actually have a perlin noise generator that I use for the volumetric particles that I could re-use for the clouds. A texture would likely work fine as well though. Is there a good way to make sure it only samples from a distance of 1 pixel away regardless of texture resolution? Or does that not matter? I guess one could always pass in texture size. Currently there is the "Detail" texture, but as it stands it is very easy to spot, as it is just a repeated texture that is masked with the cloud overlay. By manipulating the UV, the pattern should be almost invisible though I think.

KSP.log is useful, it is player.log that isn't really helpful.

Thickness is determined by the size param. Area covered is determined by the area param. Fade is determined by the _DetailDist and _DistFade. Use noiseScale to change the noise params to change the determined values through the perlin noise. You can also use the maxTranslation values and add room to move in X and Z to make it less grid like.

The issue is I can't tell you what the problem is without the logs... It could be almost ANYTHING. Logs are really the only window I have into the operation of individual installs. Glad to see you read the OP. Is there anything I could do to enforce people to post logs with their issues? I know I said I wouldn't respond, but that seems like It would just result in the community having to tell them to read the OP instead of me Synchronizing different heights is hard, as the speed is not rotationally based, it is based off of speed at cloud level. eg. couds moving at the "same speed" at different heights wouldn't be synchronized. I'd have to edit things in code for this to be feasable.

This is something I'd really like to do, but it is a VERY difficult problem. I've yet to see a planet in ANY game or simulator that makes nice procedural clouds. They seem to use perlin noise exclusively. Send logs. Seriously, do people not even just glance at the OP?

I you could follow the OP and provide screenshots and logs that would help. Nope. This was put on hold once squad added the shader tags I needed.