blackrack

[quote name='selfish_meme'][url]http://i.imgur.com/vsRPpXB.png[/url]I am seeing a noticible lag now on scene changes before scatterer kicks in, it was always behind the scene load but now it's more pronounced, no other effect of note. Linux 64bit, Intel with nvidia graphics and overidden hardware antialiasing. Happens for a second before physics kicks in. Glorius.[/QUOTE] Try setting delayLoading = 0 in the planetslist.cfg file.

[quote name='rbray89']Sweet! What is involved with generating the new depth texture?[/QUOTE] 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.

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. [IMG]http://i.imgur.com/HjQX71H.jpg[/IMG] 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 name='rbray89']Hmmm... Then I'm not sure. It is still probably producing a better depth buffer though.[/QUOTE] 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 name='rbray89']Yeah, but that would be where the idea of writing alpha could save us. Me too... [COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] 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] 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 name='rbray89']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] 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 name='sashan']I guess it's the only mod that uses new EVE. Also, the Jool is amazing. And it may eventually revamp ground textures. And it is up to date. Well, just try. :P By the way, how heavy is it comparing to Astronomer's? [COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] Is it the problem of new EVE, or is the old Eve and Scatterer play together much better on edges of the visible part of the planet? Here's the old EVE, compare it to the pic in the OP: [url]http://i.imgur.com/9YwxrIG.png[/url][/QUOTE] Actually if you look at from 90 degrees to the side it still has the same problem. The terminators don't line up so it looks weird, EVE was originally built with stock's terminators in mind so it looks off with scatterer. I believe rbray is making this adjustable though.

[quote name='rbray89']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] ShaderReplacer being the entity that substitutes KSPs shader code with the modified code that adds the Shader Tags that they ommitted :)[/QUOTE] But deferred rendering definitely fixes all the artifacts which is weird. 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 name='rbray89']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] 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.[/QUOTE] 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 name='rbray89'] Oh, and you shouldn't have to use shaderreplacer any more! The newest KSP added the shader tags for RenderType.[/QUOTE] So wait, how do I re-render everything so as to obtain a custom depth buffer without a replacement shader? Edited: I might still use your snippet for the ocean as I still get some kind of barrier around the horizon on oceans in OpenGL.

[quote name='Manwith Noname']Good news, hopefully. Latest EVE, Scatterer 0.0191 plus fix 3. It appears all the visual glitches are gone....at least for me. The only thing that remains is the atmo effect is lost when returning to space center from map view, which is presumably something to do with refreshing on scene change...though you two (Blackrack and rBray89) are far more qualified to be able to diagnose that.[/QUOTE] That is just a bug with the latest version that happens sometimes. Not important I'd say it's just the KSC view, nothing game-breaking. However, I'm testing the fix myself right now, and it seems with scatterer only the sky still goes black randomly.

[quote name='rbray89']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] 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. 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 name='Nhawks17']Fixed the black land but the sky is still black :([/QUOTE] Oh well, no idea what to do now, as far as I know it should be ignoring the projectors now.

[quote name='Nhawks17']Ok... now it's doing this :P [url]http://imgur.com/a/1FvpS[/url] That third image was taken after I had gone to map view and back again.[/QUOTE] [quote name='Manwith Noname']I'll try those new files but I'll just add... Latest EVE and default Scatterer has the weird glitches but when I replaced those shaders with the earlier files the bulk of the problem goes away. Now I get a strange little box that seems to occupy a point in space relative to the camera. I'm trying to set up shadow play to capture it but I've never captured video and have no editing software so bear with me.[/QUOTE] Ok wait, give it one last try with this [URL="https://mega.nz/#!fQhiWL7S!sOG0rJu-W2HeT7LKaMYLzHZYLAchod0YwAeaXmfH9d0"]https://mega.nz/#!fQhiWL7S!sOG0rJu-W2HeT7LKaMYLzHZYLAchod0YwAeaXmfH9d0[/URL]

[quote name='rbray89']I thought shader tags were case sensitive? Is that not the case?[/QUOTE] I actually didn't know this, I copied that from another shader so no idea why it's in caps to begin with. Btw is your celestial object shadow shader functional in the newest EVE? And another question about projectors, how do you geenerate them from the clouds texture for the shadows? [quote name='Manwith Noname']Ok, progress report. Clean install just scatterer - No anomalies loading into launch and viewing map. Reverting to hangar from map view kills atmo effects when exiting out to KSC As does simply returning to space center from map view. Entering a hangar and exiting again does not force them to load however, entering the tracking station and exiting out does. As does launching another vessel. Clean install just scatterer but with replaced files - Same as above, but I'm not surprised as the change in code seems like it would be unrelated to this. Off to add the latest E.V.E and see what happens. I'll also revert Scatterer back to the original download and try with the replacement shaders.[/QUOTE] [quote name='Nhawks17']I think I'm experiencing something similar to Manwith Noname... This is using the latest version of EVE (1-05-2) and I tried the default new Scatterer download as well as using the two .shader files you posted above and this happens still. You load the game and the sky goes black, go to a craft, it's still black, go to map view everything is fine, go back to your craft and scatterer effects are showing but it seems to me it breaks EVE and the clouds stop doing what they are configured to do... if that makes sense... I can provide more details if you need me to :P [url]http://imgur.com/a/H38F0[/url][/QUOTE] As rbray said I messed up the tags. Try scatterer again with these files and the latest EVE: [URL="https://mega.nz/#!CMISkRRA!NLq6s5CIxx2P30XkVq-h3OSDwZZiM0_QUg1_BDuI7Gk"]https://mega.nz/#!CMISkRRA!NLq6s5CIxx2P30XkVq-h3OSDwZZiM0_QUg1_BDuI7Gk[/URL]

[quote name='rbray89']Hmmm.... Blackrack, does your shader perchance include "IgnoreProjector"="True"? If it doesn't, it should :)[/QUOTE] 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 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] You don't need skytonemapper with the latest version of scatterer. Also, test with scatterer only, we're not psychics.

[quote name='rbray89']Don't think so.[/QUOTE] I'm getting the impression they do, will have to check.

[quote name='eggrobin'](although they will be far more accessible once we get manœuvre nodes working). :)[/QUOTE] Please say that will be available soon.

