[1.9-1.12.x] EVE-Redux: Performance-enhanced EVE + maintenance (v1.11.7.1 - 09/09/2022)

[610yesnolovely]

Oh my shadows and rain at 2:37 :-O Staaaaph with teeez! Gib naow! 

Seriously take your time to get it right! (But not too long)

[DocNappers]

@blackrack, the volumetric clouds are very impressive, well done!

I've received some questions about the possibility of incorporating the reduction in visibility that the clouds cause to the line-of-sight checks (visual only, not radar or other instruments) in BDArmoryPlus. Do you know how computationally expensive it'd be to calculate a visibility reduction factor due to the clouds between two points? Is this something that could be calculated between, say, 8 planes (so 28 visibility-reduction calculations per physics frame) without a noticeable drop in framerate?

[blackrack]

3 hours ago, Moose said:

When it's released I believe it'll be in the same pipeline as the current Eve Redux, so it should just be an update - I use CKAN, I highly recommend it.

Though @blackrack may decide to have a second download (I'd assume) for earlier releases if it's a fundamental rewrite?

When it's released you'll have to update EVE and get a different set of configs. Old configs will continue to work as before (it's retrocompatible).

16 minutes ago, DocNappers said:

@blackrack, the volumetric clouds are very impressive, well done!

I've received some questions about the possibility of incorporating the reduction in visibility that the clouds cause to the line-of-sight checks (visual only, not radar or other instruments) in BDArmoryPlus. Do you know how computationally expensive it'd be to calculate a visibility reduction factor due to the clouds between two points? Is this something that could be calculated between, say, 8 planes (so 28 visibility-reduction calculations per physics frame) without a noticeable drop in framerate?

Thank you.

Considering I do these checks for  460800 pairs of points currently (2560x1440 / 8) per regular frame, 28 per physics-frame shouldn't be an issue.

However is a delay of 1-2 physics-frames acceptable in the update of visibility-reduction? It would allow calculating the checks asynchronously on the GPU (the same way scatterer does wave interactions) for even lower CPU load and a simpler implementation (won't need to readapt all the shader code for the CPU). Could this delay be ascribed to pilot reaction time for example, or even just not be noticeable?

Edited October 31, 2022 by blackrack

[DocNappers]

13 minutes ago, blackrack said:

Considering I do these checks for  460800 pairs of points currently (2560x1440 / 8) per regular frame, 28 per physics-frame shouldn't be an issue.

Lol, fair enough! I was thinking that doing these would be much more computationally expensive.

14 minutes ago, blackrack said:

However is a delay of 1-2 physics-frames acceptable in the update of visibility-reduction? It would allow calculating the checks asynchronously on the GPU (the same way scatterer does wave interactions) for even lower CPU load and a simpler implementation (won't need to readapt all the shader code for the CPU). Could this delay be ascribed to pilot reaction time for example, or even just not be noticeable?

Yeah, they could be done that way. At the moment, the target selection logic only happens a couple of times per second anyway, so they could be done a few physics frames in advance without any issue.

If I do get around to implementing this sort of thing in BDA+, then to avoid making EVE redux a hard dependency, I was thinking it could be done via reflection using delegates (in the same way that CameraTools does with BDA+ (ReflectionUtils.cs), which works fairly well), however that would require EVE redux to provide some functions for doing so. Since it'd be asynchronous, I think there'd need to be one for initiating the check and another to check if the results are ready and fetch them since I'm not sure if it's possible to use a coroutine that way.

[blackrack]

33 minutes ago, DocNappers said:

Lol, fair enough! I was thinking that doing these would be much more computationally expensive.

Yeah, they could be done that way. At the moment, the target selection logic only happens a couple of times per second anyway, so they could be done a few physics frames in advance without any issue.

If I do get around to implementing this sort of thing in BDA+, then to avoid making EVE redux a hard dependency, I was thinking it could be done via reflection using delegates (in the same way that CameraTools does with BDA+ (ReflectionUtils.cs), which works fairly well), however that would require EVE redux to provide some functions for doing so. Since it'd be asynchronous, I think there'd need to be one for initiating the check and another to check if the results are ready and fetch them since I'm not sure if it's possible to use a coroutine that way.

That sounds good, I can provide the function for doing this. Oh btw I forgot to mention but this kind of async GPU access is Directx 11 only (so windows or linux with dxvk), is that still ok?

I think we could just do a single function, to which you pass a callback as a parameter, and it just executes your callback with the data when it's ready.

Edited October 31, 2022 by blackrack

[DocNappers]

2 minutes ago, blackrack said:

That sounds good, I can provide the function for doing this. Oh btw I forgot to mention but this kind of async GPU access is Directx 11 only (so windows or linux with dxvk), is that still ok?

That's a shame since I run KSP natively on linux instead of via dxvk, which would make testing it difficult. If it can be made to work, then I'd make it an optional toggle in BDA+ anyway, so if it's not supported, then it can be disabled without any drawback.

2 minutes ago, blackrack said:

I think we could just do a single function, to which you pass a callback as a parameter, and it just executes your callback with the data when it's ready.

I think that should work, but I'd have to experiment a bit with the delegates to check that it works as expected.

[RW-1]

7 hours ago, blackrack said:

 

Beautiful!  "Memories ...."

 

Of course, Jeb didn't Land back at KSC either hehehe ...

[WarriorSabe]

3 hours ago, blackrack said:

Considering I do these checks for  460800 pairs of points currently (2560x1440 / 8) per regular frame, 28 per physics-frame shouldn't be an issue.

Oh, that does bode a little more well for my prospects of running this; I only have a 1080p display, so that'd be only about half as many checks and so would help to narrow the margins a bit. Which actually gives me the idea; would it be possible to add a setting to reduce the sampling resolution (with some interpolation between or something for smoothing) to increase performance, or would the cost of the smoothing cost more than the gains from performing fewer samples?

[blackrack]

14 hours ago, DocNappers said:

That's a shame since I run KSP natively on linux instead of via dxvk, which would make testing it difficult. If it can be made to work, then I'd make it an optional toggle in BDA+ anyway, so if it's not supported, then it can be disabled without any drawback.

I think that should work, but I'd have to experiment a bit with the delegates to check that it works as expected.

Alright, I could implement it later on the CPU and be compatible with more systems, but it will come later on as it requires more work.

11 hours ago, WarriorSabe said:

Oh, that does bode a little more well for my prospects of running this; I only have a 1080p display, so that'd be only about half as many checks and so would help to narrow the margins a bit. Which actually gives me the idea; would it be possible to add a setting to reduce the sampling resolution (with some interpolation between or something for smoothing) to increase performance, or would the cost of the smoothing cost more than the gains from performing fewer samples?

So, I'm already running it at 1/8 native resolution which I consider to be the best performance/quality ratio, it can be done at 1/16 but the quality suffers although on static scenes it looks mostly ok. I don't expose a 1/32 setting or further lower settings as by then the image suffers a lot and becomes an incoherent mess, especially in motion.

This reduces the number of overall pixels raymarched, the number of samples taken during raymarching can be lowered as well, as well as light samples, both trade speed for noise. You can improve the performance a lot if you can accept noise, especially on thin clouds. I can't say how pleasant it will be though.

Edited November 1, 2022 by blackrack

[DocNappers]

1 hour ago, blackrack said:

Alright, I could implement it later on the CPU and be compatible with more systems, but it will come later on as it requires more work.

Yep, no worries. It's something that I was considering as a potential option for BDA+ due to the requests I received, but it's not high priority. Give me a ping if/when you have something ready to test and I'll see if I can get it to work. Thanks!

[KSACheese]

Hey, blackrack, quick question about EVE: Volumetrics, do you plan to integrate the behavior of the clouds with the weather present below? I.E. will an appropriate rain cloud develop when there is rainy conditions below? Or will it just be random clouds that present with weather?

Just curious. Thanks!

[blackrack]

37 minutes ago, KSACheese said:

Hey, blackrack, quick question about EVE: Volumetrics, do you plan to integrate the behavior of the clouds with the weather present below? I.E. will an appropriate rain cloud develop when there is rainy conditions below? Or will it just be random clouds that present with weather?

Just curious. Thanks!

I will configure it so that rain mostly appears under the thicker/bigger clouds, however I'm not going to morph random clouds into big ones, at least not in the first version.

[blackrack]

Was messing around with fog

Spooky KSC

What you see in the afterlife:

I should add that raymarching shadows like this is very expensive to get good quality, so won't be enabled by default, unlike the cloud godrays which are diffuse and more forgiving to large step sizes.

Edited November 1, 2022 by blackrack

[kerbalboi]

looking amazing! can't wait to use it!

[WarriorSabe]

2 hours ago, blackrack said:

Was messing around with fog

Spooky KSC

What you see in the afterlife:

Your work continues to amaze. I wonder, since you've always shown the plane without it, does it work with Waterfall? Main worries would be render order and whether the heat distortion effects mesh with the raymarches.

Edited November 1, 2022 by WarriorSabe
fixed cat stepping on keyboard effects

[blackrack]

41 minutes ago, WarriorSabe said:

Your work continues to amaze. I wonder, since you've always shown the plane without itl;pp, does it work with Waterfall? Main worries would be render order and whether the heat distortion effects mesh with the raymarches.

Thank you. I haven't tested it but it should work fine, if it works with scatterer it should work with this.

Edited November 1, 2022 by blackrack

[qromodynmc]

Oh man it looks amazing! I never thought i'd see ksp this beautiful..

[LHACK4142]

OK so I had a weird idea for visible raindrops that's probably been considered already, but I thought I might just post it. If rain goes 10m/s, maybe you could find the ratio of rain speed to camera/aircraft (which I'll call r) then orient a cylinder such that it is facing r of the way to the direction of the aircraft. The cylinder would either stay pretty much stationary or have an animated texture. IDK if that made much sense but I hope I could at least get the basic idea through.

In other words, if the raindrops are going n% the speed of the camera, make the cylinder n% vertical and 100-n% prograde.

Edited November 2, 2022 by LHACK4142
added in other words part

[InfoTheGamer]

@blackrackIs the new volumetric system more GPU intensive or more CPU intensive? Right now with current EVE and a decked out RSS/RO save, I have 95% GPU usage and 40% CPU with a 1080ti and 3950x. The fog btw is incredible and I can't wait to see dust on Mars.

[Spaceman.Spiff]

8 hours ago, blackrack said:

I should add that raymarching shadows like this is very expensive to get good quality, so won't be enabled by default, unlike the cloud godrays which are diffuse and more forgiving to large step sizes.

Does that take advantage of dedicated raytracing hardware that’s on some GPUs?

[Poodmund]

17 hours ago, blackrack said:

Was messing around with fog

An effective solution to have thick fog like this, for a decent altitude range, would be the cherry on top.

[blackrack]

15 hours ago, LHACK4142 said:

OK so I had a weird idea for visible raindrops that's probably been considered already, but I thought I might just post it. If rain goes 10m/s, maybe you could find the ratio of rain speed to camera/aircraft (which I'll call r) then orient a cylinder such that it is facing r of the way to the direction of the aircraft. The cylinder would either stay pretty much stationary or have an animated texture. IDK if that made much sense but I hope I could at least get the basic idea through.

In other words, if the raindrops are going n% the speed of the camera, make the cylinder n% vertical and 100-n% prograde.

Actual particles would be better than this though.

12 hours ago, InfoTheGamer said:

@blackrackIs the new volumetric system more GPU intensive or more CPU intensive? Right now with current EVE and a decked out RSS/RO save, I have 95% GPU usage and 40% CPU with a 1080ti and 3950x. The fog btw is incredible and I can't wait to see dust on Mars.

Only GPU intensive.

8 hours ago, Spaceman.Spiff said:

Does that take advantage of dedicated raytracing hardware that’s on some GPUs?

Nope, this is just raymarching and checking the shadowmaps at every step.

16 minutes ago, Poodmund said:

An effective solution to have thick fog like this, for a decent altitude range, would be the cherry on top.

It's already a thing, and runs very well as long as you disable object/terrain shadows on it. See the previous posts with rain and large scale fog.

Edited November 2, 2022 by blackrack

[KSACheese]

2 hours ago, blackrack said:

Only GPU intensive.

Finally, a use for my 3080!

[blackrack]

1 minute ago, KSACheese said:

Finally, a use for my 3080!

Better get a 4090, so you can (maybe) run this without temporal upscaling.

[RW-1]

Another reason to upgrade my GPU, let alone3 system, another 7 years has passed since I last toyed with it, ugh!