[WIP][1.9.x-1.12.x] Scatterer-atmospheric scattering (0.0838 - 14/08/2022) Scattering improvements, in-game atmo generation and multi-sun support

[rbray89]

I think I may have a solution... It would use something similar to what you do with the ocean. A mesh applied on screen, moved to the locations on the depth buffer, and the depth buffer normals extrude the secondary mesh.

Downside is that you'd need both a depth buffer and normals buffer.

EDIT:
The issue stems obviously from not all  vertices being connected to each-other. In regular objects this of-course is to maintain proper normals rather than sharing them and making them inaccurate at hard edges (your cube example). In the case of terrain however, the surface is made up of disjointed quad objects, meaning the vertexes could never be connected.

I think the secondary screen mesh should work though. You'd probably have to filter out the cases where the vertex doesn't hit anything, but you already do a good job in the ocean anyways.

Edited January 28, 2016 by rbray89

[blackrack]

27 minutes ago, rbray89 said:

I think I may have a solution... It would use something similar to what you do with the ocean. A mesh applied on screen, moved to the locations on the depth buffer, and the depth buffer normals extrude the secondary mesh.

Downside is that you'd need both a depth buffer and normals buffer.

EDIT:
The issue stems obviously from not all  vertices being connected to each-other. In regular objects this of-course is to maintain proper normals rather than sharing them and making them inaccurate at hard edges (your cube example). In the case of terrain however, the surface is made up of disjointed quad objects, meaning the vertexes could never be connected.

I think the secondary screen mesh should work though. You'd probably have to filter out the cases where the vertex doesn't hit anything, but you already do a good job in the ocean anyways.

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.

[rbray89]

11 minutes ago, blackrack said:

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.

Gotcha... Though, with any geometry based approach you'd have the issue with off-screen rendering... You'd have to alter the rendersphere to make sure it was rendered anyways.

I look forward to see what can be done with shadow mapping

[blackrack]

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.

[blackrack]

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

Edited January 29, 2016 by blackrack

[rbray89]

34 minutes ago, blackrack said:

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

Out of sheer curiosity, what was the issue?

[blackrack]

4 minutes ago, rbray89 said:

Out of sheer curiosity, what was the issue?

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.

Edited January 29, 2016 by blackrack

[rbray89]

7 minutes ago, blackrack said:

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.

Hmmm.... it may have been that the dv/du values weren't being calculated properly? You could always test by selecting a specific mip map level to see if they are being generated properly, or it is just the selection.

[blackrack]

4 minutes ago, rbray89 said:

Hmmm.... it may have been that the dv/du values weren't being calculated properly? You could always test by selecting a specific mip map level to see if they are being generated properly, or it is just the selection.

I will check, thanks for the pointers!

[colmo]

Excellent news, the mod was unusable on Linux/Nvidia.

[skykooler]

20 hours ago, blackrack said:

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.

What if, instead of creating a plane of vertices that you project, you create a half-sphere (in the direction between the player and the sun)? And then deform the vertices the same way you were doing.

 

Edit: on further consideration, you'd need the other side of the sphere too if you were facing away from the sun, but not if facing toward it. So, I guess, project a section of a sphere that is the union of a half-sphere in the direction of the sun and a half-sphere in the direction the camera is facing. (You could project a whole sphere, but that would have a lot of unnecessary vertices that are behind you and don't deform to somewhere you can see.)

Edited January 29, 2016 by skykooler

[rbray89]

26 minutes ago, skykooler said:

What if, instead of creating a plane of vertices that you project, you create a half-sphere (in the direction between the player and the sun)? And then deform the vertices the same way you were doing.

 

Edit: on further consideration, you'd need the other side of the sphere too if you were facing away from the sun, but not if facing toward it. So, I guess, project a section of a sphere that is the union of a half-sphere in the direction of the sun and a half-sphere in the direction the camera is facing. (You could project a whole sphere, but that would have a lot of unnecessary vertices that are behind you and don't deform to somewhere you can see.)

