Why is part loading like it is?

[CsendesMark]

There's not much they can do about that. The lag will not go away be more efficient part loading. The only thing that will reduce is memory crashes.

Improving on lag requires both improvements to the physics engine on the Unity engine, and optimization of the simulation, a good bit of which came with .23.

Sorry, I think I wasn't really clear, my problem is not with the one-time waiting to start the game, I talking about the actual gameplay, when I having multiple ships and/or high part count and a very low framerate.

[borisperrons]

Yes, all the space that those parts take up in my RAM is really inconvenient but on the other hand, whenever I launch KSP I can just leaveit loading and make some tea. If it would start up immediately, that would rob me of that precious moment!

So my position on this issue is "meh"...

That's one of the most british things I've ever read on this forum.

[MR4Y]

Finally a suggestion that actually makes sense. That would also help people who can run the graphics KSP provides, but still get's lower framerates because of the way KSP handles processing. I never fully understood where's the advantage of running entirely into RAM if the game can't even see all of it (64 bit version). Also, it's been speculated that some native 64 bit programs are 15% faster because you're not loosing time converting data (Since all CPUs do 64 bit processing internally and externally and have to convert data for 32 bit apps in a format they can deal with, even when running a native x64 OS).

[Aghanim]

@katateochi: we agree on efficient/beautiful code design, sadly, Dumbosoft and co have introduced a new coding style which is "do makeshifts, it's faster, and you get more money with them more quickly", opposed to "do your best whatever it cost" which may lead to bankruptcy even before an early release of your software (off topic but I see that bad designs prevail over smart/effective, but quite more expensive ones, like Intel CPU vs Motorola CPU, the PowerPC 60x serie was far more better than x86 at the beginning)

The consequence of this is all deep, used by everyone, APIs are bad, full of memory leaks, so even your super done, super expensive, super tested code will be bad because of dumb coded API.

Multithreading is also not an ultimate solution as threads are designed to don't share memory with their parent process, it's just an allegedly light memory foot print model, but it's a real pain to design (with shared memory pool and locking mechanisms), and it's even more painful to debug as issues may be caused by tiny wrong timing op between threads (in a milli-sec or less step size) which are impossible to debug manually.

And use the to deal with parts is not as easy as it sounds as there is memory ownership to deal with, but I dunno really how to do low-level GPU code so I might be wrong.

Don't forget Unity layer is there and Squad team can do nothing about it, it's not in their hands, whatever they would like to do I guess.

I also observe that KSP doesn't use that much of my nvidia gfx card which make me think Unity/KSP doesn't use GPU that much whereas it provides crazy stuffes in memory managment, rendering, physics. Modern GPUs are more powerfull than a multicore CPU.

