[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

[Manwith Noname]

To explain it fully is going to take so much explanation. 

If I take the last point you make, "Kerbals under a red star would still see white as white". This suggests to me, coupled with the rest of the post that you think nature has something encoded within it that means all life will try to make itself see light a certain way (the same way as we do under our star). By extension of that thought process, all life on Earth would see things exactly as we do because we all live under the same star and we are quite sure that isn't the case.

Edited February 29, 2020 by Manwith Noname
Trimming huge off topic stuff.

[R-T-B]

I don't know about you guys but I'm a frog-flight director helping the kerbals out, so I probably see based on our Stars (Sol's) light spectrum. hehe.

[Manwith Noname]

Or the light spectrum of your monitor.

[VoidSquid]

1 hour ago, Manwith Noname said:

By extension of that thought process, all life on Earth would see things exactly as we do

Actually: no. Think about how, as per our knowledge say a bee, or an octopus sees their respective universe.

If you like, feel free to join this off-topic thread, but as per my understanding, posts in this thread should mainly stay on topic, ok?

Anything goes, with just one premise: no offence given, no offence taken. And ofc, within the general guidelines of this forum.

Edited February 29, 2020 by VoidSquid

[Manwith Noname]

Heh, having taken a quick peek at the discussion there already, I think that might just confuse things. Anyway...

2 minutes ago, VoidSquid said:

Actually: no. Think about how, as per our knowledge say a bee, or an octopus sees their respective universe.

Exactly, this was my point. In any case, if you are aware of that then I suspect I've misunderstood the post and run off on a tangent so, I've trimmed my post because while trying to keep other parts simple I'm just making things worse and leaving an opening for huge off topic ramblings.

[VoidSquid]

13 minutes ago, Manwith Noname said:

I'm just making things worse and leaving an opening for huge off topic ramblings.

I like off topic ramblings  

Feel free to join this thread, just two rules:

1. Open discussion about everything, but no offence taken, no offence given.

2. We have to stay within the forum's guidelines.

 

[R-T-B]

I found a way to get scatterer working in 1.9 without blue terrain.

After forcing OpenGL, scatterer runs but Kerbin terrain is blue above a certain altitude.  This config fixes that.  The issue seems to be that the Spec RGB values are too high.  Some, like Kerbin, are too high by a factor of about 5!  I have lowered them accordingly to restore the right effect.

I have no idea why this works, it just does.  Sharing for it's limited example use only, I still think you should probably wait for a release.

http://glacialsoftware.net/Scatterer19OGLConfigFix.zip

Extract that into your gamedata overwriting your scatterer stock planet configs.

Example of result:

Edited February 29, 2020 by R-T-B

[VoidSquid]

8 minutes ago, R-T-B said:

I found a way to get scatterer working in 1.9 without blue terrain.

That's still AVP, not SVE, right?

[R-T-B]

53 minutes ago, VoidSquid said:

That's still AVP, not SVE, right?

It's just stock scatterer.

 

I just noticed my test was by accident on 1.9.0.  I just tested again and it works on 1.9.1 as well.

Heck, my whole "Red Dwarf" modstack appears to do so, actually:

 

Looks like I personally am updating today.

NOTE:  A lot of those mods on the toolbar are custom recompiles and for the authors sake I will not be sharing them.

Edited February 29, 2020 by R-T-B

[steve_v]

4 hours ago, R-T-B said:

After forcing OpenGL, scatterer runs but Kerbin terrain is blue above a certain altitude.  This config fixes that.

It does indeed, and so does the config shipped with AVP.
The massive performance tax however, that remains.

[R-T-B]

15 minutes ago, steve_v said:

It does indeed, and so does the config shipped with AVP.
The massive performance tax however, that remains.

You running AMD GPU by chance?  I am too, so no hard feelings re your brand of choice...  lol.  They all have pros and cons like anything.

But anyway: Nvidia had a much, much faster opengl implementation when I last used them.  Just sayin'  So for some the "tax" may not be an issue, maybe?

Sadly though, it seems there are some kind of artifacts in the sun at certain altitudes.  Distracting.

 

Edited March 1, 2020 by R-T-B

[steve_v]

10 minutes ago, R-T-B said:

You running AMD GPU by chance?  I am too, so no hard feelings re your brand of choice...  lol.  They all have pros and cons like anything.

Nah, mildly overclocked GTX1070. I gave up on ATI/AMD long ago, as their GNU/Linux drivers sucked extremely hard. I hear it's better now, but I have a long memory.

It's only with scatterer, only on 1.9.x, only in the flight scene, and only when the atmosphere is visible. GPU load is ~30%, CPU tapped out on two cores, clock flickering yellow. Something in scatterer seems to be loading the CPU, but it doesn't throw any exceptions. Looking at the ground restores framerate immediately.

Edited March 1, 2020 by steve_v

[R-T-B]

1 minute ago, steve_v said:

Nah, mildly overclocked GTX1070. I gave up on ATI/AMD long ago, as their GNU/Linux drivers sucked extremely hard. I hear it's better now, but I have a long memory.

It's only with scatterer, only on 1.9.x, only in the flight scene, and only when the atmosphere is visible. GPU load is ~30%, CPU tapped out on two cores, clock flickering yellow. Something in scatterer seems to be loading the CPU, but it doesn't throw any exceptions. Looking at the ground restores framerate immediately.

Yep, same result here (plus super duper sun artifacts!) sadly.

[steve_v]

1 minute ago, R-T-B said:

Yep, same result here (plus super duper sun artifacts!) sadly.

I guess I'll have to take my own advice and wait for an update then. Minor code fixes and recompiles I can do, but shaders and the like are really not my thing.

[soulsource]

10 hours ago, R-T-B said:

You running AMD GPU by chance?  I am too, so no hard feelings re your brand of choice...  lol.  They all have pros and cons like anything.

But anyway: Nvidia had a much, much faster opengl implementation when I last used them.  Just sayin'  So for some the "tax" may not be an issue, maybe?

Sadly though, it seems there are some kind of artifacts in the sun at certain altitudes.  Distracting.

 

From what I've found it's not the OpenGL implementation, it's that nVidia has custom workarounds for what Unity does to hardcoded constant-value matrices when transpiling HLSL shaders to GLSL. The issue here really lies with Unity. The problem is, that the HLSL->GLSL transpiler is not able to properly transpile matrices of constant values.

Instead of simply outputting constant value hardcoded matrices on the GLSL side as well, the transpiler

1. allocates a dynamic (aka: non-constant) array the size of the matrix for each fragment ("pixel") . This is done in global scope, so this array has longer lifetime than the shader's individual functions.
2. for each fragment ("pixel") re-initializes this array with the hardcoded values at the beginning of the shader's main function.
3. has the code use the value in that array (even though the same value is there, hardcoded, and used for initialization...)

Now, this is a problem, because, if the shader compiler does not have a custom workaround for that broken behaviour of the HLSL->GLSL transpiler, the shader compiler will do as told, and allocate a bunch of vector registers to store the matrix for every fragment (keep in mind, that the code generated by Unity's HLSL-GLSL transpiler just tells the shader compiler, that there is a matrix of floating point values that could in principle be different for every fragment, and that that matrix is in global scope, so it has longer lifetime than any shader function and therefore cannot be optimized away).

For small matrices this is bad, because in an ideal world, several waves (meaning: groups of fragments, vertices, whatever) should be scheduled on the same SIMD computation unit, to allow it to hide memory latency by working on a different wave if one wave is waiting for data. This is not "true" multitasking, meaning, that also registers of "background" waves are kept directly at the computation unit. If now one wave takes a lot of registers, less waves can be scheduled for that computation unit, increasing the impact of memory latency. While this is not optimal, it's not a full catastrophe either.

If, however, the matrices are big, we go from bad to (much, much) worse. The shader compiler now is running out of registers in which to store the matrix. Instead the matrix gets placed in video memory (aka. "register spilling"). If this happens, the shader's performance goes from acceptable to "What do you mean, I should draw a picture? You just told me to spend most of my time copying numbers between video memory and registers!".

I did report this issue to the Unity developers, but made the report from my personal (free) account (because I noticed it at home, while working on Scatterer's OpenGL performance). Of course the bug report was ignored...
I should have really posted it at work, using our Unity premium support accounts...

Edited March 1, 2020 by soulsource

[dave1904]

20 hours ago, VoidSquid said:

Hmm... while not specific to EVE (or any other location), if things are way too dark and you're feeling you're hunting a black crow (there are white crows too, just saying) at night, this mod helps:

 

Go ahead!  

Thanks but I remember changing it in the cloud settings in a previous version but on tekto in opm. The setting exists but I simply forgot how to change it. 

Edit: Omg why am I asking this here. I need to go to SVE and after 20 seconds there I saw the menu I was looking for was Alt+0 ..... Sorry.

Edited March 1, 2020 by dave1904

[blackrack]

On 2/29/2020 at 10:56 PM, R-T-B said:

I found a way to get scatterer working in 1.9 without blue terrain.

After forcing OpenGL, scatterer runs but Kerbin terrain is blue above a certain altitude.  This config fixes that.  The issue seems to be that the Spec RGB values are too high.  Some, like Kerbin, are too high by a factor of about 5!  I have lowered them accordingly to restore the right effect.

I have no idea why this works, it just does.  Sharing for it's limited example use only, I still think you should probably wait for a release.

http://glacialsoftware.net/Scatterer19OGLConfigFix.zip

Extract that into your gamedata overwriting your scatterer stock planet configs.

Thanks for these tips.

In addition to what @R-T-B said, it was reported to me on github that scatterer will work fine by forcing Directx12.

So instead of using the slow openGL, just use directx12: -force-d3d12

I'm adding this info to the OP.

[Pepe]

Confirming the Dx12 force fix works.  Water is back and scatterer working perfectly.  Also confirming that my new 2080TI graphics card makes this game with Scatterer and AVP runs BEAUTIFULLY.

 

[prestja]

1 hour ago, Pepe said:

Confirming the Dx12 force fix works.  Water is back and scatterer working perfectly.  Also confirming that my new 2080TI graphics card makes this game with Scatterer and AVP runs BEAUTIFULLY.

 

AVP works with 1.9?

[gap]

5 minutes ago, prestja said:

AVP works with 1.9?

Read below please

 

[prestja]

1 minute ago, gap said:

Read below please

 

Ah, thank you.

[R-T-B]

6 hours ago, blackrack said:

Thanks for these tips.

In addition to what @R-T-B said, it was reported to me on github that scatterer will work fine by forcing Directx12.

So instead of using the slow openGL, just use directx12: -force-d3d12

I'm adding this info to the OP.

Does forcing directx12 cause any other issues?  It used to cause strange things longterm.

I wonder if the vulkan renderer still works, in hindsight...  I may have to test today.

EDIT:  Nope, -force vulkan is still broke.  Unfortunate as DX12 is only available to windows 10 users.

Edited March 2, 2020 by R-T-B

[Poodmund]

5 hours ago, R-T-B said:

Does forcing directx12 cause any other issues?  It used to cause strange things longterm.

It causes considerable input lag for myself, both in mouse input and any in-game action. Usable... barely... but 'working' nonetheless.

[grayal]

Sun Flare doesnt seem to work with this fix. And Mechjeb will crash when you try to pick a landing spot

Edited March 3, 2020 by grayal

[banditsan]

16 hours ago, blackrack said:

Thanks for these tips.

In addition to what @R-T-B said, it was reported to me on github that scatterer will work fine by forcing Directx12.

So instead of using the slow openGL, just use directx12: -force-d3d12

I'm adding this info to the OP.

This is only option for people on windows 10.