Ways to increase framerate

[msyblade]

I have a pretty damn slow AMD 2.1Ghz with a 1gig radeon 6450, and the performance on everything made after 2011 is ACTROCIOUS. KSP is unplayable if I do not lower the physics Delta to 0.03. Its bad enough that lowering ALL of the graphics options to minimum, does not equal the performance increase of lowering the physics alone.I also must clean boot to get decent framerate out of it. Firefox, Skype . . .ANY of those open will cost me 15 frames/sec. I have a moon base consisting of 3- 70 part landers and a 200 part "Base" (heheh, actually 2- 140 part dual landers that split,and one of em didnt make it "snip,clip,tumble,tumble,smack,boom". So one lander arrived alone.) I experience lag there, even on a clean boot. Honestly, I just kinda stopped going there because it was annoying. Anyway (I tend to ramble), lower the physics, and use the task manager to close everything that is running in resident memory: daemon tools, poweriso, spybot, skype, web browser, realplayer, windows media player. . .All of those types of programs can be closed to inch evermore power for KSP's physics. It's not unreasonable for this to be the case. If Squad says "Okay, We've got the system. and it's AWESOME. but if you make us iterate it 700 times simultaneously, there is likely to be a performance decrease." We would all look incredulous and say "Duuh, that's obvious."

Edited July 3, 2013 by msyblade

[Tiron]

As people have said, the real problem is Unity. Specifically that they're still using ancient PhysX version 2. Plenty for most games, but not for one so physics heavy as this.

I've heard stuff indicating that someone was working on a different physics engine for Unity, to be released as a plugin for the engine. Which could be fantastic for us, because it could potentially fix so many basic problems with KSP. Framerates with large ships (if it can use multiple cores and/or GPU acceleration) and the instability in orbital parameters (caused largely by Unity's old PhysX being unable to use floating point numbers and consequently introducing rounding error, or so I gather) for a start.

Unfortunately, I also gather that development on said physics plugin has basically ceased, as it was one guy doing it and it sounds as if he's basically abandoned it.

If some wonderful person were to make or port an alternate, better physics engine in a way that would allow the KSP team to easily integrate it into the game (PhysX 3, perhaps?), it would do so much to help the game in general it's not even funny.

Double unfortunately I'm a hardware geek with only very minor experience in programming, or I'd just try and do it myself...

[sushinut]

Wow.. are there more and more posts about lag, or is it just a coincidence given there are simply more players?

Like OP and countless others, I've pulled my hair out over the last 10 days or so due to this limitation of Unity. I spent hours trying to get a few more frames (4FPS up to 8FPS). Finally, I couldn't take it anymore and decided to just rebuild the base completely. I realized I was spending wayyy too much time trying to tweak my settings and playing with a deplorable framerate; starting from scratch would be better. Only THIS time redesigning everything with fewer parts and connections... and of course going through all the pain of redelivering the pieces to the Mun.

