rbray89

You can raise the altitude in the clouds config file to be higher than the mountains... personally, I prefer getting close to the mountains and seeing the peaks stick up out of the volumetric clouds. Increase your texture graphics settings in KSP. - - - Updated - - - In what way? With Configs? The current release is not config-compatible with the old EVE.

Not sure... it might? I didn't try the binaries, but the code certainly would if recompiled. You'd just have to try it out and see.

We are now on mainline Overhaul branch is now depricated. I may create new branches for additional features and whatnot though. If that's the case, I'll update here.

You can open the configs and change all "shadow=True" to False to disable them. Atmosphere is not a supported function right now. I'd recommend scatterer in the meantime.

op: Alt+0

You downloading the two zip files and extracting them both?

OS? Anything you did to trigger it?

See the OP in http://forum.kerbalspaceprogram.com/threads/100857-WIP-Environmental-Visual-Enhancements-Development I want to keep it "under wraps" for people who shouldn't be messing with the configs - - - Updated - - - Updated the github link with a mini description of what the files are. https://github.com/rbray89/EnvironmentalVisualEnhancements/releases/tag/EVE-1.05-1

If there are configs to handle them, sure. Things like astronomer's visual pack and such won't work with this new and improved version though. You'll have to wait for the pack authors to come up with something.

City texture is there during day. Clouds don't appear in main-menu for now.

Sorry folks, looks like my release mechanism was broken. Updated and corrected.

EVE has been updated. Get it here: https://github.com/rbray89/EnvironmentalVisualEnhancements/releases/tag/EVE-1.05-1

Nope. Projectors should be rendered Somewhere after geometry, but before transparency. Don't know the exact queue number though.

That looks about right.

Add EVE to Eve for some cloud action!