Using nvidia inspector tool, I saw KSP/Unity rise GPU mem usage to 524 MB (187 MB base), use GPU at almost 75% (I didn't play with a crazy millions of part) ship).

One thing to try would be to switch to DDS tex format with mipmaps support + add LODs to parts. And eventually a "basic shape auto builder" for complex things, I mean KSP automatically build a lowpoly model of something like an Unity collision convex shape, and for example a 4 spikes star shaped space-station can be modelled as two boxes in a cross pattern for view from infinity to ~ 300m if it is not too big, then and only then, use parts themselves.

For GPU: Unity uses PhysX as its physics engine, which should uses GPU for acceleration, but because it means that it will do some really ugly vendor lockout to Nvidia card, the Unity developer refuses to implement it.

However, if Squad do a physics engine recode, which is extremely unlikely, they should ditch PhysX entirely and use Bullet, as it will enable them to do this:

Bullet 2.80 includes a preview of the GPU rigid body pipeline by Takahiro Harada, running 100% on the GPU using OpenCL. A new AMD Radeon 7970 Tahiti can simulate 110k objects in real-time between 15-30 frames/second. It also works on recent NVIDIA GPUs with latest drivers." -bulletphysics.org

Worst case scenario is it could only simulate half of that, 50k parts

[MR4Y]

For GPU: Unity uses PhysX as its physics engine, which should uses GPU for acceleration, but because it means that it will do some really ugly vendor lockout to Nvidia card, the Unity developer refuses to implement it.

PhysX only uses the GPU if you a have a nVidia graphics card. The physics is calculated by the CPU instead if you don't have a card compatible with it.

[Sirrobert]

You know, unity already makes such small builds that the memory required means its an ideal game engine for making phone games, some people have as many as 5 INSTALLS of KSP at 1 time, I don't really see where the memory issue is...

So it comes down to "I don't like loading screens and i'l delete parts in order to save a few seconds there"..... anyways, it may be better the way it is and have everything ready to go rather than wait while a heavy part/plugin file loads mid-building and you wait that same minute fustrated while you're building your ship...

You do realize we aren't talking about space on the harddrive right? We'r talking about RAM

multiple KSP installs do nothing to effect the memory. Memory is only for active programs

[aquilux]

This needs more attention. Squad, why aren't you responding to/considering this. What happened when you did all that memory optimisation? Did you ever consider this and if so, what were your reasons for not implementing it?

[Nemrav]

you didn't specify that it was ram, anyways, since somebody bumped the thread, I may as well post this which should answer all the complaints and yes this is chad (one of the devs) talking about :

http://www.twitch.tv/hocgaming/b/443077849?t=1h1m58s

edit : why don't people do any research before asking/look into stuff before posting ?

edit 2 : since I was asked, I found that part of the stream by simply going on the planned features list, clicking the reference # (which takes you to the notes at the bottom), then you click the link... I happened to be looking for 64bit, but I watched the stream a little more (1 or 2 minutes) and there it was....

oh well, I shouldn't be that dead set against this idea, but this does answer the the threads title...

Edited March 9, 2014 by Nemrav

[aquilux]

you didn't specify that it was ram, anyways, since somebody bumped the thread, I may as well post this which should answer all the complaints and yes this is chad (one of the devs) talking about :

http://www.twitch.tv/hocgaming/b/443077849?t=1h1m58s

edit : why don't people do any research before asking/look into stuff before posting ?

I did look for answers, but either I'm defective at finding the answers, or they're hard to find. And considering that you had to link me a video... I wonder how many people would watch that for over one hour before finding the info they want?

I have a few exceptions to what was said though, like:

• Do you have any idea how big "only the people with 64 bit and more than 4g of ram" is? If you don't know, you shouldn't blow them off as a small group, you may be surprised at how big of a % of you fan base you just dismissed. Why is it that metrics are being collected on what people do in the game, but not on the very foundations of the game experience itself?
  

• These wonderful streamlining features, are there any benefits to using them on a per-mod basis? Could mod-makers reduce their ram usage by implementing them? Would it be possible to build a registry of streamlined files based off of the parts folder, use a checksum to look for any changes, and update only what needs to be?
  

• If the game is built around the mods, why are you dismissing a problem caused by the very thing you are encouraging as inconsequential. If you're going to be mod-friendly, then you need to take into account the problems caused by them.
  

• The idea that loading the files on the fly will cause hangups in the game is absurd if the loading is handled properly. Many parts will be repeated often and not need to be loaded because they are already in use, the top 10 to 20 parts used in game could be derived from the save file and kept in memory, and all other parts could be handled based off of distance much in the same way that terrain is handled. My suggestions would be that the game load the top 10 most used parts within the SOI that are not part of the prior group of parts from the persistent file, and load any parts left required for any ship within 50km, all in the background. By the time that you get within 2.2km of any reasonable ship the parts would already be in memory. Even if you had no mods installed, that'd still be a significant portion of the stock parts staying off-ram. (And don't fling the "what about massive ships" argument at me, they already hang noticeably as is I'm sure an added 10ms per part that isn't already loaded wouldn't add more than 0.5-1% of the current hang time)
  

• Even in the VAB and SPH, dynamic loading could be implemented. Pull all the thumbnails for the display, and only load parts "one click away" (current page, next/prior page, first pages of all other tabs, and top 10 parts used in sub-assemblies when on said page). People could conceivably click through faster than the parts can be loaded but they'll have the thumb-nails and text to look at, prioritize the current page and they'll hardly grab a part that isn't loaded,then you just give them a stand in for the 1/2 second it takes to load that one part. Besides, remember that "most used parts" suggestion earlier? Still having trouble with parts loading? Include saved craft in that calculation.
  

All in all, as I've combed the forums for information on this I've found a plethora of arguments and examples proving the technique's feasibility, and the only counter-argument I've seen that isn't promptly disproven is "You don't need that many parts anyway, uninstall them and go away."

I feel like this is going to be another case of squad dismissing a problem with a potential solution already at hand, until someone goes and does it for them just like multiplayer was.

Edited March 9, 2014 by aquilux
Accidental submit before proofread.

[ferram4]

Fine, here's a good argument against on-the-fly loading: it will cause unwanted behavior when a situation comes up where the game needs to load enough assets into memory that it goes over the memory limit. If you have a space station made up of parts from enough mod packs that it almost, but not quite, goes over the memory limit, but then you go to rendezvous with a ship built of parts from another pack, so that the total memory needs of the station part assets and the ship part assets exceeds 4 GB then either one of two things happens:

1. The game runs out of memory and crashes. However, since it doesn't happen during loading it's worse from a gameplay perspective, since you're interrupting someone's game partway through.
   
2. The other ship isn't loaded to prevent the game from crashing. This avoids the crash, but it still means gameplay is interfered with due to memory issues.
   

Neither of the above solutions are good because instead of a mod-heavy player worrying about memory usage when they're putting their mod setup together they're trying to figure out the maximum amount of memory that their particular mission will require based on what parts will be loaded all at once. There's no way to tell if you've planned enough for your game's memory usage until you head out there, and a player shouldn't have to think about this type of theoretical memory allocation in the middle of the game.

And then there's the fact that you could cause the crashes in the VAB as well by building a ship with too many different types of parts.

Finally, once this is implemented there will be less incentive for any modder to reduce the memory usage of their parts; it's not like memory limits will cause people to be unable to play with their pack, so why should anyone decide to use smaller textures when they could use much more detailed ones? So that will just cause the inevitable in-game crashing / vessel not loading to become more prominent.

The reason that it's a bad solution is because it has really nasty consequences if it's pushed (as it certainly will be, since that's what mod users do).

[aquilux]

But how is that situation worse than it already is? At the moment we have to contend with random crashes and hangups already. If I knew I was approaching something large that had the possibility of crashing my game, it would be less disruptive when it crashed rather than how it is now where the game may crash randomly even when just switching from my ship to map view, or from VAB to the main complex, or from the main complex to the tracking station, or just randomly for no apparent reason. I'm never prepared for that possibility, there's no warning, and I'm derailed when it happens. Not to mention it could happen just before a save wiping out everything since my last one. Or heaven forbid, during a save, completely wiping out my save file. Yes I keep backups. Should I have to? No.

At least in the scenario above the game would be allowed to gracefully handle the failure without crashing in a predictable scenario, while also giving me a warning that it's happened/about to happen, instead of hanging or dumping me to desktop at random times and requiring me to reload the whole game.

[ferram4]

But those random crashes in-game aren't due to the way that parts are loaded, it's due to either memory leaks (which will only be exacerbated under on-the-fly loading), bits of code needing just enough memory to put it over, or an unhandled exception somewhere. On-the-fly loading will only help ease the crash-during-game-initially loading and game-crashes-on-initially-going-to-flight-scene / VAB situations. And telling the player that they've gone over the game's memory limit, so they can't do the mission they've planned on doing when they get to the crucial docking procedure is only "graceful" when compared to a crash; otherwise it's the most jarring, unpolished way to handle this type of thing. It should gracefully say that the game won't be able to allocate enough memory at startup and that the player should consider uninstalling some mods.

I'm not even sure how you manage to get that many crashes; I've had a surprising lack of random crashes, and this is with me actively developing and testing mods in my saves. It makes me think there's something else interfering with KSP that is the cause of those issues to be honest.

[undercoveryankee]

Fine, here's a good argument against on-the-fly loading: it will cause unwanted behavior when a situation comes up where the game needs to load enough assets into memory that it goes over the memory limit.

…

The reason that it's a bad solution is because it has really nasty consequences if it's pushed (as it certainly will be, since that's what mod users do).

Here's a possibility: Keep a low-resolution version of every texture in memory so as long as the game runs it has something to display. Then opportunistically load full-resolution textures for nearby objects as memory permits.

It would be complicated code, and someone with actual 3D programming experience will have to talk about the performance hit. But it could be the least bad option for getting more content into a 32-bit build.

[Nuke]

[*]Do you have any idea how big "only the people with 64 bit and more than 4g of ram" is? If you don't know, you shouldn't blow them off as a small group, you may be surprised at how big of a % of you fan base you just dismissed. Why is it that metrics are being collected on what people do in the game, but not on the very foundations of the game experience itself?

im going to have to agree here. i started using 64 bit ~10 years ago. 10. 1 with a 0 after it. no, not 2 in binary, 10. ive been running with more than 4gb for at least 8. many members of the ksp community were still in kindergarten back then. i made a very early switch to 64 bit operating systems at a time where people were still needing 32 bit to run their old dos games (a thing long superseded by emulators). i used xp pro 64 up till win 7 came out. im still aghast about how much 32 bit software i still run. 32 bit should be legacy by now. im not even sure you can still buy an x86 processor (intended for use in a pc, were not talking embedded markets) that doesn't support 64-bit. also why anyone would cripple their 64 bit cpu by running a 32-bit os is beyond me.

Edited March 10, 2014 by Nuke

[Deadweasel]

• The problem is RAM usage due to large textures.
  
• Textures are large because the game will accept formats that are in non-native formats like .png, which accommodates ease-of-access to modders.
  
• Solution: require a compressed and compiled texture format like DXT for quicker load times and easier rendering by the video card.
  

Remember when KSP would accept "raw" editable model formats instead of compiled ones? Things got more snappy once that changed. Remember when one of the version releases resulted in ridiculously-long load times because of a png rendering bug in Unity? They fixed that, but the fact remains that .png is still a- shall we say, less than optimal format to use for the final load. Look through your other games; how often do you find any recognizable image formats in their resources? In fact, look in KSP's libraries. They're already using compressed formats for the core game elements like the VAB/SPH and the kerbals themselves (wrapped up in the .assets files), though it's evident that was done more to protect intellectual property assets than for performance reasons, because the parts themselves are still wide open to changes.

Now, the downside to my proposed solution is that modding becomes slightly more difficult for developers due to the format restriction, and it becomes more difficult for players to make their own changes to the mods to suit their desires. Currently, mods like Active Texture Management do this compression on-the-fly in a non-destructive manner, each time the game is loaded. It makes for a slightly longer load, but ends up using less memory once all is said and done.

Now imagine if all mods used the compiled DXT format natively. We'd see much quicker load times, less RAM usage, and snappier frame rates in general.

Currently Active Texture Management and its ilk help a lot, but they are not perfect solutions because they need to be aware of a particular mod's texture names before they will be able to work on them, and while they cover most of the big mods, they certainly can't be expected to address every single possible one.

As long as Squad are going to actively encourage modding as they have so far, it might be a good idea to release a parts dev kit that includes automated methods of compiling the models and textures into a variant of the .assets bundles for use in the game. Sources can still be released as they currently are, in a separate folder in the downloadable archive files, alongside the compiled (game-ready) bundle.

[Arcamean]

Frankly I believe improving performance should be Squads top priority as the game is becoming a chore for me not a game. By that I mean I spend more time rebooting it and waiting for loads than I do playing it. The error I see most often is:

I really want/need 64bit support A.S.A.P. for me to even have any fun. I'm so sick of seeing "out of memory" when my ships aren't even that complicated! It was my mistake for not looking but I never would have suspected this was a 32bit game. That said I'm constantly running into crashes like the log I've included and it drives me nuts. KSP takes almost as long to load as Civ 5 although with a more interesting load screen at least lol. Er I was going to add my log but I don't see a simple attach file icon and I don't want to spam this thread so here's a lil snippet.

Unity Player [version: Unity 4.3.3f1_c8ca9b6b9936]

KSP.exe caused an Access Violation (0xc0000005)

in module KSP.exe at 0023:01254a1f.

Error occurred at 2014-05-08_201724.

C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP.exe, run by Owner.

85% memory in use.

0 MB physical memory [1202 MB free].

0 MB paging file [0 MB free].

0 MB user address space [124 MB free].

Write to location 00000008 caused an access violation.

Context:

EDI: 0x00000008 ESI: 0xfa16da30 EAX: 0x00000008

EBX: 0xfa16db28 ECX: 0xfa16da30 EDX: 0xffffffff

EIP: 0x01254a1f EBP: 0x0014d804 SegCs: 0x00000023

EFlags: 0x00010202 ESP: 0x0014d804 SegSs: 0x0000002b

I'm no programmer but if I had to wager a guess I'd say it was the lack of 64bit support. My computer isn't top end but neither is it a slouch so games like KSP should run smooth as butter.

edit: Call me crazy but after viewing the list of things NOT to request what the hell did they leave out besides painting the rockets yesh!

Edited May 9, 2014 by Arcamean

[coolitic]

Can we add this to the do not suggest list?

It has been discussed to death OP, look for older topics before making new ones and causing more clutter.

[Nuke]

^ i have to agree here. its kinda getting old to see threads like this pop up every month or so. its just cannon fodder for arm chair game devs.

[aquilux]

The reason that this keeps popping up is that every time it does it gets dismissed with nothing but excuses. Before you say it, I'm aware of any response older than 3 months. They're excuses and dismissals with no level of thought behind them, and nowhere close to an actual thoughtful answer. It shall keep being brought up untill there is an actual thoughtful answer that doesn't amount to "I don't want to think about it."

As we've seen with the multiplayer mod some larger ideas get completely dismissed until someone goes and proves squad wrong by actually doing it, but as I understand it the modifications required to fix this problem are actually illegal according to squad's terms.

[Nemrav]

well, lets put an end to this :

for linux there is already 64bit

for other operating systems, 64bit is unstable and being worked on : http://www.twitch.tv/hocgaming/b/443077849?t=1h0m15s , http://wiki.kerbalspaceprogram.com/wiki/Planned_features

Now please stop asking, if another thread like this comes up copy paste this post.

hope this satisfies you.

edit : whoops wrong thread, but still if you watch the twitch vid, it still gives an answer (part loading is like this so we can support mods easier instead of the game lagging every time you want a new part.....)

Edited May 10, 2014 by Nemrav

[Deadweasel]

well, lets put an end to this :

for linux there is already 64bit

for other operating systems, 64bit is unstable and being worked on : http://www.twitch.tv/hocgaming/b/443077849?t=1h0m15s , http://wiki.kerbalspaceprogram.com/wiki/Planned_features

Now please stop asking, if another thread like this comes up copy paste this post.

hope this satisfies you.

Except the question was regarding why KSP seems to be so wasteful with the resources, not how it can be circumvented and ignored by accessing more RAM. You're right: the whole 64-bit question has been beaten to death by now, but the OP asked about why everything needs to load into memory from the get-go, as well as why the resources are so heavy when they do.

64-bit is not a cure-all, and it certainly doesn't address other issues that come with a game as complex as KSP has become, using uncompressed assets. Personally, I have to wonder what could be done on that front, too. I'd wager that if the game required compressed textures, there'd be very little negative effects seen in actively loading/unloading assets to/from RAM on-the-fly. As it stands, using .png files as-is for textures is never going to be tame-able where RAM consumption is concerned.

[Nuke]

the do not suggest list has its other side. that is squad has acknowledged the request, so there is no need to discuss it anymore. its their way of saying, ok we get it.

[aquilux]

But those random crashes in-game aren't due to the way that parts are loaded, it's due to either memory leaks (which will only be exacerbated under on-the-fly loading), bits of code needing just enough memory to put it over, or an unhandled exception somewhere. On-the-fly loading will only help ease the crash-during-game-initially loading and game-crashes-on-initially-going-to-flight-scene / VAB situations. And telling the player that they've gone over the game's memory limit, so they can't do the mission they've planned on doing when they get to the crucial docking procedure is only "graceful" when compared to a crash; otherwise it's the most jarring, unpolished way to handle this type of thing. It should gracefully say that the game won't be able to allocate enough memory at startup and that the player should consider uninstalling some mods.

I'm not even sure how you manage to get that many crashes; I've had a surprising lack of random crashes, and this is with me actively developing and testing mods in my saves. It makes me think there's something else interfering with KSP that is the cause of those issues to be honest.

For some reason I never saw this reply, so here is my belated response.

First, I only get crashes as I approach the ram limit with installed mods.

Second, with on the fly loading it'd be near impossible to cram so many different parts in one 50k sphere that you'd get more than the stock ram usage even with 10gb of mods installed, that'd keep ram usage down so much that memory leaks and bits of code wouldn't even get you close to the ram limit.

And the point of the graceful handling only being graceful compared to a crash statement is nothing short of being dismissive considering that's exactly what it's being compared to in the first place, there would be no need in most situations to post a high GB warning in startup because part loading would not occur until the parts are in a position of probable use. With the system I outlined earlier, it'd be rare to reach a point where you use as much ram as the stock game uses today.

- - - Updated - - -

edit : whoops wrong thread, but still if you watch the twitch vid, it still gives an answer (part loading is like this so we can support mods easier instead of the game lagging every time you want a new part.....)

Yeah I watched the video, excuse my language but it's a bul**** cop-out. A modded part can easily be made indistinguishable from a stock part in KSP, and I've already suggested how to handle part loading in a way that'd cause no hangups in an earlier post. It's another case of a major improvement being dismissed because apparently we have no idea what we're doing and everything we say is wrong. I hope to see someone decompile the game so that they can implement this system just to prove squad wrong like what happened with multiplayer.

Edited May 10, 2014 by aquilux

[einsteiner]

• The problem is RAM usage due to large textures.
  
• Textures are large because the game will accept formats that are in non-native formats like .png, which accommodates ease-of-access to modders.
  
• Solution: require a compressed and compiled texture format like DXT for quicker load times and easier rendering by the video card.
  

If Active Texture Management can compress the textures from inside the program, so can KSP. Then have it save the textures alongside the original files. When it loads it can check to see if the compressed file is out of date or missing, and if so re-generate it. Otherwise it only has to work with the more efficient compressed texture. It's still easy for modders because they don't have to create odd formats (though I don't see why there shouldn't be a tool to let them) and efficient.

[Justin Kerbice]

It's still easy for modders because they don't have to create odd formats (though I don't see why there shouldn't be a tool to let them) and efficient.

Nvidia made such tool: nvdxt, it create DDS (Direct Draw Surface, created by Microsoft) file from most common picture format and it support all (I think) options offered by it.

An by the way, this format is not odd, compared to the stock MBM one (which is very odd, no actual benefit but trouble to convert pic into it).

Regarding memory management, Squad should seriously rework what was done in KSP, cause it's not acceptable a mere game needs so much for just a "few" textures. I never see before any single program of any kind so memory angry. (I don't take programs that need so much memory or more legitimately like very complex simulators in account.)