rbray89

[quote name='Bizz Keryear']Have the black sky problem, too, but I really think that it is more of an problem caused by EVE. Since even with the old version of scatter it shows a complete black sky Anyway while having a look at the files there are some things that hit my eye. [list][*]Is it really necessary to have duplicates of files? I mean sunglare.png and black.png are literally the same everywhere. How about bout a folder named global. Having all the stuff in that is used more than once. Every for every planet if it has a folder of its own but it doesn't find file X in it it uses the global one. [*]The black png ... after starting up KSP ... not being in game, not doing something in game I am already at 3.2 Gig (not really [only] your fault, though).... is it really necessary to have a 5kb png of only one color? .... I mean is there really a reason to make it 512 x 512 pixels, too? If I was making this my black file would probably (unless I really really need something else) be (if used to produce black pixels) a 1x1 pixel grayscale bmp. (this should make the smallest file since you don't need compression for just one pixel and one color) Size of that file is 66 bytes to 4533 bytes of yours. On other hand I am relative clueless when it comes to compiling C scripts, I am clueless about Unity and KSP api. So ... I don't know if that would work. But I still thought I mentioned it. Maybe you are so deep into it that it left your grasp that you could use a file like this, too.[/list][/QUOTE] Try disabling cloud shadows in EVE. GUI: ALT-0

[quote name='Manwith Noname']Uch, I don't like double posting but here goes... With just scatterer and the latest fix with the new shading technique, the big blue rectangles are gone, however.... [url]http://steamcommunity.com/sharedfiles/filedetails/?id=557876814[/url] [url]http://steamcommunity.com/sharedfiles/filedetails/?id=557884235[/url] You'll probably need to zoom in on the second shot but particles appear to wipe out the atmo effect under certain circumstances. So I suspect the blue rectangles in the sky when EVE is present are in some way connected to this too.[/QUOTE] Weird... is this with the new depth buffer change?

[quote name='Manwith Noname']I'll test but I very much doubt it as I was using EVE with the tonemapper until scatterer was updated to 1.0.5 and I did not see this until using the latest shader fixes above.[/QUOTE] Ah. Carry on then :)

[quote name='Manwith Noname']It is certainly odd how this has different issues for different people so I'm wondering what other things are at play. For example, after cleaning out my install and putting EVE, scatterer and the latest fixes in place, I get this.. [URL]http://steamcommunity.com/sharedfiles/filedetails/?id=557792501[/URL] Maybe the blackness has something to do with Proot and Nhawks17 using higher resolution textures or something about the modified files they have. I've got some things I need to do but I'll try these latest fixes with just scatterer in place shortly.[/QUOTE] Does this (or something like it) still happen without Scatterer? Those look like the quads generated for EVE's volume particles.