(It would be oooooohhh so helpful if there were a cheat that allowed you to switch one VESSEL for another in the persistent file. There isn't one is there?)

All this being said, it seems there are a BUNCH of Getting Started guides, FAQs, videos, etc. When I first started playing, I used some of those resources, but I never saw anyone mention this SUBSTANTIAL limiting factor for the game. I guess I just missed it.

SEEMS like a STICKY would be VERY useful for this issue. The "Performance" section of the "Known Issues" sticky does not mention this issue.

In retrospect, I sure wish there were a POP-UP warning in a building tutorial or when you first enter the VAB that said something like this:

"Once you figure out the basics, you're likely going to want to build a huge space station or a Mun base. DON'T DO IT until you understand the limitations of the software: you will likely only be able to have maybe 300 to 400 parts rendered in the same scene until you have a substantial loss of game performance. PLAN ACCORDINGLY: use parts wisely; don't just attach things because they look cool.... you'll regret it later." (this is tongue-in-cheek, but you get the idea)

This simple caveat, plus maybe the list of helpful tips for maximizing performance (while sacrificing quality) would help reduce the chances of paying customers simply walking away from this game. This issue will be a substantial problem for user experience, if the game is to ever mature out of alpha. I suspect many have already put down the game and moved on to others.

My 2 cents.

Edited July 3, 2013 by sushinut

[Jason_25]

I think the performance issue is the elephant in the room and it would decrease sales if it was widely known that you, cannot, build the designs you imagine in the game. The sticky should say something like a build a tiny, ugly rocket because that's all you will be doing before punching something, the end.

[Vanamonde]

Yep, it sure does suck, the way you can only build small, simple ships in this game.

[Ming]

Wow.. SEEMS like a STICKY would be VERY useful for this issue. The "Performance" section of the "Known Issues" sticky does not mention this issue. ... I suspect many have already put down the game and moved on to others. My 2 cents.

Many prior threads have already covered, often in heated detail, this KSP performance problem. Short of a Unity engine change nothing is going to significantly increase your frame rate while using high part count designs. For right now "sushinut" has the best idea. Make it abundantly clear via a forum sticky, both here and on Steam, that there is a "known" performance issue with overly populated design structures. This sticky could even make general recommendations on max part counts (300, 400, 500, whatever). But say something! Just letting new players stumble blindly into this already known pit of frustration is being, IMO, very inconsiderate.

P.S. Personally, I'm willing to put up with 1-2 FPS while launching 1100+part rocket-tubbies. However, most folks aren't as patient as me.

Edited July 3, 2013 by Ming

[_Zee]

Have you tried editing your exploding craft's altitude in the save file?

No, after rebooting the game, my base loaded just fine oddly enough. Frames were still terrible, but no problems with terrain collision on scene loadup. Which leads me to wonder if the engine has a problem with memory leaking as well.

to answer the origional post.

1) less background programs

2) higher IPC(instructions per cycle) CPUs

3) Overclocking

4)limit ksp to highest numbered cores and limit other stuff to lowest numbered

not much you can do at this point. we are really waiting for better multicore support within unity.

1) No background programs are being run during KSP, only the ones that have to be, i.e. Steam.

2) Read post #9

3) Same thing. Can't be done on my CPU

4) What?

Yep, it sure does suck, the way you can only build small, simple ships in this game.

The point of this post was.... what?

No one is making claims that the game doesn't allow you to build towering mega structures capable of achieving orbit. The argument is that flying that contraption you have there in LKO at 5 fps is a problem when it shouldn't be.

[Zardiz]

As someone said indeed, the fact that this is just listed as alpha is not enough imo. There needs to be information laid out to people that there is big performance issues with structures extending over X parts, on most machines and nothing you can do about it. There is another game that's much earlier Alpha than this that I have too, and its to point where, while I would love with the bug hunting and stuff like that, it runs so badly on my PC that its just not enjoyable at all (Maia is the game btw)

[korda]

No one is making claims that the game doesn't allow you to build towering mega structures capable of achieving orbit. The argument is that flying that contraption you have there in LKO at 5 fps is a problem when it shouldn't be.

Flying something at LKO is really really really different thing than flying it elsewhere. The way game renders terrain and specifically the way game renders water makes all stuff I build lag as long as I'm looking at Kerbin/Eve/Laythe while being close to it. I've heard that there are ways to fix it a bit though, at least when it comes to water.

And TBH while I would probably had some issues with that behemoth it wouldn't be so bad in practice, even though I play game on my laptop (its Dell XPS though), my constructions are often similar size and I don't have big issues.

Also as a programmer I think I'm aware in how bad situation Squad probably is when it comes to physics in this game. You make assumptions and decision on what you can afford, what you can actually make in finite amount of time and what will be in future. If you assume game won't be so popular then you won't be able to afford some stuff (since you assume that you won't be able to get the cash back). Making game engine is really hard task and KSP has small team. Also it would mean that they would have to maintain engine too. While starting this game they probably didn't have idea that limitations of Unity engine will be big issue ever (or they had to ignore it, since it was best option they could afford), also it wasn't 2013, they couldn't know it will be problem for Unity developers to upgrade engine to today's standards in future.

This isn't normal game, most modern games are GPU hungry, not CPU hungry, also not many games have to simulate physics for so many objects in so many aspects (remember that there is also heat and aerodynamics). It all also means that Unity developers would have to focus on stuff that isn't so important for modern game just to help KSP.

