Bad performance with mods (1.2.2 and 1.2.9)

[Tau137]

So, I finally came back to playing KSP, gradually and carefully built my mod list... only to realize that the game is unplayable with my mod setup (nothing excessive, mind you - all fits under 2Gb).

I have not "the latest and greatest" but still a pretty decent CPU, GTX780, 16G ram.

EDIT:  Removed "observations from prior versions" comment because I did proper testing with 1.1.3 and found that it was just false memory on my part - tendencies are the same in terms of slowness (except that 1.1.3 is ~25-30% slower overall).

 

Now in 1.2.2 (identical behavior in 1.2.9, at least for those mods that work with it) I see huge performance hits.  Example: a 300-part airplane on the runway:

1. Full stock: 50fps, down to 35 over ocean (btw, why such a drastic drop in fps, when there is little to render and nothing has changed in physics/parts?)

2. Scatterer: 48-35 fps

3. Scatterer + Kopernicus + SVT: 41-29 fps

4a. SVE + SVT (+EVE, Kopernicus, Scatterer)): 21-12 fps

4b. Same mods, but flying Aeris 3a: 60-44 fps (!!!)

5. KJR only: 31-12 fps (!!)

So, these are heavy visual mods and one physics mod, so one would expect a performance hit (even though it was not nearly as noticeable in 1.1.3).  BTW, at no point do I get 100% CPU core usage - at most it goes up to ~75%, with a couple more cores at ~25-30%.  Graphics is definitely not the bottleneck either (see 1 and 4a/b above).

 

So, what if we install a few essential and light-weight mods that should, in theory, have minimal impact on in-flight performance?

6a. MM, Toolbar, Better burn time, Better time warp, KAC, CCK, CRP, CTT, AGX, EasyVesselSwitch, EditorExtensions, KAS, KIS, MechJeb2, Docking alignment, Vanguard Parachutes, no KJR, same 300-parts airplane: 31-25fps (just a reminder - 50-35fps in pure stock).

6b. Same mods, but flying Aeris 3A: 60 fps (limit!!!).

 

At some point I tended to blame the total memory footprint as being the culprit, but it does not seem to be the case - although total RAM consumption and part count (existing in game, not on vessel on in the scene) does have some effect, it is nothing compared to number of mod DLLs installed.

Conclusion: what (tf) is going on here?  Why mods that should not work on per-part basis (visual enhancements, utility non-physics mods) slow the game down proportionally to the size of the craft?  And even if, for some bizarre reason, they are called on each part, why the execution is so slow for what is essentially just a few lines of code (from my long-past days of hands-on programming, this feels like every call to third-party procedures is wrapped in several layers or extreme debug exception handling - btw, no exceptions reported in the log)?

Do you experience something similar, or perhaps you have 200 mods and more than 5GB in GameData folder and yet everything runs just as smoothly as in stock?  Either way, please report your experiences here (keep it civil, avoid excessive quoting, and include your rig configuration and specific test results if available).

 

Edited May 8, 2017 by Tau137

[Ruedii]

There are two possibilities. 

First: One of these mods is obsolete and is thus throwing an exception on a regular interval.  (I know Vanguard parachutes is obsolete and has been replaced with a community drop in     replacement mod. This might be your problem.)  This should show up in the log (Under the dubug menu, same menu as the cheats).  Toolbar is also undermaintained, and uses the old "legacy" GUI which always bogged things down but now causes massive slowdown in KSP 1.2 and later.  (Also, double check that you have the latest Mechjeb2 version.  Older versions also use Legacy GUI.)

Second, you have a mod creating a lot of garbage due to changes to the version of Unity3D (The dev-kit used to make KSP).

GC Cycles are memory bottlenecked and operate solely on the main thread (thus only use one core).  During this process all other parts of the game are temporarily stopped.  Under normal situations these cycles are so quick you don't notice them, but when a mod is using a lot of script variables instead of using static assets, it has much more to check, and often much more to clean up. 

You can check if it's the GC by checking the performance tab.  This will provide you with a chart of the memory usage and frame rate info.  The memory should be a sawtooth pattern.  If, instead you see frequent huge spikes that occur right before the stutters, that is a garbage issue.

Either way, the first thing I recommend is checking that all your mods are updated.  Sometimes, as is the case with Toolbar, the mod is no longer necessary, or you may need to find the community update.