[quote name='Proot']Eve and/or Scatterer seems to have some kind of problem/incompatibility in the last changes: atmos are loaded, but unloaded again after one or two secs, leaving the sky black (I've changed the delay with no effect). Also, environmental effects appears completely stopped (froze, no movement), and the volumetrics are gone. I'm not able to determine the specific problem, so I'm reporting the same to you and Blackrack. I leave you the logs here: [URL="https://drive.google.com/file/d/0B8doOUfa8UN-WGZ5dTVvaVVGaWM/view?usp=sharing"]KSP.log [/URL][URL="https://drive.google.com/file/d/0B8doOUfa8UN-VTk4RFQwc0Q0S0U/view?usp=sharing"]output_log.txt[/URL][/QUOTE] Is this with your configs or mine? There were changes in some parameters (speed)

Yeah, this was my suspicion. OpenGl seems to use a much less precise depth buffer than DX, so when it goes to try and get the value for depth testing it fails the check sometimes, even though it is EXACTLY where it should be. We could fix this by removing shadows from Jool I think. If we try to offset the depth check any further than we are now we'll run into bigger black lines around the KSC for example.

[quote name='blackrack']It's actually pretty simple, using this as a replacement shader [CODE] Shader "Custom/DepthTexture" { SubShader { Tags { "RenderType"="Opaque" } Pass { Fog { Mode Off } CGPROGRAM #pragma vertex vert #pragma fragment frag #include "UnityCG.cginc" struct v2f { float4 pos : SV_POSITION; float2 depth : TEXCOORD0; }; v2f vert (appdata_base v) { v2f o; o.pos = mul (UNITY_MATRIX_MVP, v.vertex); UNITY_TRANSFER_DEPTH(o.depth); return o; } half4 frag(v2f i) : COLOR { UNITY_OUTPUT_DEPTH(i.depth); } ENDCG } } } [/CODE] And then just creating a camera that renders the scene with this replacement shader to a rendertexture. This produces a regular (linear?) depth buffer but the rendertexture depth can be set manually when creating it. This seems to fix my OpenGL issues but dx9 still seems to have some flickering so I'll probably experiment with the logarithmic depth buffer later on.[/QUOTE] Very cool!

[quote name='blackrack']Custom depth buffer is working, all high altitude artifacts and moire patterns are gone. The barrier effect at the edge of the ocean remains but I already have an idea for that. [url]http://i.imgur.com/HjQX71H.jpg[/url] The maximum depth allowed is actually 24bit. Turns out OpenGL was using 16bit by default which explains why it was so bad. Now to fix the ground to orbit transition. Edited: for those who want to try it: [URL="https://mega.nz/#!6JYDSKQJ!JoSWw_pr7wH1wBbknI3k7Nfl5xhRJ7tUcYCCcx3xHyA"]ArtifactsFix.zip[/URL] I will probably add a few more features before making a complete new release/reupload to kerbalstuff.[/QUOTE] Sweet! What is involved with generating the new depth texture?

[quote name='parameciumkid']Ah, I see. I ended up having to completely rebuild my custom CFG from scratch. By the way, issues I've seen so far: - If not all of the planets/moons have an entry in clouds.cfg, sometimes when tabbing to a planet in the Map view the debug log is spammed with an exception about an argument index being out of range. - When erasing and re-entering values in the color field, the debug log spams with a warning about the color format being invalid until three commas have been typed. - Layer2D's don't display if a detail texture has been set, even if the main texture has been set. This was easy to solve with a simple 4x4 white square texture, but it wasn't necessary in the last version. - New cloud layers by default have "1,1,1,1" in the color field, but colors still range from 0 to 255, so this ends up being nearly invisible black rather than solid white (255,255,255,255). - It's nice being able to put hyperbolic values in the color field for things like over-saturated color effects (Moho looks seriously hot now), but putting large values still doesn't cause the clouds to glow in the dark as it prior to the reboot - no matter how large a value is placed there, clouds at night remain invisible. If you have a different plan for things like aurorae and noctilucent clouds, that's fine, but currently neither the CityLights nor cloud systems can produce them. I intended to post a log file, but unfortunately I solved all the problems already so they're not visible in there any more xD Hopefully my description at least helps. And I'd put screenshots, but everything looks just fine ;)[/QUOTE] Most things are adressed, though I couldn't replicate the Index out of range and have to table the glow in the dark until next release. [url]https://github.com/rbray89/EnvironmentalVisualEnhancements/releases/tag/EVE-1.05-3[/url] [COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] [quote name='TyrannoFan']Well, I also deleted the city lights plugin as well as the city lights folder in BoulderCo. Since I wasn't using Eve clouds in the config, I deleted Eve's cloud image too. I replaced detail1.dds and duna1.dds with dds conversions of the Astronomer's Visual Pack's detail1.png and duna.png of those textures as well. I downgraded to the first 1.0.5 version and it's working properly now, even though I did those exact same things in that version too.[/QUOTE] Don't delete things aside from configs. Read the OP. [COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] So the z-fighting *Should* be fixed, but I couldn't replicate it to begin with. "Z-fighting in OpenGL should be fixed. Unfortunately this causes some small extra darkening with geometry very close to ground. This results in a dark border when clouds are above around KSP as an example. Unfortunately on OpenGL platforms this is unavoidable."

[quote name='TyrannoFan']I downloaded the most recent version and I have an issue where the clouds look like they're updating very slowly. As in, they stay still for a few seconds and then jump to the next position. It's very distracting and is noticeable on the ground, in space and for every planet with clouds. Here's a quick 6 second clip that shows what I mean in map view. I upped the cloud speed and went up to 1000x time warp to make the effect more obvious: [url]http://gfycat.com/DearestRawBorderterrier[/url] EDIT: In case it's relevant, here's my clouds.cfg file: [CODE]EVE_CLOUDS { Kerbin { Kerbin-clouds1 { altitude = 4000 speed = 0,30,0 detailSpeed = 0,6,0 offset = 0,0,0 settings { _MainTex = BoulderCo/Atmosphere/Textures/kerbin1 _DetailTex = BoulderCo/Atmosphere/Textures/detail1 _DetailScale = 8 _DistFade = 1 _DistFadeVert = 4E-05 _Color = 255,255,255,255 _DetailDist = 2E-06 } layer2D { shadowMaterial { } macroCloudMaterial { _FalloffPow = 2 _FalloffScale = 3 _DetailDist = 2E-06 _MinLight = 0.5 _RimDist = 0.0001 _RimDistSub = 1.01 _InvFade = 0.008 } } layerVolume { size = 4000,2 maxTranslation = 0,100,0 area = 24000,4 particleMaterial { _TopTex = BoulderCo/Atmosphere/Textures/particle/1 _LeftTex = BoulderCo/Atmosphere/Textures/particle/2 _FrontTex = BoulderCo/Atmosphere/Textures/particle/3 _LightScatter = 0.55 _MinLight = 0.5 _InvFade = 0.008 } } } } Laythe { Laythe-clouds1 { altitude = 6000 speed = 0,30,0 detailSpeed = 0,6,0 offset = 0,0,0 settings { _MainTex = BoulderCo/Atmosphere/Textures/kerbin1 _DetailTex = BoulderCo/Atmosphere/Textures/detail1 _DetailScale = 8 _DistFade = 1 _DistFadeVert = 4E-05 _Color = 255,255,255,255 _DetailDist = 2E-06 } layer2D { shadowMaterial { } macroCloudMaterial { _FalloffPow = 2 _FalloffScale = 3 _DetailDist = 2E-06 _MinLight = 0.5 _RimDist = 0.0001 _RimDistSub = 1.01 _InvFade = 0.008 } } layerVolume { size = 4000,2 maxTranslation = 0,100,0 area = 24000,4 particleMaterial { _TopTex = BoulderCo/Atmosphere/Textures/particle/1 _LeftTex = BoulderCo/Atmosphere/Textures/particle/2 _FrontTex = BoulderCo/Atmosphere/Textures/particle/3 _LightScatter = 0.55 _MinLight = 0.5 _InvFade = 0.008 } } } } Duna { Duna-clouds1 { altitude = 8000 speed = 0,30,0 detailSpeed = 0,6,0 offset = 0,0,0 settings { _MainTex = BoulderCo/Atmosphere/Textures/duna1 _DetailTex = BoulderCo/Atmosphere/Textures/detail1 _DetailScale = 8 _DistFade = 1 _DistFadeVert = 4E-05 _Color = 255,255,255,255 _DetailDist = 2E-06 } layer2D { shadowMaterial { } macroCloudMaterial { _FalloffPow = 2 _FalloffScale = 3 _DetailDist = 2E-06 _MinLight = 0.5 _RimDist = 0.0001 _RimDistSub = 1.01 _InvFade = 0.008 } } layerVolume { size = 4000,2 maxTranslation = 0,100,0 area = 24000,4 particleMaterial { _TopTex = BoulderCo/Atmosphere/Textures/particle/1 _LeftTex = BoulderCo/Atmosphere/Textures/particle/2 _FrontTex = BoulderCo/Atmosphere/Textures/particle/3 _LightScatter = 0.55 _MinLight = 0.5 _InvFade = 0.008 } } } } }[/CODE][/QUOTE] I can't seem to replicate this.

[quote name='jlcarneiro']Hey, rbray89, your mod literally looks fantastic, thanks! I use 64-bit linux version (on nVidia) and no problems such the ocean on KSC. But the atmospheric planets show some kind of flickering. Firstly, I thought it was lightnings, but I decided to report it to you. I'm not sure what you need to report a glitch, but here are the log files and an animated gif. [SPOILER=The animated screenshot (wait it load)][url]http://i.imgur.com/Ird4LNm.gif[/url][/SPOILER] [URL="http://www.filedropper.com/ksp"]The log file[/URL] Hope this is enough...[/QUOTE] Hmmm... could you try something? While looking at Duna (like in the screenshot) Press ALT+0 and toggle the "Cloud Shadows?" Then hit Apply? I think this is related to the shadows.

[quote name='blackrack']I've looked around a bit, it appears that when using forward, unity uses whichever depth buffer is default for the platform and hardware (32bit for dx9, 24bit for OpenGL) and when using deferred it uses replacement shaders to render a 32bit depth buffer for both. So this should work :cool: And although dx9 seems to have slight flickering at some altitudes it's much better than the combined patterns and flickering OpenGL has. This will be a first step before I try a logarithmic depth buffer.[/QUOTE] Ah that makes sense. I'd probably like a better depth buffer anyways and being able to send that off to all cameras rather than relying on them to have a unified buffer.

[quote name='blackrack']Actually no, I'm using the depth only map that forward gives and it has artifacts compared to deferred. The depthNormals map was a lot worse and I couldn't even achieve the effects I wanted with the normals so I just got rid of it.[/QUOTE] Hmmm... Then I'm not sure. It is still probably producing a better depth buffer though.

[quote name='blackrack']This is a cool idea, and I was thinking about doing this to simulate a really thick atmo on Eve, but for scatterer it wouldn't work that well because the proland atmo is really rigid in many ways. ALso, won't this make it render on top of the EVE clouds again? However I thought about making a custom shader based on the unity global fog shader to simulate dust or really dense fog on Eve.[/QUOTE] Yeah, but that would be where the idea of writing alpha could save us. Me too... [COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] [quote name='blackrack']But deferred rendering definitely fixes all the artifacts which is weird.[/QUOTE] Oh, and I think that might be the case. I think that unity might actually render to two seperate buffers for depth and normal to achieve quality results, while you are reading from a depth+normal map right?

[quote name='blackrack']Ah okay, I'm not talking about ShaderReplacer, but about using replacement shaders [URL="http://docs.unity3d.com/Manual/SL-ShaderReplacement.html"]http://docs.unity3d.com/Manual/SL-ShaderReplacement.html[/URL] to re-render a scene and obtain a depth buffer for example.[/QUOTE] Right. I just wanted to mention that you can remove this entity and no longer have to worry about updating it going forward. As a cool by-product, if you do make your own depth buffer you could use a camera with a huge clipping area and then you could use the near camera instead of the far camera for rendering and make much more dense atmo-rendering.

[quote name='blackrack']Well it's mostly the ocean, starts at 10 KMs up. But at higher altitudes other artifacts start appearing over the land so this won't be enough. I noticed that forcing deferred rendering seems to get rid of all these artifacts but it causes many more issues with the rendering that I don't feel like looking at. Do you know if deferred rendering uses some kind of higher precision depth buffer? Maybe 32bit for deferred vs 24bit for forward?[/QUOTE] Not that I'm aware of. In case you didn't see: Oh, and you shouldn't have to use shaderreplacer any more! The newest KSP added the shader tags for RenderType. [COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] [quote name='blackrack']Well it's mostly the ocean, starts at 10 KMs up. But at higher altitudes other artifacts start appearing over the land so this won't be enough. I noticed that forcing deferred rendering seems to get rid of all these artifacts but it causes many more issues with the rendering that I don't feel like looking at. Do you know if deferred rendering uses some kind of higher precision depth buffer? Maybe 32bit for deferred vs 24bit for forward? So wait, how do I render this as to obtain a custom depth buffer without a replacement shader?[/QUOTE] ShaderReplacer being the entity that substitutes KSPs shader code with the modified code that adds the Shader Tags that they ommitted :) EDIT: This guy: [url]https://github.com/LGhassen/Scatterer/blob/master/scatterer/ShaderReplacer.cs[/url]

[quote name='blackrack']That seems nifty, in the end do you just look at the alpha value of the texture? Do the shadows have variable alpha depending on the clouds? I probably shouldn't look at the code right now though as I'm way too tired to understand anything.[/QUOTE] Close... we first subtract the alpha off the color, then use the alpha to lerp between 1 and the color. It is then multiplied to the DstColor. This way, if the cloud was colored, we get a multiplicative effect that reflects the color passing through. We subtract the alpha to ensure that a fully opaque cloud is always opaque but if not some color should still show through (maybe we should use *(1-color.a) instead...) and then that value gets filtered once again by alpha to determine intensity. [code] Blend Zero SrcColor ... fixed4 color = _Color * main.rgba * lerp(detail.rgba, 1, detailLevel); color.rgb = saturate(color.rgb - color.a); color.rgb = lerp(1, color.rgb, _ShadowFactor*color.a); return lerp(1, color, shadowCheck); [/code] [quote name='blackrack']Also, I wanted to ask your opinion about logarithmic depth buffers. I've been meaning to implement a custom logarithmic depth buffer for use with the "post-processing" shader to solve what I think are depth buffer inaccuracies that arise mostly in dx11 and OpenGL when looking at the water surface from the limit altitude where the PQS is disappearing, but also I think it causes a flickering (z-fighting?) effect in dx9. There are a few resources on this, notably [URL="http://outerra.blogspot.fr/2009/08/logarithmic-z-buffer.html"]http://outerra.blogspot.fr/2009/08/logarithmic-z-buffer.html[/URL] [URL="http://outerra.blogspot.fr/2013/07/logarithmic-depth-buffer-optimizations.html"]http://outerra.blogspot.fr/2013/07/logarithmic-depth-buffer-optimizations.html[/URL] I haven't gone too much in detail yet but it seems feasible, although I think reconstructing world position from this new depth buffer might be a bit more of a pain (it already was a pain for me to get working). I plan to just start from the provided unity depth shader and make changes to it, then use it as a replacement shader and obtain a depth buffer in a rendertexture. Thought it sounds straightforward, I know if too much matrix math gets involved I will lose my sanity.[/QUOTE] If it is just water surface, than do what I was doing. I didn't want to enable depth processing on the ocean.: [code] _OceanRadius ("Ocean Radius", Float) = 63000 _PlanetOrigin ("Sphere Center", Vector) = (0,0,0,1) ... float _OceanRadius; float3 _PlanetOrigin; ... [vertex] o.L = _PlanetOrigin - _WorldSpaceCameraPos.xyz; ... [surface] half3 worldDir = normalize(IN.worldVert - _WorldSpaceCameraPos.xyz); float tc = dot(IN.L, worldDir); float d = sqrt(dot(IN.L,IN.L)-(tc*tc)); float3 norm = normalize(-IN.L); float d2 = pow(d,2); float td = sqrt(dot(IN.L,IN.L)-d2); float oceanRadius = _Scale*_OceanRadius; half sphereCheck = step(d, oceanRadius)*step(0.0, tc); float tlc = sqrt((oceanRadius*oceanRadius)-d2); float oceanSphereDist = lerp(depth, tc - tlc, sphereCheck); depth = min(oceanSphereDist, depth); [/code] This will allow you to get the distance to the ocean if it is a "hit" or depth in the "miss" case. From there, you just take the min of the depth and the ocean dist. It allows you to get the VERY accurate distance to the ocean (floating point loss rather than depth buffer compression) I dreamed this up when thinking about how to go about doing stuff without using the depth buffer, and found that spherical collision is actually a very common math problem apparently. I've since used the same approach in many shaders. We are very lucky that things are perfect spheres in KSP. [COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] Oh, and you shouldn't have to use shaderreplacer any more! The newest KSP added the shader tags for RenderType.

[quote name='Sethur']Hi rbray, thanks for your great work. I'm on 1.0.5, 32bit, Windows with -force-opengl and -popupwindow and with the 1.0.5-2 release of EVE, I'm getting z-fighting/flickering issues when I'm in map view or in the tracking station view. Weirdly enough, I'm seeing clouds when I am in the tracking station, but only city lights when I am in the map view. The flickering issue is, however, present in both views. I'm using an NVIDIA Geforce with up-to-date drivers. I'll include some time series screenshots of the z-fighting. You have to zoom in on the original pictures to see it, the compression here in the forum will make the artifacts almost disappear. It's very clearly visible though when in-game.[/QUOTE] Take a closer look while in the tracking station. The lights can be hard to spot. Is it flickering or something? It should be stretched near the terminator as the light is coming in from a very oblate angle

[quote name='blackrack']Btw is your celestial object shadow shader functional in the newest EVE?[/QUOTE] Nope. Some of the stuff is there, but not enabled. I have to go a completely new route as many things wouldn't work properly had I pursued the multi-projector route (eg. any transparent things like clouds wouldn't be handled properly, scaled space shadows shake violently with camera movement, and multiple bodies obscuring the sun would result in multiple darkening passes being very unrealistic.) so I'm pursuing the single projector, multi-body shader for macro space, and an additional body material that handles multiple casts. I may turn this into a full scale lighting pass shader. [quote name='blackrack']And another question about projectors, how do you geenerate them from the clouds texture for the shadows?[/QUOTE] Oooh... a loaded question... basically, we take the vertex, the sun Direction, the body position and the cloud sphere radius, and use sphere collision math to determine at what distance a ray from that vertex would hit the cloud sphere. Then we take that, and get the cloud position with vertex+(sunDir*distance) and from there, we use the body position to get the point of the sphere that resolves to. From there, we just plug that into our existing formula to fetch the texture. You can take a look in [url]https://github.com/rbray89/EnvironmentalVisualEnhancements/blob/master/ShaderLoader/Shaders/CloudShadow.shader[/url] to get a better peek.