At any rate though, projectors won't work for clouds or atmo, so we'll have to do something different for them anyways. EDIT: Now that I think about it though, we could use the same mechanism planned for clouds in the shader for projectors, reducing the draw call significantly, use only one projector per active PQS, and fix the ocean issue (both ground and ocean receive projectors, and should have a filter mechanism like cloud shadows do.

Keeping projector count down is better I could try with multiple projectors to check it out though. Very possible. We would just use the "d" value and compare it against the planet radius to do a linear smoothing.

So the way projectors work is that they have a FOV (In this case orthogonal and with a size of the planet that casts the shadow), Layer masks, and Clip planes, much like cameras do. Every material in the frustum of the projector in the layer mask and without the shader tag "IgnoreProjector=True", will be re-rendered with the new shader. In our case, the shader is placed on the surface of the shadow casting body facing away from the sun, projecting the shadow shader on anything in it's path. The shadow is calculated using the vertex of the mesh, along with the sun direction and center of the casting body. IT assumes a perfect sphere, so unfortunately oblate bodies won't be handled properly. Luckily when using projectors, the implementation is simplified, but imperfect. We only have to use one projector per body, and swap the layer masks and variables to go from scaled space to macro, but this means if you have a craft in space past PQS, the shadows won't render properly on BOTH the craft and body (has to be one unless you have multiple projectors). It also means clouds can't receive them either. What I plan to do is move to a (much more complicated) solution where the projectors are kept for PQS and ship-in-space situations, and the scaled space situations will use additional material(s) that implement shadows. If I want the clouds to properly receive them, I'll have to add all the shadows to the cloud shader. I think I have a way to do this in a single pass, but it may result in BAD performance. If I do this, I'll end up re-using this implementation with the shader for bodies and there will just be a single material for the body shadows. With this, I think I will be able to do up to 4 celestial shadows casting on a single body (matrix of 4 value sets: body position [xyz] and radius [w]) but it will require choosing a select set of bodies and managing their positions to plug into the materials. Much more involvement, but should be a more complete solution. - - - Updated - - - Yeah, I still need to alter the penumbra to be more accurate.

Projectors. It's actually a really simple shader: Shader "EVE/PlanetShadow" { Properties { _PlanetOrigin ("Sphere Center", Vector) = (0,0,0,1) _SunDir ("Sunlight direction", Vector) = (0,0,0,1) _PlanetRadius ("Planet Radius", Float) = 1 } SubShader { Pass { Blend DstColor Zero ZWrite Off CGPROGRAM #include "EVEUtils.cginc" #pragma target 3.0 #pragma glsl #pragma vertex vert #pragma fragment frag uniform sampler2D _MainTex; float4 _MainOffset; uniform sampler2D _DetailTex; fixed4 _DetailOffset; float _DetailScale; float _DetailDist; float4 _SunDir; float _PlanetRadius; float3 _PlanetOrigin; uniform float4x4 _Projector; struct appdata_t { float4 vertex : POSITION; float3 normal : NORMAL; }; struct v2f { float4 pos : SV_POSITION; float4 posProj : TEXCOORD0; float dotcoeff : TEXCOORD1; float originDist : TEXCOORD2; float nDotL : TEXCOORD3; float4 worldPos : TEXCOORD4; float3 L : TEXCOORD5; }; v2f vert (appdata_t v) { v2f o; o.posProj = mul(_Projector, v.vertex); o.pos = mul(UNITY_MATRIX_MVP, v.vertex); float3 normView = normalize(float3(_Projector[2][0],_Projector[2][1], _Projector[2][2])); float4 vertexPos = mul(_Object2World, v.vertex); o.worldPos = vertexPos; float3 worldOrigin = _PlanetOrigin; o.L = worldOrigin - vertexPos; o.originDist = length(o.L); o.nDotL = -dot(_SunDir, mul(_Object2World, float4(v.normal,0)).xyz); return o; } fixed4 frag (v2f IN) : COLOR { //Eliminate vertexes facing the "wrong" way. Either behind the projector, or facing away from it. half shadowCheck = step(0, IN.posProj.w)*step(0, IN.nDotL); //Get the component of L facing the Sun. float tc = dot(IN.L,- _SunDir); //Find the distance from the sphere center to the tangent. float d = sqrt(dot(IN.L,IN.L)-(tc*tc)); //Chceck for occlusion. d should be smaller than radius, and tc should be >0 (facing the sphere) half sphereCheck = step(d, _PlanetRadius)*step(0.0, tc); fixed4 color = half4(1,1,1,sphereCheck); color.a = 1.2*(1.2-color.a); color = saturate(color); return lerp(1, color.a, shadowCheck); } ENDCG } } } The issue right now of course is that projectors don't work well with transparent objects. I think what I'm going to do is keep the projectors for world-space, and for scaled space, create another material that can do several body shadows in a single pass. I'll then add those passes to my cloud shader. I'm not certain it will translate well to atmospheric use, then again, I don't really understand how Scatterer calculates all the math in the first place. You'd probably have to add some math to determine what percentage of light is now occluded from the region of air you are looking into.

That's my plan.

Yup! Everything goes dark as it does in real-life

Mun and Kerbin Shadows: http://gfycat.com/BowedCooperativeEkaltadeta

Sill have to figure out how to render the body eclipse onto the clouds...

Hmmm... Tried toying around with scatterer, but I don't know enough about it's workings to say if this is what I should be doing. Extinction shader goes first, extinguishes alpha, keeps color blend mode / Compiled shader for all platforms, uncompressed size: 22.5KB Shader "Proland/Atmo/SkyExtinction" { SubShader { Tags { "QUEUE"="Transparent-6" } // Stats for Vertex shader: // d3d11 : 10 math // d3d9 : 14 math // Stats for Fragment shader: // d3d11 : 48 math, 2 branch // d3d9 : 68 math, 2 texture Pass { Tags { "QUEUE"="Transparent-6" } ZTest False ZWrite Off Cull Front Blend DstColor Zero, Zero Zero Planet is re-rendered next, writing brightness to alpha. Shader "EVE/PlanetLight" { Properties { _Color ("Color Tint", Color) = (1,1,1,1) } Category { Lighting On ZWrite Off Cull Back Blend SrcColor SrcAlpha, One Zero Tags { "Queue"="Transparent-5" "RenderMode"="Transparent" "IgnoreProjector"="True" } Sky is last. Now addition is dependent on framebuffer alpha. Here, we could also try reversing it to "Blend One OneMinusDstAlpha" and reversing the alpha writing in the planet shader to write dark areas as "1". // Compiled shader for all platforms, uncompressed size: 52.6KB Shader "Proland/Atmo/Sky" { SubShader { Tags { "QUEUE"="Transparent-3" } // Stats for Vertex shader: // d3d11 : 10 math // d3d9 : 14 math // Stats for Fragment shader: // d3d11 : 163 math, 1 texture // d3d9 : 243 math, 11 texture Pass { Tags { "QUEUE"="Transparent-3" } ZTest False ZWrite Off Cull Front Blend OneMinusDstAlpha One - - - Updated - - - Ok, got it. had to move my shader to Geometry+1: This is still with the queues being moved around as well, so I don't know for certain how much the new alpha changes are helping. Interestingly, Mun now glows with a slight tint of whatever the sun is. Pretty cool actually.

Perfect. That was my initial attempt at a proper terminator with a VERY overpowered multiplicative blend. I think the default sky shader over-writes the alpha values though. That or there is a bug in my atmo shader. Either way, we are getting closer. I suspect that this is entirely an issue with KSP's sky. It also seems to write to the depth buffer (no "zwrite off"), and seems to be on the transparent render queue. It is quite annoying; I see why you decided to eliminate it