[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

[curtquarquesso]

Not sure if this has been asked before, but I'll give it a go. 

I'm currently using Sigma Dimensions to rescale Kerbin, and the Kerbin system to 6.4x its scale. I've figured out basic things, like rescaling the map view to the correct radius of the planetary body, and I'm trying to figure out what else needs to be tweaked to make Scatterer look right on rescaled bodies. Are there any other parameters I should be tweaking besides the map view radius?

Map view looks good, but in low orbits, the scattering and the horizon doesn't quite match up. It seems to be a bit lower than the horizon. Which controls do I tweak to adjust this?

[rbray89]

3 hours ago, blackrack said:

It's a 7-zip file, download 7-zip (it's free, fast and handles all the common compression formats) or wait a few seconds, I'm currently uploading to spacedock.

Edited: up on spacedock http://spacedock.info/mod/141/scatterer

Edited again:

Hmm, turns out the default shadow system can be used to make the terrain generate shadows, this complements the godrays nicely.

 

So cool! I think I figured out how we could do cloud godrays too... Use a mesh similar to your ocean, place the vertices at cloud sphere level, then extrude them where the texture would obscure light.

Edited February 18, 2016 by rbray89

[Errol]

3 hours ago, blackrack said:

...

Hmm, turns out the default shadow system can be used to make the terrain generate shadows, this complements the godrays nicely.

...

 

This is going to make the Mun way more Epic. Can't wait to grind the crack with this!

[Nhawks17]

4 hours ago, blackrack said:

It's a 7-zip file, download 7-zip (it's free, fast and handles all the common compression formats) or wait a few seconds, I'm currently uploading to spacedock.

Edited: up on spacedock http://spacedock.info/mod/141/scatterer

Edited again:

Hmm, turns out the default shadow system can be used to make the terrain generate shadows, this complements the godrays nicely.

 

Postprocessing disabled so you can see the shadows:

 

Those terrain shadows are so subtle but add so much to the visual look of the terrain its crazy. As always, fantastic fantastic work Blackrack!

[blackrack]

2 hours ago, curtquarquesso said:

Not sure if this has been asked before, but I'll give it a go. 

I'm currently using Sigma Dimensions to rescale Kerbin, and the Kerbin system to 6.4x its scale. I've figured out basic things, like rescaling the map view to the correct radius of the planetary body, and I'm trying to figure out what else needs to be tweaked to make Scatterer look right on rescaled bodies. Are there any other parameters I should be tweaking besides the map view radius?

Map view looks good, but in low orbits, the scattering and the horizon doesn't quite match up. It seems to be a bit lower than the horizon. Which controls do I tweak to adjust this?

Could you post some screens? Sounds like something went wrong. Btw I fixed having to set the map view scale manually, will release it in next update.

 

1 hour ago, rbray89 said:

So cool! I think I figured out how we could do cloud godrays too... Use a mesh similar to your ocean, place the vertices at cloud sphere level, then extrude them where the texture would obscure light.

This would work, I guess you'll have to set some kind of threshold though. Also, I have to talk about the current limitations of the method so maybe we could think of solutions, and also because they would be more obvious with clouds. I'll explain with some images as it's easier to get the point across, and also for everyone else who happens to read the thread:

So basically when I do the scattering I get the scene depth from the depth buffer and compute the amount of scattering based on optical depth, assuming the whole segment is receiving light, pretty straightforward.

 

Now when I want to render a godray, I have to get only the length of the lit section. For this I extrude the geometry edge along the direction of the light and write it to the depth buffer. This works nicely when looking straight into terrain and along the direction of the sun.

However, say we are looking sideways from a sun, and a mountain in the distance is projecting a godray, we need the length of the two lit sections, the current method only returns the length of the first lit section.

In practice this results in it looking like this, where everything behind a godray looks like it's in shadowa dn the transition is harsh.

To get around this I though I'd render the depth of the backfaces separately and then using the depth of the frontface minus that of the backface I'd get the length of the unlit section, which I'd then substract from the total length, returned by the regular depth buffer. This should work nicely but I haven't tried it yet. And usually with terrain the viewing angles are limited enough that one godray+scattering in the background would look believable in the majority of views.