I have a few of them for you already:

EVA Parachutes: https://spacedock.info/mod/991/EVA Parachutes %26 Ejection Seats
Mechjeb2: https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/
Editor Extensions: https://spacedock.info/mod/48/Editor Extensions Redux
KIS (with links to KAS):

 

[Tau137]

8 hours ago, Ruedii said:

First: One of these mods is obsolete and is thus throwing an exception on a regular interval.

Second, you have a mod creating a lot of garbage due to changes to the version of Unity3D (The dev-kit used to make KSP).

GC Cycles are memory bottlenecked and operate solely on the main thread (thus only use one core).  During this process all other parts of the game are temporarily stopped.  Under normal situations these cycles are so quick you don't notice them, but when a mod is using a lot of script variables instead of using static assets, it has much more to check, and often much more to clean up. 

You can check if it's the GC by checking the performance tab.
 

First - not applicable, all mods are latest and greatest, compiled for 1.2.2 (the only exception is KJR, 1.2.0).  I guess I should have stated that in the first place, but I presumed that to be self-evident (for every self-respecting and at least somewhat experienced KSP player).

Second - reasonable assumption, but I cannot localize ONE single mod(s), and there is no garbage in the output log (does not negate your argument completely, but still) - it looks like EVERY SINGLE mod I add creates more problems/slowdown (I can even see slowdown on high-partcount ships with just KAC(!) installed).

GC Cycles... does not help me to understand why the performance is so abysmal on my rig, while not being neither graphically nor CPU bound.  Surely, if I have a mod that is not optimized and, on every cycle, keeps pulling a lot of info or doing a lot of stuff - that could be a culprit.  But how would a visual enhancement mod (textures, clouds, shaders) be so much slower on a large ship compared to a small one (even though the mod has nothing to do with object interaction aka "physics", and there is a plenty of other objects/vertices to render in the scene, so part count on the vessel should not matter that much - after all, somehow I get better fps flying around KSC compared to flying over the ocean with nothing in sight)?

BTW, comparing frame rate in flight scene vs. map view (while flying) - map view is better, but not by much (~25-50% fps difference), so looks like it's mostly in physics and/or external (mod) calls - still somehow dependent on physics/partcount.

Performance tab in KSP is a big lier - actual numbers (as reported by Windows and NVidia) are quite a lot different (significantly lower fps, significantly higher actual RAM consumption; and the performance tab tends to freeze often, showing nothing after a while).

Anyhow, the idea of this topic was not to try to discredit one's observations/experience, but rather to collect more of them (preferably supported by not just "feelings" but actual recorded/verifiable numbers) to be able to make any sort of fact- and statistics-based conclusions - to (hopefully) bring this issue to the developers' attention.

In other words, are you in a similar (mod-wise) situation to one of those described above?  If so, what are your benchmarks compared to stock game?  At what PC specs? 

THAT is what I would like to see in this thread, and would greatly appreciate if the (mostly) irrelevant arguments were kept out, despite the oh-so-sweet urge to comment

 

Edited May 2, 2017 by Tau137

[Bornholio]

Are you running in Dx11 mode? Make sure its 64bit.  (KSP_x64.exe -single-instance -force-d3d11)

I'd suggest running Memgraph mod.  Make sure you learn the hotkeys (alt *) and read its usage OP.

Large part count i move on to using Welding mod to get rid of unneeded part complexity. Again read the OP for the mod or you will make mistakes.

[Tau137]

On 5/2/2017 at 7:38 PM, Bornholio said:

Are you running in Dx11 mode? Make sure its 64bit.  (KSP_x64.exe -single-instance -force-d3d11)

I'd suggest running Memgraph mod.  Make sure you learn the hotkeys (alt *) and read its usage OP.

Large part count i move on to using Welding mod to get rid of unneeded part complexity. Again read the OP for the mod or you will make mistakes.

Thank you for the tips, I will check out Memgraph.

I always run x64, but not forcing DX11.  I should test DX11 and OGL and see if that makes any difference.

My main concern is that even utility mods slow the came down in proportion to part count (how clouds can be so much slower on 300 part ship vs 10-part ship?  Why it is noticeably slower with just Alarm Clock?) - the rest is kind of self-explanatory, given that any improvement demands some performance sacrifice.