[quote name='parameciumkid']Yay! New version! Um, question: For those of us who have already customized the CFGs and textures, did you introduce any new textures or CFGs in this edition?[/QUOTE] Only minor config changes. Some of the parameter types changed float to vector3, vector3 to vector2, etc. The GUI will highlight any items it can't parse, so that should help some.

[quote name='blackrack']It doesn't, I'll add it. I guess it's time for me to catch up with the new EVE features. ManwithNoname can you put back EVE and try if this fixes it? [URL="https://mega.nz/#!2ZQgTBxQ!3_6QQu07-3yyQBvEhd6NLFaCXYqlrVDiW_Pne2YfxrU"]https://mega.nz/#!2ZQgTBxQ!3_6QQu07-3yyQBvEhd6NLFaCXYqlrVDiW_Pne2YfxrU[/URL][/QUOTE] I thought shader tags were case sensitive? Is that not the case?

[quote name='Manwith Noname']First, love this work. Sadly, I encountered a rather strange problem. [url]http://steamcommunity.com/sharedfiles/filedetails/?id=557198023[/url] [url]http://steamcommunity.com/sharedfiles/filedetails/?id=557198289[/url] I haven't tried scatterer on it's own but as you can probably tell I am using this with E.V.E and the seperate tone mapper plugin. I'm not sure if the logs will tell you anything but I can upload them if you feel they may show something. What also happens but is hard to capture in a screenshot, when zooming out in the map view I get this strange zooming black area toward the camera. This is 1.0.5 KSP 32 bit on Windows with no launch parameters to alter rendering.[/QUOTE] Hmmm.... Blackrack, does your shader perchance include "IgnoreProjector"="True"? If it doesn't, it should :)

[quote name='Poodmund']Yes! Haha, this is exactly what I have been doing. I can't show it happening in screenshots but I have been playing around with Tekto and simulating some serious gas storms on the surface. The rotating particles create a faux shimmer (kind of like heat haze) and there are periods of really thick fog/dust due to the texture maps I am using. Its really fun. Makes Tekto look really hostile. [url]http://imgur.com/a/yYph4[/url][/QUOTE] Nice! I'd love to see a GIF of it in action! Would being able to select an axis of rotation be helpful? I'm thinking specifically of things like hurricanes and whatnot.

[quote name='purpleivan']Here's the [URL="https://www.dropbox.com/s/1gi2vg5xsc47fis/output_log.txt?dl=0"]output log[/URL] from my last load (using most recent EVE build) BTW... the behaviour disappeared on return to KSC after after switching to there from Mun orbit.[/QUOTE] Yeah, this definitely looks like z-fighting. Usually this shouldn't happen, but apparently on certain graphics cards on OpenGL this can cause this issue. I'd also recommend upgrading graphics drivers.

[quote name='blackrack']I'm getting the impression they do, will have to check.[/QUOTE] It should get the same global shader value PlanetOpacity or some such value passed to it.