Requests to change engine? Thats equal to starting over. It's not going to happen (unless they actually will start from a scratch).

[ASnogarD]

Alpha is alpha, do not expect the game to run smoothly, do not expect your game to run without issues, do not expect your saved games to be safe, do not...

... do not expect the quality and performance of a released title.

To be honest with you, despite my complaints, for an alpha this runs pretty well... at alpha stage the developers are stitching the various parts of the game together, seeing how each part interacts and tweaking components to sort out issues in interaction.

Performance is a secondary consideration at this stage.

So, sorry to say, the fact it is listed as a Alpha, and is still in development and is not released is enough to warn players this game may not run well or be stable... now if Squad declares the title in beta or released and you meet the games requirements THEN you have recourse to complain.

FYI - I am on a rig that handles BF3 decently, and Metro:Last Light with all the eye candy on...yet the game stutters with even some of my sub 200 part craft... a 3.2 ghz CPU.

I have tried some small tricks to see if that smooths out some of the issues like disabling in game vsync and using the nVidia control panel to enable vsync there, I disable AA as at 1920x1080 the edges are reasonably smooth enough for me, though I use the control panel to bump up the anisiostropic filitering (cant really tell if its effective though).

I also made the game only use core 5 of my CPU rather than have it try share core 0 with the rest of the applications.

Not sure if these things are effective as I dont have many really ambitious craft hanging around as I am still playing with docking and Mun landings... docking still takes me over and hour to complete (may not be so long if I had used SAS to keep my heading while translating, and if my fancy craft was actually RCS balanced )

[Synapse]

Did you reduce the visual distance as per youtube recommendations? made a heap of diference for me, particularly alter Kerbin-Ocean down to 3 instead of 6

[Amphiprion]

But going from a SINGLE core at 2.8 to a SINGLE core at 3.4, really isn't going to make that big of a difference. It certainly wouldn't justify purchasing a new CPU.

And fair enough, Squad didn't design the engine that they are using for their software. But why in the HELL would ANY software company choose to use an antiquated engine that can only utilize a single core?! It's 2013! Do stores even sell new single core processors anymore??? Excuse me for ranting, but that's f***in ridiculous.

LoL, I think because its still pre-Alpha, single core code is easier to change and update than multi core code..

makes sense for a game in pre-alphe dev stage..

2.8ghz-3.4ghz is quite a percentage increase.

Alot of anger in you, there is. remember your training.

Edited July 3, 2013 by Amphiprion

[KerbMav]

How do you activate the displaying of fps in the game?

I built some very atrociously "over-parted" lifters and maybe I am simply used to (not spoiled) lower framerates, but I dont think it was ever 4 fps ... and I do run Miranda, Teamspeak, Firefox (with x tabs) in the background. (Steam btw is not needed, I even just copied the game out of the steam folder for easier access to my gamedata and to prevent unwanted updates)

Picking up on a question asked a page back: Does moving to Linux 64bit help somehow?

[boxman]

I don't see how overclocking or buying a faster CPU would help in any way, shape, or form, if the engine is only utilizing one core from the CPU. Buying a faster CPU, would mean increasing my core count. So instead of having 3 cores completely un-utilized, I would instead have 5 or 7 un-utilized.

If Squad designed the engine... how is changing the engine out of their control?

Then overclocking would make perfect sense. If you up the frequency you will get noticeable increased peformance with games that even use just one core.

And you can just compare cpus like that. Even though newer high end cpus usually have more cores they are also often faster per core.

[boxman]

I think the performance issue is the elephant in the room and it would decrease sales if it was widely known that you, cannot, build the designs you imagine in the game. The sticky should say something like a build a tiny, ugly rocket because that's all you will be doing before punching something, the end.

And what if they double the performance?? People will just build bigger and then moan about framerates again. What we do now in KSP is not something the developers even imagined could be done. Most people only started building really big stuff after docking ports was added which was not very long ago.

Performance has already noticeable improved for large ships/stations since then and I am sure it will improve more as devs have been saying they are working on increasing performance.

But if you expect a physics heavy game to be anywhere unlimited then you are pretty naive.