UboWelding - I use it occasionally, but its limitations (graphical for animated parts, and need to restart the game - and that takes at least 5 minutes with my 2GB mod setup... with the game installed on SSD) make it not ideal for routine tasks, mostly useful for one-of-a-kind space station or IP mission (and those I tend to assemble in space with KIS and Konstruction, and would like to start utilizing GroundContsruction more, but it has one annoying glitch that throws exceptions on part count changes).

Edited May 8, 2017 by Tau137

[Diddly Feelerino]

Hey; just logging to post. I too encountered a similar problem (running KSP 64-bit); when I played last month the game (or a mod) appeared to have a memory leak of some sort, but only on the Launchpad. Once you hit the Launch key the FPS returned to normal. I also got a significant drop going through the cloud layer in SVT-Scatterer. Was bad enough to make me quit last month.

All this on an ASUS G752VS (16GB RAM, 64-bit, I7-1600Q, GTX1070).

[DrLicor]

Just to give extra information here:
For me, and several others, DX11 has a higher change on causing graphic glitches than for your game to open in OpenGL mode.
For RSS/RO, DX11 sometimes has the behaviour to glitch with the horizon. However, the game runs smoother for me with a install of 9.15GB at the moment using DX11.

Another thing: KSP isn't optimised for multicore processing. An i7 is offcourse fast and efficient, but when it has those 8 cores, it won't do better than a i5 with 4 cores and exact the same hertz. KSP will only use on or 2 cores for the main proccesing and so do most games. A few games are multicore optimized. In case of the ASUS laptop @Diddly Feelerino has, this doesn't count, since that i7 has 4 cores. 

KSP is a game that's pulled by RAM and CPU, GPU is only a bit important when running heavy visual mods, but will not be the main reason frames drop, a GTX1050 is even overpowered. A powerfull GPU comes handy with games like Battlefield, Crysis, Total War etc. KSP's energy goes mostly to calculation stuff.

It's indeed a pitty that the engine works the way it does, that it has to calculate everything per part. But for games like this, I don't see another way I think.
For now, I'm okay with reloading the game completely for the sake of welding parts together, I grab a coffee, take the dog for a walk or just bring a little visit to the toilet. It helps me to take a break from the game sometimes.  
And most of the time I reuse my launch vehicles either way.

[Diddly Feelerino]

Thanks for the feedback.

I figured the CPU might bottleneck performance, but to cause significant lag with a relatively low part count? Not to mention the inexplicable mem leak on Launchpad.

I'll try redownloading the core mods and reinstalling - it's been a while since I've played and maybe the leaks have been sorted.

[Ruedii]

On 5/1/2017 at 2:36 PM, Tau137 said:

First - not applicable, all mods are latest and greatest, compiled for 1.2.2 (the only exception is KJR, 1.2.0).  I guess I should have stated that in the first place, but I presumed that to be self-evident (for every self-respecting and at least somewhat experienced KSP player).

Second - reasonable assumption, but I cannot localize ONE single mod(s), and there is no garbage in the output log (does not negate your argument completely, but still) - it looks like EVERY SINGLE mod I add creates more problems/slowdown (I can even see slowdown on high-partcount ships with just KAC(!) installed).

GC Cycles... does not help me to understand why the performance is so abysmal on my rig, while not being neither graphically nor CPU bound.  Surely, if I have a mod that is not optimized and, on every cycle, keeps pulling a lot of info or doing a lot of stuff - that could be a culprit.  But how would a visual enhancement mod (textures, clouds, shaders) be so much slower on a large ship compared to a small one (even though the mod has nothing to do with object interaction aka "physics", and there is a plenty of other objects/vertices to render in the scene, so part count on the vessel should not matter that much - after all, somehow I get better fps flying around KSC compared to flying over the ocean with nothing in sight)?

 

First, I know for a fact you are mistaken on that one.  Specifically Vanguard Parachutes is not available for 1.2.2 specifically due to exception errors.  There is a complete from-scratch rewrite that I provided a link to.

Second, Things don't necessarily appear in the output log as far as you can tell.  NRE Exceptions and bad call exceptions only appear in the Unity Player.log, not the KSP's output log, and definately not the Operating System output log.

