Too many parts - Any Way to save some of them FPS?

[Kobymaru]

Hi!

So I am currently preparing a mission to Eloo. This is the only body I haven't visited yet, so I wanted to make a big mission this time. I have landers, probes, rovers, a base, an orbital station, a refueling craft, tugboats and pretty much everything I could conceive of. I have been assembling it slowly in Orbit and strutting it all together with Kerbal Attachment System Strut End Points.

I'm like 80% done and here's a snapshot of what it looks like at the moment: http://i.imgur.com/4ekoM8P.jpg

There's just a "tiny" problem:

I'm not even finished, and it turns out that I already have over 1000 parts!!! As you can imagine, the performance is awful. I get 5 FPS tops.

And that's with a new PC! I have 8 GB of RAM and an Intel i5 4690K. That should be enough right? Well, it's not.

The thing is: Once I get this monster into Eloo orbit, the problem is solved. It will disassemble and I will put the crafts into different places/orbits, so I expect a final part count of around 500. The problem is that I have yet some more assembling to do and then all the maneuvers to get there. That won't be fun with 5 FPS.

My question is: does anyone have ideas about what I could do to get some more performance?

Here's what I'm willing to do:

- Go down with graphics up to potato quality

- Tweak or mod the game

- Change some obscure hidden settings

Here's what I'm NOT willing to do:

- Reduce part count. That's a big mission with a big ship, and a lot of equipment. I won't scale down.

- Use welding mods. Most of my parts are functional. This is a composite "mothership" vessel with functional equipment, and not a single piece of iron.

Here's what I already tried:

- Change resolution, full screen and the likes.

- Go down with graphics quality. Almost no effect.

- Increase or decrease Phyics-Delta T

- Use the 64 Bit version

I am currently pondering to buy a new graphics card, but seeing that neither the GPU usage nor the GPU memory are used completely, I'm affraid the Graphics card is not the bottleneck.

Edited December 1, 2014 by Kobymaru

[John FX]

It won`t help. The issue is the physics calculations. They run single threaded on the CPU.

I would suggest getting Kerbal Alarm Clock and sending an armada. Send the separate modules on their own and get them to meet up at the other end.

You will get good FPS as you`ll only be going up to a few hundred parts per craft.

[Hodo]

You can cut down on a lot of the extra parts.

I understand you think you will need everything but if you were to built a bit more utility into the ship design you won't need as many parts. Do you really need 4 ion engines on on section? Do you need so many small solar panels when larger ones will do better for less? Do you need six wheeled Rovers, can you get away with smaller 4 wheeled rovers?

Unfortunately I see a lot of "problems" with that design that are going to cause issues even without the frame rate lag. I am sorry to say that but I think that design is doomed.

[zekes]

are you related to me? I made a 1600 part, 8-module Laythe base XD

[Heagar]

If you don't want to change the design, but want an better framerate you have to use the 64bit version of KSP, i guess.

I know (i tried it out) that that version is buggy. But a new graphic card changes nothing, because the CPU have to calculate the graphic (KSP uses no CUDA or the like). More RAM changes nothing too, because Unity will not use it. An 64bit task on the other hand will accelerate the command fetching witch will give you at least 15 fps, i suppose.

Thats far from an comftable framerate (25-30fps), but have to do it in your case.

[Kobymaru]

I would suggest getting Kerbal Alarm Clock and sending an armada. Send the separate modules on their own and get them to meet up at the other end.

I see, that seems like a "good" option.

You can cut down on a lot of the extra parts.

I understand you think you will need everything but if you were to built a bit more utility into the ship design you won't need as many parts. Do you really need 4 ion engines on on section? Do you need so many small solar panels when larger ones will do better for less? Do you need six wheeled Rovers, can you get away with smaller 4 wheeled rovers?

I understand what you're getting it. But to me it seems just so strange to cut down on luxury just to accomodate the game engine. Compromises due to mass limitations? TWR? Stability? Costs? Practicability? All fine and well, because those factors are "real". But not because the game can't handle my awesomeness.