The problem there is that you'd also need another camera. The idea of using a plane infront of the primary camera, is that you have the depth buffer already.

[TheDog]

4 hours ago, blackrack said:

Edited:

Alright, everyone with the black ocean bug try this:  https://mega.nz/#!bB4mAKZB!u9jmQxWMNp7PtavizZ-QK7T41Rjm6wpDamf9iHeJORk

Totally fixed this for me! (Linux x64, NVIDIA 960M)

[blackrack]

39 minutes ago, TheDog said:

Totally fixed this for me! (Linux x64, NVIDIA 960M)

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

[skykooler]

5 hours ago, rbray89 said:

The problem there is that you'd also need another camera. The idea of using a plane infront of the primary camera, is that you have the depth buffer already.

hmm. I thought that Scatterer was rendering its own depth buffer?

[blackrack]

21 hours ago, skykooler said:

hmm. I thought that Scatterer was rendering its own depth buffer?

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?

Edited January 30, 2016 by blackrack

[rbray89]

as per http://docs.unity3d.com/ScriptReference/RenderTexture-useMipMap.html what is the resolution of the texture?

[blackrack]

33 minutes ago, rbray89 said:

as per http://docs.unity3d.com/ScriptReference/RenderTexture-useMipMap.html what is the resolution of the texture?

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

[rbray89]

4 hours ago, blackrack said:

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

I assume both useMipMap and   generateMips  are set to true? A decent work-around would be to generate the mips manually...

[blackrack]

11 hours ago, rbray89 said:

I assume both useMipMap and   generateMips  are set to true? A decent work-around would be to generate the mips manually...

Yep. How does one generate mipmaps manually?

Edited:

Only way I can think of is to create a bunch of scaled down textures, pass them to the shader and then do the selection and bilinear/trilinear filtering manually to "emulate" mipmaps. Might end up working well, shouldn't impact performance much.

Edited January 31, 2016 by blackrack

[rbray89]

5 hours ago, blackrack said:

Yep. How does one generate mipmaps manually?

When you run SetRenderTarget You can specify a mipmap level. I think there must be a unity bug that doesn't take into consideration the way you are building the texture. I'd expect if you were using Blit or a camera it would just work though.

[blackrack]

6 hours ago, rbray89 said:

When you run SetRenderTarget You can specify a mipmap level. I think there must be a unity bug that doesn't take into consideration the way you are building the texture. I'd expect if you were using Blit or a camera it would just work though.

Hmm, the problem is that I'm using the overload of Graphics.SetRenderTarget that allows to use multiple render targets and it doesn't allow manually setting the mip levels. As far as I know with Graphics.Blit or using a camera you can't render to multiple render targets. So between doing two passes, one for each render target, or manually emulating mipmaps I'm not sure which would be faster. Although I might just try doing two passes as it's easier to try and then maybe the impact on performance is negligible. Normally it should be as this shader is the lightest in all the ocean shaders.

Edited: Did two passes with graphics.Blit, seems to work well. Although I'll have to test more as the bug comes and goes at random.

Edited again:

Just posted a new version with all the recent bug fixes. Other features I've been showing lately are not ready yet. Enjoy.

Edited February 1, 2016 by blackrack

[Gkirmathal]

@blackrack Finally updated ksp to 1.0.5, but does the Skytone Mapper you released some months ago functions in 1.0.5?

[blackrack]

13 minutes ago, Gkirmathal said:

@blackrack Finally updated ksp to 1.0.5, but does the Skytone Mapper you released some months ago functions in 1.0.5?

I think it should work though I never tried. Any reason you'd rather use the tone mapper instead of scatterer?

[KillAshley]

7 hours ago, Gkirmathal said:

@blackrack Finally updated ksp to 1.0.5, but does the Skytone Mapper you released some months ago functions in 1.0.5?

it works fine in 1.0.5, im using it a lot