Finally, if you don't know what GC problems are, then don't question me about it.  GOOGLE IT!  I'm not going to explain basic computer concepts to someone.  Let's just say KSP isn't the only game affected.

GC operations are memory-bandwidth bound on the main thread, meaning one CPU will be running at about 1/4-1/2 capacity, shutting down all background activity by the game engine.  I can go into detail about Unity's archaic GC engine but you can find plenty of complaints about that online as well, and even some articles from last (finally) fall promising a fix "soon."  You may notice this is a topic that makes me irate, because I know there is nothing Squad can do about it without paying a fortune to have Unity create a replacement GC at top priority.

Anyways, KSP does not support multithreading on all operations, especially with mods.  (Many mods are called in manners that create world-freezes this stops all background activity.   This is something that can only be fixed by the mod developer or a contributor who knows coding if the mod is open source.)

As a note, for the person who is having trouble with Kerbal Alarm Clock, there is one function that can be quite heavy on KAC that can be fixed.  By turning down the update times of certain things in the options for KAC you can drastically improve performance.  I'm thinking of filing a request to put the mod on a timer other than the frame timer to boost performance, and to move as much of it as possible to a helper thread.  I need to look up the exact timer call to completely offload it to a helper thread.

[Tau137]

10 hours ago, Ruedii said:

First, I know for a fact you are mistaken on that one.  Specifically Vanguard Parachutes is not available for 1.2.2 specifically due to exception errors.  There is a complete from-scratch rewrite that I provided a link to.

Second, Things don't necessarily appear in the output log as far as you can tell.  NRE Exceptions and bad call exceptions only appear in the Unity Player.log, not the KSP's output log, and definately not the Operating System output log.

Finally, if you don't know what GC problems are, then don't question me about it.  GOOGLE IT!  I'm not going to explain basic computer concepts to someone.  Let's just say KSP isn't the only game affected.

GC operations are memory-bandwidth bound on the main thread, meaning one CPU will be running at about 1/4-1/2 capacity, shutting down all background activity by the game engine.  I can go into detail about Unity's archaic GC engine but you can find plenty of complaints about that online as well, and even some articles from last (finally) fall promising a fix "soon."  You may notice this is a topic that makes me irate, because I know there is nothing Squad can do about it without paying a fortune to have Unity create a replacement GC at top priority.

Anyways, KSP does not support multithreading on all operations, especially with mods.  (Many mods are called in manners that create world-freezes this stops all background activity.   This is something that can only be fixed by the mod developer or a contributor who knows coding if the mod is open source.)

As a note, for the person who is having trouble with Kerbal Alarm Clock, there is one function that can be quite heavy on KAC that can be fixed.  By turning down the update times of certain things in the options for KAC you can drastically improve performance.  I'm thinking of filing a request to put the mod on a timer other than the frame timer to boost performance, and to move as much of it as possible to a helper thread.  I need to look up the exact timer call to completely offload it to a helper thread.

1. Irrelevant, as it does work.  Also irrelevant because it was not used it the test cases presented.

2. Yep, never argued that.

3. Google!  Yes, I never realized it exists, thank you!

KAC: this one was brought up as an example of a mod that should not be affected by part count, and yet there is a noticeable hit.  Same way as EVE, in theory, should have a "constant" (not dependent on part count) performance hit.

 

Let's consider this simple example: stock vs. visual mods (EVE+Kopernicus+SVT), huge craft.

Let's further simplify that each frame game spends most of cycles on graphics and physics.

STOCK: 50fps, 20ms per frame. P+Gc+Gu=20 (Physics, Graphics-craft, Graphics-universe)

MOD: 20fps, 50ms per frame. P+Gc+MGu=50 (modded graphics - universe).  Result: MGu >= 30ms

Now let's fly the simplest smallest craft possible (P2+Gc2 << P+Gc):

MOD: 60fps, <17ms per frame.  P2+G2 + MGu = 17.  Result: MGu <= 17ms

Anyone else noticed an inconsistency?  Somehow the mod graphics (terrain & clouds) work twice as slow for 300 part ship vs. 10-part ship!  Or we have to assume that somehow Physics depends on the presence of modded graphics.  Either - or, as these mods do not touch physics or craft rendering.

