blackrack

Same as the fourier grid size, so 128x128 by default and always enforced to be power of two anyway.

Yes, he means the main camera already has a depth buffer rendered which means no additional rendering time is wasted with that approach. Creating another camera from another angle would require rendering an additional depth buffer. Edited: @rbray89, I tried displaying the lod levels separately to check for problems. This is what it looks like what the texture is used without mipmapping. However when there are problems they seem to happen randomly at random LOD levels, this what LOD level 3 looks like What I noticed however, when everything is fine, the rendertexture and it's LODs are updated every frame and things move around. However when there are issues, any LOD level with problems will be frozen at the same frame all the time, while unaffected LODs will continue to work as normal. Any idea what might possibly be going on?

Great, foam will look a little different though until a proper fix.

I will check, thanks for the pointers!

Some issue with mipmaps, so I'm guessing they work differently on different GPUs (and apparently between scene refreshes). For now I disabled it on the foam rendertextures, so foam might start looking too sharp and pixely, I'll try to find a better fix later on if this takes care of the issue for everyone.

Found the root of all the ocean artifacts. However fixing it makes the ocean look pixelated in the distance like this (not the black line on the horizon): Funny enough someone complained about this bug 2 days ago, describing the ocean as "having too much resolution" and said changing video modes gave him the black artifacts instead, so these two things are related. I should be able to fix both by the end of the day. Edited: Alright, everyone with the black ocean bug try this: https://mega.nz/#!bB4mAKZB!u9jmQxWMNp7PtavizZ-QK7T41Rjm6wpDamf9iHeJORk

Well, the terrain geometry seems to exist off-screen right now even if at lower detail, so mountains off screen cause godrays that end up on-screen already (I think it's visible in one of the shots I posted). Anyway, I expect shadow mapping won't be easy either, especially at planetary scales but I guess I'll have to try to find out.

I see, another projected grid to work as a base for extrusions. Very clever actually. However I must point out that relying on depth and normals buffers means that objects off-screen won't be able to generate any godrays, basically godrays will only be visible head-on. Still I guess one could render an arbitrary camera from the direction of the light source and build the geometry off of it to get around this issue but that may give precision issues. Also, another problem with the extrusion method in general, I don't really know how to navigate these shadow volumes, I just write their depth value and then use that depth value for the scattering effect. Basically if the viewing ray intersects multiple separate lightshafts only the top one will be seen. This makes me consider that shadow mapping approach instead.

Well, the problem is, these gaps only appear after extrusion and there is no real way to check for them. Besides, the geometry is taken directly from a duplicate camera using a replacement shader, so I don't really pass the geometry around or anything, it's why it's fast. Edited: the gaps actually appear in the godrays, the objects are not a problem, gaps also "fill" and "empty" with a moving light source. Exactly, the code is very simple: float backFactor = dot( toLight, v.normal ); float extrude = (backFactor < 0.0) ? 1.0 : 0.0; v.vertex.xyz -= toLight * (extrude * extrusionLength); But as you can see it doesn't work well for all meshes. It's enough to introduce distracting gaps in the effect. Some people may not notice though and it may look good in some screenshots so I'll probably still release it as an option I've looked around and basically the only way to fix this is to check neighboring edges and faces which can't be done in the vertex shader or alter the geometry by adding additional quads, which also can't be done in the vertex shader. Not sure if there is something else I'm missing.

So unfortunately, the method I'm using for extruding volumes for the godrays doesn't play well with all meshes resulting in many "holes" and instability in the geometry. This would be easily fixed if there was a possibility to access neighboring normals in a vertex shader but as far as I know this isn't possible. Extruding the terrain geometry on the CPU is also out of the question for terrain of that scale and especially for KSP's tight CPU budget. This is unfortunate as this method is very fast, I might still release but it will always have holes and artifacts in it. The issue can be seen in these screens on the box on the left. In the end I might give shadow maps a try and then I'll be able to use them for terrain and for godrays (as per this paper http://www.moving-picture.com/documents/VolumetricShadowMapping.pdf) but I feel it's going to be much slower for real-time. On the upside it will look fuzzier and "more volumetric" than current method.

When I figure out terrain shadows this should be easy.

Well this only works with geometry and also assumes any point in the screen will only go once into the light and once into the shadow, i.e objects in mid-air will break it. You're totally right but there is nothing I can do about the terrain shading right now. These godrays are based on shadow volumes (think shadows in doom3) which I guess I could use for shadows but I'm not sure how to do that. Currently there isn't, but I'll try to come up with something. I was just experimenting with this to see if a little blurriness would help.

Well, I thought about it, but couldn't come up with a name catchier than scatterer suggestions welcome. Btw I'm gonna need some opinions here. Here are godrays rendered at 1/4 resolution and upscaled: http://i.imgur.com/mRb54bZ.jpg http://i.imgur.com/rwq9WoX.jpg (ignore the topmost aliasing artifacts) And here rendered at native resolution: http://i.imgur.com/aHBRtCn.jpg http://i.imgur.com/jeUv8ap.jpg Somehow I find the lower resolution gives them a more volumetric and natural feel while the crisp high resolution betrays their polygonal nature and takes away from the effect. Opinions?

Here are some more cherrypicked screens

Those are just tears in the fabric of space and time. KSP was not meant mean to have this kind of shader, the space-time continuum has been broken... But seriously, I don't know what's causing these yet but the good thing is that I now get them from time to time so I might be able to fix them one of these days. Edited: I'll just leave this here:

They even released 3d hurricane models and asteroid models.

Yes, I said nothing about this being fixed, I might have it fixed soon though. Edited: @Poodmund try this fix for the mapview atmosphere drawing on top of other planets: https://mega.nz/#!CNAwFC7a!JlosJLmYp8jnT8peg2Ctw5UT25nj7AGHzArHsSumre8

Alright, I think I know what it is, I'll have it fixed shortly.

Does this happen outside the map view?

Maybe later on. Don't have any good ideas for this right now.

Well my idea was to make it higher so they have more room to merge "smoothly". Other than that I'm not sure what's going on, it looks like you're getting some kind of "noise" which I haven't seen before.

There's a variable in one of the config files that says fakeoceanaltitude or oceandeactivatealtitude, try changing its value and see if it does anything.

Here are some fresh screens for you, still a lot to figure out and many issues to fix though. Edited: Images are a bit dark so the effect may not be visible depending on your screen brightness.

Yeah but so far using the depth buffer has also been causing lots of artifacts and other precision issues. Edited: First try at godrays. I obviously messed up a few important things but still, it kind of works.

Great, does the rim fix also work? Edited: Not sure how to handle this yet. The terrain isn't currenlty darkened and since I'm planning to add planetshine/multiple suns pretty sure the best way to do both is to somehow obtain the original terrain shaders and modify them or build some new terrain shaders. Rbray was also working on something like this https://www.reddit.com/r/KerbalSpaceProgram/comments/3s3m9g/working_on_celestial_shadows/ , and his approach is different and handles terrain darkening but also doesn't work with the scatterer atmospheres. Not sure if he got it working with clouds though at the time. I can make the EVE clouds go dark when seen from orbit but ground view remains a problem. I could also add the code I'm using to the EVE clouds shader, it'd result in some calculations being done twice but it'd work. Well the ground (PQS) isn't affected yet so there's that. The scaledspace darkening is faked in the extinction shader, I suppose a similar approach would also work for the the PQS if I was to try it but it'd also be depth-buffer based.