And especially from a damn alpha game.....

These problems would not go away no matter which engine they used, as you will always eventually run into limits even if it handles multicore properly.

And who is to say that unity wont get multicore support?? I personally bet they are working on that and that it will be in future versions of unity.

Edited July 3, 2013 by boxman

[KerbMav]

Compiling the VAB built into less parts - physics-digital-welding certain parts into one:

girders connected to girders, docking ports to their parent-parts, stacked fueltanks (or maybe not, only if heat dissipates differently then) ...

[Deadweasel]

Allow me to help add some perspective here.

Look at this:

This is what a frame ripper pulled from the game. What you're seeing is a segment of Kerbin rendered out.

Okay, in the lower right hand frame, you see that area with the black blotches? That's the general area of the KSC.

In this "model", there are 379 components. This rip was taken from a clean save with a kerbal (and nothing more) standing on the runway.

A kerbal is composed of around 30 or so components. One kerbal.

Now go ahead and slap your ship out there. Your 100+ part ship with individual pieces that require physics calculations for each and every one. Now while it's sitting out there, come back and look at this, and realize just how much is being rendered out in realtime by this game.

Oh, by the way, each of those colored squares represent about 2 layers of meshes. The low mesh is the real planet surface, the upper one contains the topography (mountains, hills etc) that resides on it.

Just some things I've recently discovered that go a long way toward explaining for me why KSP is the way it is sometimes.

[Tiron]

From: http://docs.unity3d.com/Documentation/Manual/Plugins.html