Some might say (or direct me to Google) something regarding 3D rendering and how it is done and why computational complexity of drawing an object within a background scene would be affect by the way background is drawn.  True, but only partially, and most importantly.... absolutely irrelevant to the argument, as the performance problem remains even in map view with almost nothing to render!

Now, what else have we missed so far that can explain this?  Perhaps collisions (Kopernicus), that could explain it.... except it does not, because the same behavior is evident without Kopernicus, with just EVE, or with a bunch of mods that have nothing to do with part count whatsoever, and yet each adding a bit of lag on per-part basis!  I do not have fps numbers handy for these - I might have time to get those, too, and I encourage everyone to test this "assumption" themselves!

Conclusion: physics (or something else related to part-count) is somehow affected by presence of graphics (and other) mods.  This means that something out of these mods is being called in each physics processing iteration!

And THAT is the problem I am trying to bring up here.  So, instead of misdirecting and implying my utter incompetency (it is only partial, not total), would you be willing to run similar tests and present results here?  The purpose is to either:

1. Prove that the problem is specific to my computer and vast majority of users are not affected.  If that is the case, I'll gladly admit that it is "my" problem, and will shut up.

2. Bring more factual confirmation that the problem does exist.  Perhaps it is Squad coders' mistake, perhaps it is an inherent Unity issue - I do not know (again, Unity and C# programming is definitely not my strong sides), but that is even more reason to get devs' attention - in the interest of all players, especially those who actually do extensive career and exploration sessions and build ships and stations with hundreds of parts, those who love the game and want to make it better - even if all they are able to put in the pot is a few tests and observations.

[diomedea]

KSP being a Unity based game, makes use of whatever libraries Unity includes. One such library is PhysX (now version 3.3) that devolves to a nVidia GPU most of the physics calculations. The more parts with a vessel, the more physics calculations per frame. A GPU is actually a very powerful parallel computing unit, using it to save CPU cycles is generally a good choice; however KSP is a lot heavier than other games when it comes to physics, having lots more interactions among parts (or with ground, water, atmosphere). The result is the GPU is often loaded way more than advisable and, concurrently with its true graphical tasks, can become the real bottleneck.

I do use Process Explorer to keep track of resource usage while KSP is running (and even when not). One good feature of Process Explorer over other similar apps (e.g. Task Manager) is to show the % of GPU used in real time by any application, not only of CPU, RAM, or else. I have a nVidia GPU and guess what? when KSP is running with even a low partcount vessel, even without anything graphical to show (as when orbiting without looking at any object) the GPU% is at least double than the CPU%. Proof without doubt of the GPU being effectively charged with those PhysX calcs, not the CPU.

On the other side, KSP doesn't use more than one CPU core unless it can make use of different threads (like when dealing with more vessels). With that same app is fairly easy to check each one of the threads started by KSP; there is always one that makes up the largest part (by far) of all CPU cycles (should it alone arrive to a CPU% = 100% / CPU cores, it would create lag); add-ons also add to that thread unless effectively using multithreading.

Indeed, one could think there are some inherent Unity issues when CPU or GPU usage is not optimized. Maybe Squad could find new ways to improve over the basic multithreading Unity offers, or to reduce Physics computations when not really required, or else.

[Ruedii]

On 5/11/2017 at 11:30 AM, Tau137 said:

1. Irrelevant, as it does work.  Also irrelevant because it was not used it the test cases presented.

2. Yep, never argued that.

3. Google!  Yes, I never realized it exists, thank you!

KAC: this one was brought up as an example of a mod that should not be affected by part count, and yet there is a noticeable hit.  Same way as EVE, in theory, should have a "constant" (not dependent on part count) performance hit.

 

Let's consider this simple example: stock vs. visual mods (EVE+Kopernicus+SVT), huge craft.

Let's further simplify that each frame game spends most of cycles on graphics and physics.

STOCK: 50fps, 20ms per frame. P+Gc+Gu=20 (Physics, Graphics-craft, Graphics-universe)

MOD: 20fps, 50ms per frame. P+Gc+MGu=50 (modded graphics - universe).  Result: MGu >= 30ms

Now let's fly the simplest smallest craft possible (P2+Gc2 << P+Gc):

MOD: 60fps, <17ms per frame.  P2+G2 + MGu = 17.  Result: MGu <= 17ms

