Jump to content

[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


blackrack

Recommended Posts

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 by rbray89
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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):

igyDflN.png

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 by blackrack
Link to comment
Share on other sites

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):

igyDflN.png

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?

Link to comment
Share on other sites

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 by blackrack
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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 by skykooler
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

 

Oqd6Oas.jpg

 

However when there are problems they seem to happen randomly at random LOD levels, this what LOD level 3 looks like

 

ysGoXpu.png

 

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 by blackrack
Link to comment
Share on other sites

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 by blackrack
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by blackrack
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...