However with clouds it gets really complicated, we now have an arbitrary number of godrays.

This is what I'm thinking about now, how to get the lengths of all the lit or unlit sections. Hope this is clear for everyone.

First idea that comes to mind is maybe we could do some sort of additive blending when we write the godray depths and then the same on the backfaces to get the total length or something. And also, the depth values aren't linear, which further complicates this.

Edited February 18, 2016 by blackrack

[rbray89]

2 minutes ago, blackrack said:

Could you post some screens? Sounds like something went wrong. Btw I fixed having to set the map view scale manually, will release it in next update.

 

This would work, I guess you'll have to set some kind of threshold though. Also, I have to talk about the current limitations of the method so maybe we could think of solutions, and also because they would be more obvious with clouds. I'll explain with some images as it's easier to get the point across, and also for everyone else who happens to read the thread:

So basically when I do the scattering I get the scene depth from the depth buffer and compute the amount of scattering based on optical depth, assuming the whole segment is receiving light, pretty straightforward.

 

Now when I want to render a godray, I have to get only the length of the lit section. For this I extrude the geometry edge along the direction of the light and write it to the depth buffer. This works nicely when looking straight into terrain and along the direction of the sun.

However, say we are looking sideways from a sun, and a mountain in the distance is projecting a godray, we need the length of the two lit sections, the current method only returns the length of the first lit section.

In practice this results in it looking like this, where everything behind a godray looks like it's in shadowa dn the transition is harsh.

To get around this I though I'd render the depth of the backfaces separately and then using the depth of the frontface minus that of the backface I'd get the length of the unlit section, which I'd then substract from the total length, returned by the regular depth buffer. This should work nicely but I haven't tried it yet. And usually with terrain the viewing angles are limited enough that one godray+scattering in the background would look believable in the majority of views.

However with clouds it gets really complicated, we now have an arbitrary number of godrays.

This is what I'm thinking about now, how to get the lengths of all the lit or unlit sections. Hope this is clear for everyone.

First idea that comes to mind is maybe we could do some sort of additive blending when we write the godray depths and then the same on the backfaces to get the total length or something.

I'll have to think of this a bit... one possilibility is to write the amount of "light" to the alpha channel and use that for blending... 

[blackrack]

23 minutes ago, rbray89 said:

I'll have to think of this a bit... one possilibility is to write the amount of "light" to the alpha channel and use that for blending... 

How would you get that value?

Edited: Btw I think if we add all the distances to the backfaces and and substract all the distances to the front faces it should work.

Edited February 18, 2016 by blackrack

[Manwith Noname]

5 hours ago, blackrack said:

...shadow pics...

*GASP*

My jaw dropped so far and fast it hit the floor and shattered into a million pieces.

 

Edit: Actually, as this mod develops I think your avatar is more and more fitting.

Praise the sun!

Edited February 18, 2016 by Manwith Noname

[blackrack]

1 hour ago, Manwith Noname said:

Edit: Actually, as this mod develops I think your avatar is more and more fitting.

Praise the sun!

Indeed, it's one of the reasons I picked it!

[Deizelpunk]

On ‎2‎/‎17‎/‎2016 at 6:41 PM, gkorgood said:

Here you go! I take no responsibility for the consequences of using this craft, and full responsibility for designing it.

Thank you very much!

 

[rbray89]

3 hours ago, blackrack said:

How would you get that value?

Edited: Btw I think if we add all the distances to the backfaces and and substract all the distances to the front faces it should work.

Basically in the atmosphere post-process, the blend mode would use dest alpha as a multiplier to the source alpha I think. Its been a long day though, and I'm not certain I'm thinking clearly anymore  

[blackrack]

1 minute ago, rbray89 said:

Basically in the atmosphere post-process, the blend mode would use dest alpha as a multiplier to the source alpha I think. Its been a long day though, and I'm not certain I'm thinking clearly anymore  