Unity [Edit: Pro and Mobile anyway] has extensive support for Plugins, which are libraries of native code written in C, C++, Objective-C, etc. Plugins allow your game code (written in Javascript, C# or Boo) to call functions from these libraries. This feature allows Unity to integrate with middleware libraries or existing C/C++ game code.

Suppose someone set up, say, PhysX version 3 (Which has multi-core physics support among other features we presently lack) so that it could be used as a Unity Plugin.

Now instead of redoing everything from scratch, you only have to change the calls to the physics system.

[Vanamonde]

Since asked, I will remind that the point of posting my large ship was specifically to refute this bit of hyperbole:

it would decrease sales if it was widely known that you, cannot, build the designs you imagine in the game. The sticky should say something like a build a tiny, ugly rocket because that's all you will be doing before punching something,

The ship in my pic ran a bit slowly at first but was entirely manageable, reached the Jool system and dispatched 6 orbital probes, 8 lander probes, and a manned lander to the worlds there, and after each probe was detached, the part count shrank and performance improved. I'm sorry if I'm harping on this same point across multiple threads, but I'm just getting really fed up with all the whining about how horribly this broken game is because it struggles to animate ships that are needlessly and big and overly complex for any useful purpose: ships made simply for the sake of appearances. Yes gentleman, if you senselessly overbuild your ships, both the performance of the game and the ship are going to suffer for it.

[Deadweasel]

There's also Bullet which (imo) does a much better job since as was stated elsewhere, PhysX was designed to make explosions and destructive components look more realistic when coming apart.

Thanks, but I'm not sure I want to deal with an engine that is designed to make destruction look fantastic. That's for experiences like one of the (inevitably-many) incarnations of Battlefield or Call of Duty.

Give me a real physics engine that is designed to simulate interaction of components while they stay TOGETHER instead. That's what Bullet does.

Unfortunately, there's an aspect that all these calls for "real" physics support that nobody's addressing. Let's say the devs are listening to one person intently and are standing ready to implement the very next thing he/she says, and let's say he/she says "PhysX NAO!"

It will be months, possibly a year before anybody sees another update in the game. Development on just about everything else will have to halt while the core is re-written and debugged to accommodate the new stuff. Now I'm not claiming some mystical insider knowledge of the game or even that I'm a programming expert, but I'm generally aware of how Squad has been building on this game, and just from the outside, I can see that's probable they'd have to go back and change quite a bit of the heart of the game to get it to work so radically different.

How much outcry will be out there when the entitlement crowd starts getting itchy for its updates?

I think the real issue should be leveled at Unity itself, not Squad, for why Unity is so relatively limited in this day and age. Squad are paying for the licensed pro version of Unity (which they'd have to if they're making a game that they're selling to the public, based on Unity. Look up the licensing requirements), so they're kind of limited by what Unity as an engine can do.

Why aren't Unity including native PhysX/Bullet support instead of letting them lurk outside in the back alley as plug-ins (which would solve the CPU-only limitation for KSP all by itself btw)? Why isn't Unity running proper multi-thread support yet?

These are questions that should be directed to the owners of the engine Squad are using, because at this point, some of the requests we're making of Squad are a bit like asking them to build a house and handing them a mechanic's tool set.

Off to the side, I'm not going to touch the 64-bit argument because the only reason it's a topic of discussion at all is due to the use of mods driving KSP's memory load beyond the 32 bit addressing space (around 3.5GB). By itself, in plain old vanilla form, KSP is quite well-behaved and light on the RAM, compared to other big games I've played. Those mods, though, they all have to load into memory alongside the game too. Squad are generous to accommodate the modding community as well as they have, but there's no reason to bash them for not pushing for 64-bit, when the only reason such a thing is needed is because some people don't know when to stop with the third party add-ons.

[Tiron]

I think the real issue should be leveled at Unity itself, not Squad, for why Unity is so relatively limited in this day and age. Squad are paying for the licensed pro version of Unity (which they'd have to if they're making a game that they're selling to the public, based on Unity. Look up the licensing requirements), so they're kind of limited by what Unity as an engine can do.

Why aren't Unity including native PhysX/Bullet support instead of letting them lurk outside in the back alley as plug-ins (which would solve the CPU-only limitation for KSP all by itself btw)? Why isn't Unity running proper multi-thread support yet?

These are questions that should be directed to the owners of the engine Squad are using, because at this point, some of the requests we're making of Squad are a bit like asking them to build a house and handing them a mechanic's tool set.

Because there's no substantial economic incentive for them to do so. Let's face it, for most purposes, especially the kinds of games that are usually made with Unity, old, single-threaded PhysX 2 is plenty adequate. Unity is designed primarily for accessibility and cross-platform capability. It isn't really intended for large, system-intensive games made by major developers (who generally make their own engines). It's intended for small developers to be able to pump out games on a lot of platforms, without spending years developing a framework. These kinds of people are usually okay with the features the old PhysX 2 has. Why spend lots of time and money integrating something most of your customers don't need or care about?

KSP is ONE game, with unusual requirements. Unity aren't going to spend a lot of money implementing a feature for one game.

And let's be clear, more than anything, it's the physics engine holding KSP back, not Unity itself. It was Unity's choice to use PhysX 2 instead of a better, more modern engine, but it's still the PhysX 2 that's the main problem.

Yes, it would take quite some work to switch to a new physics engine. But the change being to the game engine itself rather than a plugin probably wouldn't make it any easier. Even then, it'd be as a new version of the Unity Engine, and we've already gone through THAT once (Remember when they upgraded it to Unity 4?) It'd still be easier than changing to a different game engine. That's part of why I suggested PhysX 3. We're already using PhysX 2, and it'd probably be easier to update the current physics calls to work with PhysX 3 than to modify them for an entirely different physics engine.

But so far as I can tell, there ARE no Physics Engine plugins for Unity, of any sort whatsoever, so until that changes, that part of the discussion is moot anyway.

Edited July 3, 2013 by Tiron

[Deadweasel]

Because there's no substantial economic incentive for them to do so. Let's face it, for most purposes, especially the kinds of games that are usually made with Unity, old, single-threaded PhysX 2 is plenty adequate. Unity is designed primarily for accessibility and cross-platform capability. It isn't really intended for large, system-intensive games made by major developers (who generally make their own engines). It's intended for small developers to be able to pump out games on a lot of platforms, without spending years developing a framework. These kinds of people are usually okay with the features the old PhysX 2 has. Why spend lots of time and money integrating something most of your customers don't need or care about?

KSP is ONE game, with unusual requirements. Unity aren't going to spend a lot of money implementing a feature for one game.

And let's be clear, more than anything, it's the physics engine holding KSP back, not Unity itself. It was Unity's choice to use PhysX 2 instead of a better, more modern engine, but it's still the PhysX 2 that's the main problem.

Yes, it would take quite some work to switch to a new physics engine. But the change being to the game engine itself rather than a plugin probably wouldn't make it any easier. Even then, it'd be as a new version of the Unity Engine, and we've already gone through THAT once (Remember when they upgraded it to Unity 4?) It'd still be easier than changing to a different game engine. That's part of why I suggested PhysX 3. We're already using PhysX 2, and it'd probably be easier to update the current physics calls to work with PhysX 3 than to modify them for an entirely different physics engine.

But so far as I can tell, there ARE no Physics Engine plugins for Unity, of any sort whatsoever, so until that changes, that part of the discussion is moot anyway.

Very true on almost all fronts, point well-taken.

On that last one, though, I have to disagree:

http://forum.unity3d.com/threads/135293-Unity-Bullet-Physics-Plugin-Demo

But, again, good points on it probably making more sense to just upgrade PhysX instead of changing the physics model entirely, and why Unity isn't moving ahead quite as quickly as we KSP players would like it to.

[asmi]

There is just one thing I wish would happen - once they release 0.21 (and 0.21.x of course), Squad would announce todo list for 0.22 containing just two items - performance and 64bit support. They really need to focus on it and solve the problem. Pushing it out and blaming it on Unity/PhysX/whatever is just unprofessional.

[Tiron]

There is just one thing I wish would happen - once they release 0.21 (and 0.21.x of course), Squad would announce todo list for 0.22 containing just two items - performance and 64bit support. They really need to focus on it and solve the problem. Pushing it out and blaming it on Unity/PhysX/whatever is just unprofessional.

Not when it's true, it's not. See, you can't just slap a bunch of content together and have it be a game. There has to be a code framework holding the content together that makes everything work. This framework is called an 'engine'. When making a game you have basically two options: Make a new engine from scratch, or use an existing one. The second option means either having already made one or getting one from someone else.

KSP uses the Unity3D engine (there's also a 2D version, which Rovio is rather fond of). Basically the entire core functioning of the game relies on Unity and its features in order to work. Especially Unity's built-in physics engine, an older version of nVidia's PhysX that only supports running physics calcs on a single core and can't use GPU acceleration.

Unity's old version of PhysX is one of the primary things holding performance back, as the inability to use more than one CPU core means that ships with large partcounts use all the available processing power on a single core. Most modern systems have at LEAST two cores (Mine has Six!), but KSP can only make use of one. A different physics engine that could make use of multiple cores(Including later versions of PhysX) would allow for much larger ships before physics lag became a problem. Though as I explained above, Unity has no particular reason to bother updating this.

Which means there are only a few options available to Squad in this area: Throw out almost everything that's been created and start from scratch on a new engine. Do all that, only trying to create the engine themselves too. Tinker with the engine itself, modifying it to do what they need. Pray someone else does the latter which they can then use.

Changing engines would require YEARS, even if NOT creating a new one, and would require most content to be recreated. Changing to a different physics engine (Bullet, say), would take some months of refactoring to get everything to work with it.

Performance optimizations generally come very late, and there's a reason for it: It's rather hard to do them when some of the things you need to optimize are being reworked by someone else at the same time you're trying to optimize them. And it wouldn't help anything that got added in later, either.

Very true on almost all fronts, point well-taken.

On that last one, though, I have to disagree:

http://forum.unity3d.com/threads/135293-Unity-Bullet-Physics-Plugin-Demo

But, again, good points on it probably making more sense to just upgrade PhysX instead of changing the physics model entirely, and why Unity isn't moving ahead quite as quickly as we KSP players would like it to.

Ah, that must be the one I've heard of. Unfinished, unreleased, being worked on by a single guy, who hasn't posted to the thread in nearly seven months. If it ever got finished and released it could potentially help KSP enormously. If. It looks pretty abandoned.

[Sick]

Unfortunately SQUAD only use UNITY engine - not develop. Too bad that work on this engine is going sluggish and i keep my fingers crossed that they (unity developers) will give more support to AMD's Bullet engine instead of NVidia's PhysX.