Anyone else noticed an inconsistency?  Somehow the mod graphics (terrain & clouds) work twice as slow for 300 part ship vs. 10-part ship!  Or we have to assume that somehow Physics depends on the presence of modded graphics.  Either - or, as these mods do not touch physics or craft rendering.

Some might say (or direct me to Google) something regarding 3D rendering and how it is done and why computational complexity of drawing an object within a background scene would be affect by the way background is drawn.  True, but only partially, and most importantly.... absolutely irrelevant to the argument, as the performance problem remains even in map view with almost nothing to render!

Now, what else have we missed so far that can explain this?  Perhaps collisions (Kopernicus), that could explain it.... except it does not, because the same behavior is evident without Kopernicus, with just EVE, or with a bunch of mods that have nothing to do with part count whatsoever, and yet each adding a bit of lag on per-part basis!  I do not have fps numbers handy for these - I might have time to get those, too, and I encourage everyone to test this "assumption" themselves!

Conclusion: physics (or something else related to part-count) is somehow affected by presence of graphics (and other) mods.  This means that something out of these mods is being called in each physics processing iteration!

And THAT is the problem I am trying to bring up here.  So, instead of misdirecting and implying my utter incompetency (it is only partial, not total), would you be willing to run similar tests and present results here?  The purpose is to either:

1. Prove that the problem is specific to my computer and vast majority of users are not affected.  If that is the case, I'll gladly admit that it is "my" problem, and will shut up.

2. Bring more factual confirmation that the problem does exist.  Perhaps it is Squad coders' mistake, perhaps it is an inherent Unity issue - I do not know (again, Unity and C# programming is definitely not my strong sides), but that is even more reason to get devs' attention - in the interest of all players, especially those who actually do extensive career and exploration sessions and build ships and stations with hundreds of parts, those who love the game and want to make it better - even if all they are able to put in the pot is a few tests and observations.

How about you not question my competence to begin with?  I only replied at the start to be nice.

The probem IS in Unity, and if you search Unity GC issues you would find thousands of articles on it.

Instead of trying to accept a person's help you are picking a fight with them, WAY TO GO!

[Tau137]

14 hours ago, Ruedii said:

How about you not question my competence to begin with?  I only replied at the start to be nice.

The probem IS in Unity, and if you search Unity GC issues you would find thousands of articles on it.

Instead of trying to accept a person's help you are picking a fight with them, WAY TO GO!

Thank you for your insightful and extremely informative response, it is greatly appreciated!

[diomedea]

Unless all posters show to abide to forum rules from now on (in particular rule 2.2.d. " Insults and threats, stalking, bullying or any other behavior construed to be of a potentially rude, slanderous, accusatory, combative or otherwise harassing nature to/of another person "), this thread is going to be closed.

Now, can everybody drop personal attacks and spicy replies?

 

@Tau137, you have stated a number of times you intend this thread to collect data about users experience with lag-inducing add-ons. Please note you can't avoid other users to discuss the method and validity of the idea itself, as indeed ignoring what causes lag or why a system may slow down at times can only give useless readings. Knowledge of the possible factors with anything observed is the basis for building a valid theory, based on scientific grounds. Only once the method to take readings (and isolate possible concurrent factors) is properly defined, data collected following that method will be of value; data "taken in the wild" may only feed false beliefs about something being wrong. Of course spreading false ideas isn't welcome on this forum.

If you don't like to have those factors discussed as happened above, then what will come from data collected? Will they be used to pressure modders to improve add-ons while isn't their fault?

 

[Tau137]

@diomedea Thanks for the voice of reason.  On my part, I will try to be less passive-aggressive.

Edited May 15, 2017 by Tau137
typo corrected

[Akira_R]

@Tau137Just a wild theory here.

So while the GPU doe the main work of rendering what you see, the CPU still has to tell the GPU what to render and how, from my limited understanding these are draw calls and they can be very CPU intensive and usually make up a fair chunk of the CPU load in a game. My theory is that the added graphical mods increase the number of draw calls, now I know that for a single object if it is affected by multiple lights it will have multiple draw calls for that single object (4 lights 1 object 4 separate draw calls). Based on how KSP handles things I suspect that each part is essentially an object and that maybe the graphical mods are not just increasing the number of draw calls but increasing the number of draw calls per part which from my understanding will have a huge impact on performance.