Wait, I'm not sure whether you mean using this for "how transparent a cloud is", and making a godray equally transparent, or to compute the total length of lit distance. Btw I actually just noticed there are some directions in the Proland paper on how to handle godrays, I just ignored them before as I couldn't understand anything at the time except they used geometry extrusion.

[rbray89]

3 minutes ago, blackrack said:

Wait, I'm not sure whether you mean using this for "how transparent a cloud is", and making a godray equally transparent, or to compute the total length of lit distance. Btw I actually just noticed there are some directions in the Proland paper on how to handle godrays, I just ignored them before as I couldn't understand anything at the time except they used geometry extrusion.

EDIT: God rays... We would use an extruded mesh and write the alpha there for the cloud god rays.

 

BTW, how did you get around the gaps in geometry? Is it the push/extruded mesh method we discussed earlier?

Edited February 19, 2016 by rbray89

[blackrack]

14 minutes ago, rbray89 said:

EDIT: God rays... We would use an extruded mesh and write the alpha there for the cloud god rays.

BTW, how did you get around the gaps in geometry? Is it the push/extruded mesh method we discussed earlier?

I didn't actually, it's just not too bad when you crank the terrain quality up. And i also thought the blur pass would help with the small gaps. It's still most noticeable when you look at the mountains near KSC from the launchpad and it looks pretty bad. I thought about the extruded mesh more, and actually it's a real issue what to do with vertexes that aren't over anything. With the ocean it's easier, you can use a mathematic formula to tell you where the horizon line lies and just drag all vertexes over the horizon line back to the horizon and it just works.

I still don't understand how you plane to use the alpha value here.

Edited February 19, 2016 by blackrack

[rbray89]

7 minutes ago, blackrack said:

just drag all vertexes over the horizon line back to the horizon and it just works. 

I still don't understand how you plane to use the alpha value here.

Do the same... Place those that don't map back to horizon.

The idea would be to stash some info on how transparent the atmosphere should be using alpha. Ideally, we'd use one blending pass to set it to a known value for the screen, and then any elements that shouldn't have as much atmospheric effect would have a different alpha value. Then when the atmosphere goes to do alpha blending, it would use the dst alpha in its blending (likely as a modifier to the additive effect by pre-multiplying the color with src alpha.)

Edited February 19, 2016 by rbray89

[blackrack]

20 minutes ago, rbray89 said:

Do the same... Place those that don't map back to horizon.

The idea would be to stash some info on how transparent the atmosphere should be using alpha. Ideally, we'd use one blending pass to set it to a known value for the screen, and then any elements that shouldn't have as much atmospheric effect would have a different alpha value. Then when the atmosphere goes to do alpha blending, it would use the dst alpha in its blending (likely as a modifier to the additive effect by pre-multiplying the color with src alpha.)

I would say that isn't really necessary, as long as we can get the distance that is lit correctly, we can do the blending directly depending on this length and the results of the scattering.

Btw I switched the shader from alpha blending to soft-additive (1-dstcolor, 1), coupled with a multiplicative atmospheric extinction pass before-hand, like with the orbit shader, I think it gives softer and less foggier results and lets more of the original color shine through, but looks thicker around sunrises/mornings and sunsets, because of dimmer dscolor.

Edited February 19, 2016 by blackrack

[pingopete]

19 hours ago, blackrack said:

Could you post some screens? Sounds like something went wrong. Btw I fixed having to set the map view scale manually, will release it in next update.

 

This would work, I guess you'll have to set some kind of threshold though. Also, I have to talk about the current limitations of the method so maybe we could think of solutions, and also because they would be more obvious with clouds. I'll explain with some images as it's easier to get the point across, and also for everyone else who happens to read the thread:

So basically when I do the scattering I get the scene depth from the depth buffer and compute the amount of scattering based on optical depth, assuming the whole segment is receiving light, pretty straightforward.

 

Now when I want to render a godray, I have to get only the length of the lit section. For this I extrude the geometry edge along the direction of the light and write it to the depth buffer. This works nicely when looking straight into terrain and along the direction of the sun.

However, say we are looking sideways from a sun, and a mountain in the distance is projecting a godray, we need the length of the two lit sections, the current method only returns the length of the first lit section.