Unfortunately I see a lot of "problems" with that design that are going to cause issues even without the frame rate lag. I am sorry to say that but I think that design is doomed.

I'm gonna go through with it anyway. If I am doomed to fail, then I shall fail. It's the Kerbal way!

But out of curiosity, why do you think I am doomed?

are you related to me? I made a 1600 part, 8-module Laythe base XD

Probably not, but it's nice to see that someone shares my pain How did you cope with 1600 parts?

Edited December 1, 2014 by Kobymaru

[Kobymaru]

If you don't want to change the design, but want an better framerate you have to use the 64bit version of KSP, i guess.

I know (i tried it out) that that version is buggy. But a new graphic card changes nothing, because the CPU have to calculate the graphic (KSP uses no CUDA or the like). More RAM changes nothing too, because Unity will not use it. An 64bit task on the other hand will accelerate the command fetching witch will give you at least 15 fps, i suppose.

Thats far from an comftable framerate (25-30fps), but have to do it in your case.

Sorry, I forgot to mention that. I tried the 64 bit version too. FPS were the same. Did you try it? What were your results?

[Red Iron Crown]

But not because the game can't handle my awesomeness.

Not sure if you're willing to redesign with the ship so mature, but one mod that could really help your mothership is Hangar. It allows you to place your individually awesome rovers, landers, tugs, etc in "hangar" parts, where they are turned into a single, less awesome part. That way, the mothership with a bunch of docked ships is not too awesome for your PC, but when you release each child ship they regain their original awesomeness. As long as you don't undock all the awesome craft at once you should see a substantial performance improvement. I haven't used this mod but it does sound right for you.

(You can also substitute "part-heavy" for "awesome" in the above and it still makes sense.)

[zekes]

How did you cope with 1600 parts?

Made a 90 minute live stream XD

[mythbusters844]

You should try out Time Control. I've used it before with this thing to make the game actually run at an appreciable FPS by slowing down time and I still use it for other things too.

Just my 2 funds.

Edited December 1, 2014 by mythbusters844

[Higgs]

If you are running this on 32 bit you are limited to a max of like 4 gig ram. That said, may I suggest not scaling your mission down, BUT sending it in multiple series of ships to scale back the strain on your rig itself. End result of same big mission taken in smaller bytes so to speak.

[HoY]

I second the Hangar mod. Your mother ship can be taken down to just a few hundred parts, and still bring the entire mission in one shot.

[RainDreamer]

You can also try KAS and keep all the little things like struts and thing to be detectable and reattachable, so that you can save a bunch of part counts from all the struts you used in launch but not needed in space. Extra planetary launch pad would also help for creating things in-situ, so you don't need to launch everything at once and build them after you are there.

[LordFerret]

... The issue is the physics calculations. They run single threaded on the CPU. ...

That's interesting. Is that because of the layout/build of the KSP executable itself, or related to the construct of Unity? Curious.

[MockKnizzle]

I believe the single-threaded physics are a limitation of the older Unity build that KSP uses. There's a newer one that allows multi-threading, but I believe porting the game over is a task that SQUAD hasn't undertaken yet.

[LordFerret]

Yes, I could see that would indeed be a task. Maybe after Beta? I know both C++ and C# are capable of multithreading... but then again, parallel processes introduce a whole new set of problems and considerations.

[Higgs]

all i know is, until they do something <squad OR unity> we are stuck with what we have. and for MOST OF US, 64 bit just isnt stable enough to play the game enjoyably on windows.

[LordFerret]

I know KSP offers a 64-bit mode, but is it a version truly written 64-bit or (exactly as stated) just that - a 'mode'. Unless it's written 64-bit, you'll not receive the benefit of the power a 64-bit processor would offer.

[Heagar]

Sorry, I forgot to mention that. I tried the 64 bit version too. FPS were the same. Did you try it? What were your results?

I didn't try it with a big craft.

