Why is part loading like it is?

[katateochi]

When KSP starts up it first loads every single part into memory. Why?

In someways that seems like a logical thing to do, but I see this as a possible design flaw.

There are not many craft designs which actually use every single part (I don't think even WhackJob's use eveything!), there are even some parts that are not used at all by some players. This means that some parts are just sitting in memory, taking up space, but never being used. This is a problem as memory use is perhaps the biggest limitation in KSP (particularly for us mod users).

Loading all the parts to start with is muda (wasteful) if your into agile/lean terminology.

The agile and lean approach to coding (or business or whatever) is about reducing waste and one of its mantra is "don't do a thing before you need to do a thing, wait until the last responsible moment". By loading all the parts to start with KSP is doing something prematurely and it results in some parts being loaded even when they are never going to be used, the result is wasted memory.

Maybe there is a prescriptive reason that parts must be loaded first, some limitation in unity or some other factor that I don't know about. I'd be very interested to hear what the developers say about this.

So what is the solution?

Well, this is a possible solution, it's how I'd approach the problem.

(please don't think I'm saying this is how it must be, its just how I'd write a design specification)

The game should have a database of its parts which includes part descriptions and a generated thumbnail gif for each part (and some other data like the path to the part and a checksum). When the game starts it should check that its database is up-to-date with the parts present; build entries for any new parts that have been added or changed (based on the checksum), remove entries for parts that are no longer present. This might mean on the first ever load of the game it may have to load all the parts to do this, but then it should unload them and free up the memory. Subsequent loads when parts haven't changed should happen very quickly as only plugins will need to be loaded. How nice would it be to have a modded KSP load in under a minute!

In the VAB/SPH the parts lists should be derived from the database and a part should only actually be loaded into memory when a user selects it. This might imply a few ms or second delay when selecting parts, but already we see large delays just switching tabs when there are lots of parts. If the parts list is derived from a database, switching between tabs should be very smooth.

The fact that currently we see delays just changing tabs really bothers me given that all parts are in memory.

As you build a craft the parts that are in use by the current craft will be loaded into memory but all the other parts will not be taking up space. Depending on how fast a part can be loaded will govern how to handle parts being removed. If part loading is very fast, then unload the part and free up the memory. If part loading takes longer, then maintain the part in memory incase it gets used again, but flush the memory when entering/exiting the VAB/SPH.

In the game scene when the craft is launched its parts should remain in memory and any other parts used by other nearby craft (within the 2.2km) should also be loaded. It is likely that this will only be a few parts that have to be loaded as many craft will share common parts. Memory will also be much freer so there should be no penalty from the operating system trying to free up space by paging (questionable).

During flight when you encounter other craft their parts will need to be loaded on the fly. The game should look in the 5-10km (at a guess) around the current craft and determine what additional parts are needed and start loading them as a background process. By the time you reach the 2.2km boundary the additional parts required for the approaching craft should have been loaded and then the render event that happens at 2.2km can happen as normal.

When you move away from a craft it should wait a reasonable time before unloading parts that are not needed from memory, ie; once you've gone over 50km away from it. I think a larger distance to begin unloading parts compared to the distance to start loading parts will help as you might go just 20km from something and then turn round and come back.

This way the game works to only keep those parts which are actually being used in memory and the limitation is then not about how many parts you have installed but how many parts you are using at any one time.

Now this is just a ruff sketch of a design idea, I realize in programming there are problems lurking that you can't foresee until you start, but if this or something similar was a viable solution to reducing KSP's memory footprint then it would be the only thing I would actually care about in terms of the next phase in development.

I cry a little every time KSP crashes because of a memory limit exception. It seems like an unnecessary casualty and I quietly shake my fist at all those parts that I wasn't currently using but which are sitting in memory and doing nothing. To me this is KSP biggest failing.

There are cries to move KSP to 64bit because of the limit in available memory, but I'm wary of this.

Yes this would enable KSP to take up more memory but the limit is only raised to how much RAM you have. Not all of us can afford to pack in GB's more RAM and it is not solving the problem, its simply delaying it. Initially it will be fine, but there will be no onerous on mod developers to be efficient in the way they develop parts and people will invariably keep adding more and more mods. Very soon we'll be right back at the same problem, the only difference being KSP+mods now needs 16GB of RAM (or whatever your physical limit is).

I really hope that Squad doesn't see 64bit as a way of forgetting about memory optimization or efficient part loading, I would see that as a sloppy move. I really hope that a more elegant use of memory is something they have in their plans. As I said before, that is the only thing I care about in terms of future development because it is the only thing which makes me walk away from KSP.

I'd like to know what everyone else's thought are on this and I'd love to hear what the devs think. Maybe there is a reason this kinda approach can't be done, or maybe its already in the pipes. I've not made this as a suggestion because its not fully thought out yet. If I get some good discussion around this and hear some other ideas/thoughts then I will refine it into a suggestion.

[Orionkermin]

I believe the 64-bit issue is a limitation of Unity, so there's really nothing squad can do about that at the moment.

[SRV Ron]

Not only every part, but duplicated named textures which eat memory like crazy when those textures are large. Eventually, the programmers will address that issue, but for now, you can pull those unused parts folder from the Game Data folder which will free up memory as well as speed up the loading process.

[katateochi]

I believe the 64-bit issue is a limitation of Unity, so there's really nothing squad can do about that at the moment.

Yes 64bit is a unity limitation and out of Squads hands. But my point is that 64bit is not the answer to KSP's memory issues, its about how the parts are loaded and the fact that parts which are not being used just sitting in memory taking up space.

Not only every part, but duplicated named textures which eat memory like crazy when those textures are large. Eventually, the programmers will address that issue, but for now, you can pull those unused parts folder from the Game Data folder which will free up memory as well as speed up the loading process.

Do you mean manually delete a selection of parts that you don't use? I do this already and its a slow annoying process to prune each mod down (and have to redo it each time they update). I really hope that it is something high on the list of things to tackle and not to just leave till there is a 64bit unity.

I't a pity this hasn't gained much activity, I really feel like this is an important core issue in KSP right now and needs attention. I'd really like to know if something to deal with part loading is being considered (for sooner rather than later!) or are we just going to have to accept that KSP will always have a colossal memory footprint.

[rkman]

I agree with the OP .

[Tw1]

I see there being the problem of added loading time when coming close to other vessels. Could be a pest. So, perhaps a compromise idea would be to load all models, but not textures. That way, all parts will still appear in some form, then textures could be slowly loaded in later.

I'm not sure though, as all parts should be accessible in the editors, there would be a lot of loading and unloading going on.

[Nemrav]

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...

[rkman]

perhaps a compromise idea would be to load all models, but not textures. That way, all parts will still appear in some form, then textures could be slowly loaded in later.

Sounds like a good idea.

I'm not sure though, as all parts should be accessible in the editors, there would be a lot of loading and unloading going on.

No unloading, only loading of parts that are used. Parts will be accessible anyway.

some people have as many as 5 INSTALLS of KSP at 1 time, I don't really see where the memory issue is...

The issue is not with storage memory, but with RAM usage while the game is running.

Edited February 22, 2014 by rkman

[Nuke]

what should be done is to load all the textures but at a lower mip level (resolution) that is negligible on memory usage. then you stream in and out the bigger mip levels based on usage. usage is fairly easy to track, since somewhere there will be calls to the graphics api to change the texture, each time this happens a counter (one for each bitmap) goes up, counters are also decremented over time to keep them from overflowing. the textures with the highest counters are the most used and should have high resolution versions in memory. the game would dedicate a slice of memory to textures and will load as many textures as can fit without ever going over.

everything else when compared to textures is negligible. once parsed, cfgs take up very little space (on the order of a few KB), and model data (on the order of 10s to 100s of KB) is usually dwarfed by even 256^2 textures (uncompressed around 2MB), which are miniscule by today's standards.

Edited February 22, 2014 by Nuke

[Serratus]

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"...

[Doc.Solveberg]

Sorry for slight off-topic, but are your start up loading times also like 1 minute long? (completely stock, no mods whatsoever)

[coolitic]

Because if it didn't, you would get major stutters every time you looked at new parts and if you ended up looking at all parts without closing ksp, it would use the same memory as pre-loading.

[nhnifong]

Harv has mentioned wanting to make this optimization before, but I think they're just going to keep adding features until their memory usage hits a wall and then do the optimization.

[Nuke]

Because if it didn't, you would get major stutters every time you looked at new parts and if you ended up looking at all parts without closing ksp, it would use the same memory as pre-loading.

there are ways around it. first is always have something to draw. model data is so small you can just keep it all loaded and it has a negligible impact on memory. texture data, not so small. but if you keep only small versions of textures loaded at all times, say 128^2 textures in memory (about 50k each, uncompressed), then that too becomes negligible. that way there is always something to draw in memory. it might not look pretty but its there and you dont have to stop what you are doing to go get a higher quality version.

if the texture is used a lot, such as its always on the screen, then load up some 512^2+ textures when you have some cpu time, and change the texture handle to point to the bigger version. this could be a few frames from when the engine decides it needs a higher res version of that texture, so a fraction of a second goes by and that thing you thought looked ugly now looks a whole lot better and your mind doubts that it ever looked ugly to begin with.

you can also run texture streaming code asynchronously in another thread (though this is not a requirement you can do this in the same thread, just a possibility when threading comes into play), so it doesn't interfere with the game. its whole job is to load textures that are being used a lot and unload textures (to some minimum) that are hardly ever used.

Harv has mentioned wanting to make this optimization before, but I think they're just going to keep adding features until their memory usage hits a wall and then do the optimization.

this kinda makes sense. the only time the game really has trouble is when dealing with a lot of mods. the stock game will always take priority for the devs. especially right now when the main focus is fleshing out the game.

Edited February 22, 2014 by Nuke

[katateochi]

I see there being the problem of added loading time when coming close to other vessels. Could be a pest. So, perhaps a compromise idea would be to load all models, but not textures. That way, all parts will still appear in some form, then textures could be slowly loaded in later.

I'm not sure though, as all parts should be accessible in the editors, there would be a lot of loading and unloading going on.

Yes it is the textures that are the mem-hogs, as Nuke says everything else is negligible compared to the textures. All the parts should be accessible in the editors, but that doesn't mean they need to all be there in a high res form.

There would be a lot of loading and unloading going on, but that is the something that happens in most games these days, particularly the big open world games which constantly shuttle things in and out of memory as you move through the world. Ideally the user should not be aware of the loading and unloading.

If I was thinking about the part tabs with my web-dev hat on, each tab is like a page with a lot of slow content, so the page should load with just placeholder icons for the content and then the content should be loaded in as a background (ajax) request. This means each page loads fast and flicking through several pages would be smooth. When you stop on a page the content starts to load. You might experience a slight delay picking up the first item from that page if you're faster than the background loading process, but then after that your back to having everything ready for you.

what should be done is to load all the textures but at a lower mip level (resolution) that is negligible on memory usage. then you stream in and out the bigger mip levels based on usage. usage is fairly easy to track, since somewhere there will be calls to the graphics api to change the texture, each time this happens a counter (one for each bitmap) goes up, counters are also decremented over time to keep them from overflowing. the textures with the highest counters are the most used and should have high resolution versions in memory. the game would dedicate a slice of memory to textures and will load as many textures as can fit without ever going over.

everything else when compared to textures is negligible. once parsed, cfgs take up very little space (on the order of a few KB), and model data (on the order of 10s to 100s of KB) is usually dwarfed by even 256^2 textures (uncompressed around 2MB), which are miniscule by today's standards.

You talk a lot of sense Sir! I think (don't actually know) that what you describe is the logic used in a lot of games, particularly the big open world games.

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"...

As an Englishman I appreciate the importance of Tea. When playing Stock I get the chance to make tea before I start and typically I might only get one crash in which to make a 2nd cup. But if I made a cup of tea each time I had to restart KSP when playing with mods I think I would die of a caffeine overdose!

tbh my reason for wanting memory optimization is not to have a faster starting KSP, although if that was a byproduct I would be happy, its because nearly every crash when playing with mods is due to KSP hitting an out of memory exception. A more efficient use of memory would stop this and I'd have to consciously take a tea break once in a while.

Sorry for slight off-topic, but are your start up loading times also like 1 minute long? (completely stock, no mods whatsoever)

KSP stock 1:15 from starting the game to being in the space center

KSP heavily modded 2:20 from game start to space center

by comparison;

Skyrim 48 seconds from start to in game

Deus Ex 30 seconds to be in game

FarCry3 - failed to contact remote server and refused to start, I hate crap like that! Long live KSP's standalone approach! (it's usually about 30 seconds)

So stock KSP is not a whole load slower to start that those and really I don't mind waiting for the stock game to load. I wouldn't mind the 2+ minute load of modded KSP IF once loaded it wouldn't have frequent mem-exception crashes and force me to wait another 2+ minutes.

Harv has mentioned wanting to make this optimization before, but I think they're just going to keep adding features until their memory usage hits a wall and then do the optimization.

Glad to hear that it is being thought about, do you have a link to where that was said?

It does make sense for them to do it later, I just hope that is not too much later.

@Nuke I think you are spot on about how to treat textures and if they implemented something akin to what you are saying we would get a much more efficient memory footprint.

Does anyone know about threads in unity? Am I right in thinking that its just a single thread currently? Is multi-threading bound to the 64bit version or can we expect a multi-threaded unity before the 64bit unity. The reason I'm asking about threads is because these optimizations will benefit from being separate threads to the main logic.

[weissel]

Do you mean manually delete a selection of parts that you don't use? I do this already and its a slow annoying process to prune each mod down (and have to redo it each time they update).

Why don't you automate the process? Slow, annoying, repetetive is a clear indicator that you should.

When KSP or a mod is updated any unneeded new parts need their files to be listed in the "list of files to be pruned", but otherwise ... same old, same old, same old "delete these files"!

A 'rm "file with spaces" foo bar baz qux quux "GameData/mod dir with spaces/somefile" ... ' (possibly using multiple rm commands) would be a very lowtech, but working method. I am sure even on Windows something like this is possible.

[allmappedout]

Surely, as OP briefly mentioned in the original post, is to instead of having the models loaded for the VAB/SPH, simply have a static button to represent each part, with a low-res picture, instead of the spinning model of the part as is currently in use? Load all the buttons up at the start and you're loading maybe 1MB of information, with a button click beginning the call procedure for the texture model.

[Captain Sierra]

First off, I agree with Katateochi and Nuke in how to handle textures and reduce memory. My install isn't even *that* heavily modded, I run two major parts packs, and I still mem crash. Memory optimization needs to become a bit more of a priority, especially if they want to advertise KSP as a mod friendly game. Mem crashing under anything more than 1 large parts pack (except B9, or Novapunch, which probably count as 3 and 2 respectively) is rediculous for a mod friendly game.

-snip-

Does anyone know about threads in unity? Am I right in thinking that its just a single thread currently? Is multi-threading bound to the 64bit version or can we expect a multi-threaded unity before the 64bit unity. The reason I'm asking about threads is because these optimizations will benefit from being separate threads to the main logic.

Unity is actually multi-threaded. What isn't multi-threaded is the physics, which is why KSP can't fully take advantage of multi-core processors and why even running a 2.2GHz i7 2670QM processor, I still hit single digit FPS once I hit 700-750 parts even above 160km.

[CsendesMark]

~~~

Unity is actually multi-threaded. What isn't multi-threaded is the physics, which is why KSP can't fully take advantage of multi-core processors and why even running a 2.2GHz i7 2670QM processor, I still hit single digit FPS once I hit 700-750 parts even above 160km.

And does Squad working on that matter?

Because my i7 3820 is just getting wasted, with about total 26~27% CPU load during game

[Atoning Unifex]

And does Squad working on that matter?

Because my i7 3820 is just getting wasted, with about total 26~27% CPU load during game

Well I think that the devs are probably expending a lot of time on the NASA Asteroid and KSP Edu components, understandably, as I expect this will increase their income making it easier to add in even more stock features. That's what I'm hoping anyway. I will happily 'put up' with the longer loading times and memory problems (when heavily modded) in the interim in the hope that these additional ventures will lead to an overall better final product.

[Captain Sierra]

And does Squad working on that matter?

Because my i7 3820 is just getting wasted, with about total 26~27% CPU load during game

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.

[katateochi]

First off, I agree with Katateochi and Nuke in how to handle textures and reduce memory. My install isn't even *that* heavily modded, I run two major parts packs, and I still mem crash. Memory optimization needs to become a bit more of a priority, especially if they want to advertise KSP as a mod friendly game. Mem crashing under anything more than 1 large parts pack (except B9, or Novapunch, which probably count as 3 and 2 respectively) is rediculous for a mod friendly game.

Unity is actually multi-threaded. What isn't multi-threaded is the physics, which is why KSP can't fully take advantage of multi-core processors and why even running a 2.2GHz i7 2670QM processor, I still hit single digit FPS once I hit 700-750 parts even above 160km.

I'm finding that playing with mods has lost its shine for me because of the constant crashes and I love mods so its a real pity. And you're right, KSP is supposed to be mod friendly and (as far as I can tell) there are more mod players than pure stock players so it's not like this only effects a small percentage of the user-base.

Ah that's interesting (re the multi-threading). So it would be possible to do loading and unloading of parts in separate threads. That makes the whole thing even more feasible.

[sjwt]

In the Good old days, KSP didn't load all the parts, how ever with the way UNITY physics engine works, that meant that often situations where encountered where physics was fully loaded, but parts, scenes , worlds or actions were not.. This lead to ships literally falling apart and blowing up for no reason or even welding them selves onto the launch pad unable to take off or even falling though Kerbin!

[vexx32]

Wouldn't that just be a matter of making sure everything's loaded properly before kickstarting physics?

[Justin Kerbice]

@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.

Edited February 24, 2014 by vexx32
Tsk, tsk.