Another possible scenario is that with a high part count ship the CPU is already being taxed and the added draw calls from the graphical mods results in a loss of performance, but when you have a low part count ship the CPU is under far less strain and so the added draw calls have little effect on the performance.

Just spit-balling some ideas here based on my limited understanding of how these things work and applying a little bit of logic. If I am making some wrong assumptions here or if my logic is flawed I would love to here some feedback as to how and why.

I am at work right now so i can't give you any performance numbers for my set up but I will see what I can do when I get home

Edited May 15, 2017 by Akira_R

[Kerbal101]

This thread is quite interesting,.. just noticed a fairly-sized asteroid mining station (like 200 parts tops) over at twitch stream from I2ocketGuy lagged on .. 4.2 ghz overclocked 4790K with 970 gtx.

I suspect the most fps impact is done by part calculations, either physics and/or light. Still, I've seen people reporting heavy fps decrease because of .. Contract mods

Eitherway, I'll be following this. There can never be excessive performance.

From my tests in 1.2.2, I know that fairings cause significant performance drops, when over 10 were present (used instead of caps due to T tolerances). Thats probably because those have complex aerodynamics calculation. Replacing those with regular caps hugely improved fps.

Here are some more infos:

conclusions: lights cause fps drop, higher physics delta impacts fps, open ports cause fps drop.

[Ruedii]

16 hours ago, Kerbal101 said:

This thread is quite interesting,.. just noticed a fairly-sized asteroid mining station (like 200 parts tops) over at twitch stream from I2ocketGuy lagged on .. 4.2 ghz overclocked 4790K with 970 gtx.

I suspect the most fps impact is done by part calculations, either physics and/or light. Still, I've seen people reporting heavy fps decrease because of .. Contract mods

Here are some more infos:

conclusions: lights cause fps drop, higher physics delta impacts fps, open ports cause fps drop.

Yes, the visual enhancement mods will drastically increase the amount of function done per a light source adjusting your rendered light count (in the settings) to something sane (usually 8 or 16) will often drastically improve performance.

 

[Tau137]

20 hours ago, Ruedii said:

Yes, the visual enhancement mods will drastically increase the amount of function done per a light source adjusting your rendered light count (in the settings) to something sane (usually 8 or 16) will often drastically improve performance.

 

This is interesting, but, presumably, graphics (local lighting etc.) would not be calculated in map mode (which is clearly seen in testing, when "time per frame" decreases somewhat, but not enough).  And I do not believe I saw any difference between stock settings (8 light count?) in 1.2.9 and my regular setup with that settings maximized (1.2.2).

So the core of the problem is not rendering or GPU, it is how mods calls are made (apparently quite irrationally, somehow linked with part count and physics where they should not be).  Probably need to make a test with all the mods I can find that have nothing to do with physics or graphics.... just need to yet again overcome this dreadful combination of feelings I have towards KSP - addiction, adornment and frustration.... probably soon, with 1.3 once a reasonable number of mods is updated.

Also would like to thank everyone who looked into this thread and started thinking about it (and/or testing) - perhaps we will get something (performance improvement) out of it, eventually, in future versions, assuming Squad ever resumes focusing the development towards more depth and refinement rather than breadth and accessibility.

[Urses]

For problem with lights it was a diskussion for one month on many part treads. The most problems as mentioned was that the Lights from orbital crafts reached the surface of planets and lit them up. It was a work around found to depricate this behaivor but it means impo that this will be a computing in behind the scenes for shadow fall and illuminating. It would be not visible but the processing is stil there.

For grafik behaivour it was a glitch that calculated a oceanic surface on every craft but was only visible under specific circumstances like Kerbal EVA and a specific view angle. It was narrowed back to Kopernicus and there was a patched .dll.

As interested noob i would hereby wink at this treads and gather more information there. I personaly think, and will not insult some wiser heads as mine, this would give a trace for problematic with high part counted ships, if the hidden calculations are present they would be performed for all parts and this will give a heavy hit on performance rates.

For me personally the Kopernicus patch helped a lot and after implementation i has a significant performance upgrade.

Hope i could provide some helpful informations.

Funny Kabooms 

Urses

Edited May 29, 2017 by Urses