I tried it when the 64bit version was released. When ever a new version is availible, i test old rockets/spaceplanes with flights to mun to check out, if the general behavior of crafts have changed (buffed/nerfed parts and orbital physic rules). Because the 64bit version was that buggy i went back to the 32bit version at that time.

An reason why the 64bit version have the same framerate performance may be that KSP don't uses a hash sort for the - linked and assembled - *.craft file (for calculating the physics). May be that even that is not done, and the *.craft file is translated on the fly (over and over again for each line of code = runtime execution). This would mean that you have to live with the 5 fps margin in my opinion.

Mmmhhh... It seems so, i have to do some tests: Editing a *.craft file while flying the craft.

[rodion]

i think my approach would be to split the rover, base, and probe modules up into their own less laggy crafts, attach their interplanetary stages to them and launch them 30 minutes or so apart at the scheduled window, so they're unloaded relative to each other and don't contribute to the physics lag (and leave a good time margin to perform injection maneuvers later). it gives me an enormous headache to try to imagine single-launching such a big heap of hardware, it's just not practical.

[Kobymaru]

Not sure if you're willing to redesign with the ship so mature, but one mod that could really help your mothership is Hangar. It allows you to place your individually awesome rovers, landers, tugs, etc in "hangar" parts, where they are turned into a single, less awesome part. That way, the mothership with a bunch of docked ships is not too awesome for your PC, but when you release each child ship they regain their original awesomeness. As long as you don't undock all the awesome craft at once you should see a substantial performance improvement. I haven't used this mod but it does sound right for you.

This mod sounds awesome!

Made a 90 minute live stream XD

Lol, and how many FPS did you have?

You should try out Time Control. I've used it before with this thing to make the game actually run at an appreciable FPS by slowing down time and I still use it for other things too.

Ok, this sounds really interesting. That's 0-Change "fix". I assume it will feel inherently sluggish, but at least I won't get eye-cancer from all the single frames, and hopefull the input will still work.

That's interesting. Is that because of the layout/build of the KSP executable itself, or related to the construct of Unity? Curious.

It's because writing multithreaded applications is hard, multithreaded physics calculations harder and debugging multithreaded applications using multithreaded physics calculations is the hardest.

Remember that you not only have to calculate stuff, but you also have to divide the task into "work packages" for the single threads, sync up the results when they are done, get the timing right, etc...

It makes stuff a lot more complicated.

If I assume correctly, Unity 5 will bring multithreaded calculations. But that would require switching the game over to Unity 5 - which quite frankly, I don't see happening anytime before the big 1.0 (or any time after that, for that matter)

[edit] Ok, I stand corrected. Several threads have mentioned that Squad does look at upgrading to Unity 5.

I know KSP offers a 64-bit mode, but is it a version truly written 64-bit or (exactly as stated) just that - a 'mode'. Unless it's written 64-bit, you'll not receive the benefit of the power a 64-bit processor would offer.

No, it's a real 64 bit executable. The thing is: 64-Bit processes are not magically faster. Here's the difference:

- The pointer and integer sizes are twice as big (this actually makes the memory usage larger)

- The process can assume that the CPU is newer and has more features. This brings some performance gain, but not much.

- With the increased pointer sizes, more than 4 GB of memory can *theoretically* be adressed. I'm not sure if The Game/Unity is actually capable of using that, because I haven't seen a KSP process that's over 3 GB yet (even 64 bit).

Edited December 1, 2014 by Kobymaru

[Oafman]

I understand what you're getting it. But to me it seems just so strange to cut down on luxury just to accomodate the game engine.

If you're building a big ship, the game engine is one of your biggest limitations. There are various ways to ease this bottleneck slightly - welding, Hangar, KAS etc - but ultimately the best way to deal with it is to get your part count down. This can be done with very little impact on functionality, and only a little impact on aesthetics. As good as your ship looks, you're not really making a good job of this.

A few thoughts:

