Flare Occlusion Performance Issues

[Clayell]

According to @JonnyOThan (sorry for the ping, but I think this is relevant), sometime between v2.0.3.1 and the current v2.2.0.2, a significant performance impact was introduced. Jonny states it here (r/KSP server):

I forked the version of DOE before lisias started maintaining it and fixed some stuff that was slow
I only really tested vessel and body flares and the skybox dimming, I'm not sure how well viewing distant vessels works
but the flare code in the existing versions is real bad

Multiple people in the server have corroborated his performance impact claim, so I think this is something that should be investigated. Potentially something to do with flares?

I have no context on this issue, I have simply gathered information that I have heard from others.

[Lisias]

I had forked the mentioned project here:

https://github.com/net-lisias-kspw/DistantObjectEnhancement

And, at this time, there is not a single commit touching any code. NOT A SINGLE LINE OF CODE was touched.

I compiled the damned thing and found no difference on my rig.

I can't fix what is not broken.

[Clayell]

I don't think you understood what I was saying. Jonny forked the v2.0.3.1 version, and found it to be more performant than v2.2.0.2. (not sure what he meant by fixed some stuff that was slow, maybe it was on a local fork?) Paging @JonnyOThan

[Lisias]

I don't think you understood what I was saying. Jonny forked the v2.0.3.1 version, and found it to be more performant than v2.2.0.2.

Now I see. I willl do some tests on the next FdS.

How faster is the older versions? How many FPS more you get from it? Where are the benchmarks?

How do YOU know the newer versions are slower then the older? YOU are the one opening this ticket after all.

(not sure what he meant by fixed some stuff that was slow, maybe it was on a local fork?)

That's the problem: claims without ground. He did fixed something? Where is the code?

[Lisias]

I have no context on this issue, I have simply gathered information that I have heard from others.

I finally noticed this paragraph. I redacted part of my last post due it.

But, yet, do you have how to measure FPS in your rig? It would be nice to have some concrete information around here instead of having to use my scarce time chasing potentially groundless claims.

[Clayell]

It would be nice to have some concrete information around here instead of having to use my scarce time chasing potentially groundless claims.

Completely fair. I'll do some investigating of my own to see a performance difference, and I'll DM Jonny.

[Lisias]

@Clayell ,

I took one of my 1.4.3 test beds and made this very minimalistic and completely bogus test - it's not a controlled environment, Kraken knows what I had done on the debug mode add'ons installed on the damned installment

I installed ShowFPS and fire up a new savegame in sandbox. Launched an AeroEqus at night and checked the FPS.

KSP.log

benchmark_doe.zip

Got 46.6 FPS at night on pretty crappy MacPotato 6.2 (I7 Mobile 2012, Intel HD4000, 16GB RAM).

---

Now I installed the latest DOE, and using everything on the default settings (deleted any DOE related user configurations on the installment), loaded the same savegame and checked the FPS.

AAAAND.... I got 48.6 FPS!!!!!

Don't ask, I didn't changed anything in the KSP guts to make it "faster" - as a matter of fact, I'm kinda worried about... 😜

But one thing that I noticed is that the FPS is not constant, it drops a bit sometimes, getting as low as 20FPS when I do 3 or 4 consecutive screenshots.

When using ALT+RIghtClick, displaying the Bodie's Names as Labels in the sky, the FPS changes constantly between 44 and 60.0 FPS (!!!!) 😱 ***

---

Soooo...

I need detailed information about what's performing badly, where and how.

Also, keep in mind that if you have distant vessels activated with all unloaded vessels and have dozens of vessels alive, then OBVIOUSLY your FPS will plummet because DOE will try to draw all of them. Previous versions of DOE were more restrictive about vessels you can draw and, obviously, will "perform better" compared to newer DOE configured to draw way more vessels with a huge amount of vessels around because it will have more work do do!!!

---

I decided to do not test older DOE at this point. It's more then obvious that under normal (or near it) circumstances "my" DOE IS NOT screwing performance on the target rig.

---

Hardware used:

---

*** I toyed a bit more, and I know why I got 60 FPS out of nowhere : I was looking up, and with less ground to be drawn, obviously my FPS increased a bit.

Additionally... I did some tests at day time, and depending on where I'm looking into my FPS plummet to 20 to 30 (with and without DOE). Drawing the blue skies on Sunny Hours appears to be pretty expensive on my MacPotato!

[Lisias]

I'm going to destroy the test bed for development of something else, so I decided to do a new test - this one on orbit.

WITH DOE

I got 59.8 and 60 FPS consistently on the following scene (with and without labels):

benchmark_doe.zip

KSP.log.zip

WITHOUT DOE

Exactly the same results. 59.8 to 60 FPS.

benchmark_doe.zip

KSP.log.zip

[Lisias]

@Clayell do you have something to share?

[Clayell]

I am currently busy with IRL stuff. I'll test this when I get the chance.

[Lisias]

I am currently busy with IRL stuff. I'll test this when I get the chance.

Perfectly understandable. It's already hard to find time to implement new features and fix bugs that will effectively benefit users, what to say about potentially groundless allegations where people that are asking for the "improvement" don't use a second from their own lives to provide any kind of evidence that could support their claims?

[Clayell]

Jonny apparently had issues commenting in the thread, so I'll post their response here.

Hey, I'm not sure what happened with the KSPModStewards fork. I was never really intending to adopt this mod but people kept hounding me for the faster build so I threw something up there. Indeed, all the changes were on my local git repo and not pushed to github - I think possibly because I had changed the branch name from master to main. anyway...

I don't think the original fork was any faster than the current one. The worst part of the code is the stuff I removed in this commit and it was already existing previously.

I can't recall how significant any of the other changes were, but the above bit sticks out like a sore thumb in a profiler.