Jump to content

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


blackrack
 Share

Recommended Posts

@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?

Link to comment
Share on other sites

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

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.

Link to comment
Share on other sites

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

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

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!

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Was messing around with fog

Ffb6Vfb.png

NhVDlet.png

Spooky KSC

CDbj2Jz.png

S4oWuMc.png

JwV9MYe.png

What you see in the afterlife:

ymRgP5q.png

tuhggoy.png

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

2 hours ago, blackrack said:

Was messing around with fog

Ffb6Vfb.png

NhVDlet.png

Spooky KSC

CDbj2Jz.png

S4oWuMc.png

JwV9MYe.png

What you see in the afterlife:

ymRgP5q.png

tuhggoy.png

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 by WarriorSabe
fixed cat stepping on keyboard effects
Link to comment
Share on other sites

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

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 by LHACK4142
added in other words part
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 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.

 Share

×
×
  • Create New...