In practice this results in it looking like this, where everything behind a godray looks like it's in shadowa dn the transition is harsh.

To get around this I though I'd render the depth of the backfaces separately and then using the depth of the frontface minus that of the backface I'd get the length of the unlit section, which I'd then substract from the total length, returned by the regular depth buffer. This should work nicely but I haven't tried it yet. And usually with terrain the viewing angles are limited enough that one godray+scattering in the background would look believable in the majority of views.

However with clouds it gets really complicated, we now have an arbitrary number of godrays.

This is what I'm thinking about now, how to get the lengths of all the lit or unlit sections. Hope this is clear for everyone.

First idea that comes to mind is maybe we could do some sort of additive blending when we write the godray depths and then the same on the backfaces to get the total length or something. And also, the depth values aren't linear, which further complicates this.

Sweet Kerbin clouds and godrays would be almighty

[blackrack]

Next version is looking quite good

 

And some webms:

https://gfycat.com/LightGrandAmericanmarten

http://gfycat.com/SecondaryHandyCattle

https://gfycat.com/WaryKeenHylaeosaurus

https://gfycat.com/HiddenUnconsciousAfricanmolesnake

[Milkshakefiend]

1 hour ago, blackrack said:

Next version is looking quite good

Ho-leee sh...

I don't have a reaction gif that can handle that much awesome.

[V8jester]

2 hours ago, blackrack said:

Next version is looking quite good

....

You owe me a new keyboard..... I broke mine spamming the like button.

Edited February 19, 2016 by V8jester

[stratochief66]

I'm trying to adjust a scatterer profile for RSS Venus. I am terrible at colours and I am clearly missing something. No matter what settings I adjust in game or in the config, the planet stays purple. I'm trying to work from the planet Eve Scatterer (Eve-> Venus). Is the colour baked into the Eve folder somehow? I even tried copying the colour settings from the Kerbin/Earth config and achieved no change in colour.

 

Any suggestions or direction pointing would be appreciated.

[blackrack]

9 minutes ago, stratochief66 said:

I'm trying to adjust a scatterer profile for RSS Venus. I am terrible at colours and I am clearly missing something. No matter what settings I adjust in game or in the config, the planet stays purple. I'm trying to work from the planet Eve Scatterer (Eve-> Venus). Is the colour baked into the Eve folder somehow? I even tried copying the colour settings from the Kerbin/Earth config and achieved no change in colour.

 

Any suggestions or direction pointing would be appreciated.

The most important information is in that 16 mb .raw file.

You have to generate a new one with the config tool in the OP (a wise man once said "ah the OP, what wonders it holds") when you're done copy the files and the settings as instructed in the OP. You don't have to make the radius match that of the planet, it'll be rescaled automatically when you load the mod. Also the format has changed and I haven't updated the config tool, the mod no longer uses the xml format, just open the xml format and copy the settings manually to settings.cfg

Edited February 19, 2016 by blackrack

[stratochief66]

2 minutes ago, blackrack said:

The most important information is in that 16 mb .raw file.

You have to generate a new one with the config tool in the OP (a wise man once said "ah the OP, what wonders it holds") when you're done copy the files and the settings as instructed in the OP. You don't have to make the radius match that of the planet, it'll be rescaled automatically when you load the mod. 

Ahh, so the colour is baked into something :S

Possibly a "next weekend" project thing then. I am terrible with colours.

The OP contains many wonders, including the secrets to basic RSS Scatterer compatibility!

Thanks for the speedy response.

[sashan]

3 hours ago, blackrack said:

Next version is looking quite good

OMFG

 

Do those shadows affect vessels? Also, are they present on other bodies? Would be great to have knife-sharp shadows on Mun.

Edited February 19, 2016 by sashan

[blackrack]

6 minutes ago, sashan said:

OMFG

Do those shadows affect vessels? Also, are they present on other bodies? Would be great to have knife-sharp shadows on Mun.

Yes and yes, although I checked on mun and it was quite underwhelming still.

Edited February 19, 2016 by blackrack