- All those little batteries! Especially the 4 on each rover. This is your greatest part count crime There are plenty of bigger batteries in KW, NF etc, where 1 could do the job currently being done by many

- Get rid of all the lights, and use the Ambient Light Adjustment mod. Since I got that mod, I've even removed the lights from the squad folder

- There are a lot of the orange toroidal tanks, which carry very little fuel. Can you replace them with fewer but bigger tanks

- Same story with all the radial xenon tanks

- Do you need adaptors in front of every docking port?

- In a few places you've used 2 Modular girder adaptors, where 1 XL girder would do the same job

- Are all those girders with attached struts really adding much structural integrity?

- You could make a lot more use of KAS. With ships like this, I usually take crates full of batteries, RCS nozzles, RTGs, parachutes, science experiments etc, then just add them to each module before it departs

- could landers get away with 3 legs rather than 4? This is Eeloo after all...

I honestly think you could pretty much half this part count with enough optimisation. And while I agree that it can be frustrating to have to prioritise saving part count, the game engine-imposed limitations are not going anywhere in the near future, so there's little choice.

[Kobymaru]

- All those little batteries! Especially the 4 on each rover. This is your greatest part count crime There are plenty of bigger batteries in KW, NF etc, where 1 could do the job currently being done by many- Get rid of all the lights, and use the Ambient Light Adjustment mod. Since I got that mod, I've even removed the lights from the squad folder

- There are a lot of the orange toroidal tanks, which carry very little fuel. Can you replace them with fewer but bigger tanks

- Same story with all the radial xenon tanks

- could landers get away with 3 legs rather than 4? This is Eeloo after all...

Okay, that makes sense!

- Do you need adaptors in front of every docking port?

As always the case with adaptors: that's purely aesthetical

- In a few places you've used 2 Modular girder adaptors, where 1 XL girder would do the same job

That's a bug, not a feature! That shouldn't be there.

- Are all those girders with attached struts really adding much structural integrity?

I sure hope so! Since the ship will be somewhat linear, and the docking ports are notoriously "bendy", I'm afraid the ship will feel less like a ship and more like a cooked noodle.

- You could make a lot more use of KAS. With ships like this, I usually take crates full of batteries, RCS nozzles, RTGs, parachutes, science experiments etc, then just add them to each module before it departs

Now that is a good idea. I should have thought of that

"Some assembly required"-Style

To be honest, I simply did not take part count into account when designing the mission. With my old PC, I had lags with a smaller (~400 parts) mission but after getting my new rig it ran amazingly smooth and I thought all my performance problems were solved. Turns out part count is just another parameter I have to consider when designing things.

[MarvinKitFox]

... performance is awful. I get 5 FPS tops.

Anything better than 10SPF (seconds per frame) is doable

[Oafman]

That's a bug, not a feature! That shouldn't be there.

What bug is that?

I sure hope so! Since the ship will be somewhat linear, and the docking ports are notoriously "bendy", I'm afraid the ship will feel less like a ship and more like a cooked noodle.

They definitely are bendy, even the 2.5m ports.

But in thsi case, your struts appear to only be strutting the module they're attached to, by which i mean they don't stretch across the point where the docking ports meet, so they won't add the stability you need. You get the worst flex between docked ports, rather than within the actual modules of the ship, so you really need to add KAS struts across the docked ports. Attaching them to radial girders will help in some cases, but aren't necessary in others. For example, where your truss (with 2 large and 2 small ports) meets the part in front of it (holding the 2 landers), you could strut from the port that each lander is docked to, directly over to the 2.5m docking ports on the truss, and that should be pretty stable without the need for radially attached girders.

Even with KAS struts well placed, you will still have to take it pretty easy when you're making your exit burn from Kerbin. KAS struts are not very strong, and break under pressure, and as soon as you start getting oscillations in a long ship like this, it's very hard to stop them. (I usually stop burning, time warp very briefly to kill the wobble, then start burning again, rinse and repeat as soon as the wobble starts to get bad).