Quick question to whoever would know: Does the water PQS/PQS sphere thing have a different fading altitude than the terrain PQS?

[quote name='rbray89']Bingo. Abstracting things to bare minimum. Pretty views should come from those sending craft to the places :)[/QUOTE] I get it, but I still think this should grow into it's own mod. Also, I'd imagine for planets never visited/scanned the map view should just look like an empty sphere or a low-res one or something, and once you scan them you get the continents/topography view and it looks more like this [URL="http://www.ufopaedia.org/images/e/e5/Control.png"]http://www.ufopaedia.org/images/e/e5/Control.png[/URL].

[quote name='rbray89']Nah... I was thinking that for a map, it looks too nice :) It should be like a screen you would see at NASA depicting orbits. Not super detailed, and certainly no clouds or atmosphere. And the background shouldn't be stars, it should be a grid or something like that.[/QUOTE] Ah wait, so you're thinking of making a custom map view basically. Ahh, should have said so at the start. Well, the first thing that came to my mind was a high-tech/holographic planet and orbit view with the background being the operations room/control center àla XCOM [IMG]http://static-3.nexusmods.com/15/mods/151/images/482-1-1400737231.jpg[/IMG] Probably not a good idea though as the room is quite detailed :p

[quote name='rbray89']Yeah, I know about those... I was considering something a bit more... eg. exchanging the shaders for something less photo-realistic and/or blurring planets far from Kerbin without craft orbiting/exploring them.[/QUOTE] Not sure what you want to accomplish with this. I just unload planets that are far away because the memory usage of precomputed scattering tables loaded into rendertextures is quite high. If you are trying to optimize the memory usage you could probably load some low res textures or drop the textures on far away planets (still you'd have to benchmark it for different resolutions to see if there is much to gain). For lowering GPU usage I wouldn't really know, I'm not really up to date with EVE-overhaul and the different shaders you have except for the clouds.

[quote name='rbray89']So I was actually thinking of providing an option to mostly kill mapview and tracking station graphics to bare-bones... Have any thoughts there?[/QUOTE] Well for mapview I just use (MapView.MapIsEnabled) as a condition, for the tracking station (HighLogic.LoadedScene == GameScenes.TRACKSTATION). Will that do? I get the impression you're asking about something more.

[quote name='Poodmund']Ah, good to know! :wink: I'm having a little trouble getting the balance point right between keeping a low exposure in orbital view to keep the effect subtle which retaining a halo ring when viewing the eclipse from behind the planet. I'll get there! Thanks a million for this, makes it look sooo much better.[/QUOTE] I'm planning to add different exposure settings for the "halo around the planet" and the atmosphere that you see directly over terrain so this shouldn't be a problem in the future. [quote name='Poodmund'] It took me a while to realise that you had to have an active vessel within Scatterer's activate range before the effects would load in. Is there a way to force it to activate on the currently focused body in Map Mode?[/QUOTE] Actually I disabled the activation on purpose in map view because it made browsing the map view laggy, might make it togglable later.

[quote name='Poodmund']Loving the new multi-planet support, I have been playing around with Tekto this evening trying it out using all homemade textures with the new EVE release. [url]http://imgur.com/a/6j1ck[/url][/QUOTE] Beautiful, btw if you need to test a new atmo, you don't need to reload the game, go back to space center view, change the atmo files and then go back to your ship (make sure you go to space center view before changing the config as quitting to space center view automatically saves your settings which overrides the .cfg file).

[quote name='Pronoes']Yes latest Scatterer (downloaded about 5 hours ago through CKAN). Is your advice to try an older version of scatterer?[/QUOTE] No, just noticing how scatterer works for some and doesn't even start for others with RSS.