What is stopping Squad from loading textures on demand?

[theend3r]

One of the largest problems, if not the largest problem, of the current KSP is the memory problem which makes the loading times long and prevents large scale modding.

The solution to this is to either use the 64 bit .exe which is no longer supported, use the -force-opengl option which has some quirks and magically takes up a lot of ram

or downscale the textures and make the game look horrible.

This could all be solved by loading the textures on demand like most other games do and the loading times would be far shorter too. You'd still probably need most of them in the editor but that could easily be solved by using thumbnails. There was even a mod (that is unfortunately no longer developed) that did this so it should definitely be possible. Why doesn't squad do it?

[Red Iron Crown]

That's a good question. I suspect that their focus has been on improving the stock game, and such a change would have a minimal effect on a stock install.

[Superfluous J]

Currently, the biggest thing stopping them is this huge project they've undertaken, and possibly a fairly new and aggressive release timetable they're under to release that project. Maybe you've heard of it

After 1.0 comes out, then I hope the only thing stopping them is the front door to the office. Which will hopefully be unlocked and have a coffee machine right behind it.

[theend3r]

That's a good question. I suspect that their focus has been on improving the stock game, and such a change would have a minimal effect on a stock install.

It would significantly reduce the loading time at least.

[Red Iron Crown]

It would significantly reduce the loading time at least.

It would, for sure. I was merely suggesting what I think the reasoning might be, that they have much bigger things to do in the stock game before getting to this.

[Yakuzi]

It will be interesting to see how 1.0 will run in 32 bit with the vast multitude of new parts and features planned (e.g. new landing gear, bigger wings, IVAs for all crew compartments, heatshields, resource exploitation equipment, procedural fairings, new space center buildings and several GUI overlays). Particularly since some players were already struggling with memory issues in stock 0.90 and will further reduce the memory available for installing mods.

If Squad doesn't optimise memory usage in 1.0, they should definitely address it in their first patch (or second, the first will likely be "the squashing of *more-than-one* bugs patch")

Edited February 16, 2015 by Yakuzi
language

[NathanKell]

Q: What's stopping them?

A: Time.

What would reduce loading time is converting *.mbm to *.dds, though, and that doesn't actually take coding time really (the DDSLoader is perhaps the simplest, shortest plugin ever written); Load-On-Demand will actually slow loading time, because the textures have to be read and then low-rez placeholders made from them (one load step) and then each time a texture is actually needed at high rez it has to be loaded again.

[Beduino]

+1 to this I'm upvoting they fix it as soon as possible as described in this thread. They can probably do a better job than any mod by improving the base code.

Then we have:

Lower memory footprint

Reduced loading times

More mods+more parts+more fun

Maybe optimize the planets so we can have more, maybe even another star with little memory/performance hit.

Maybe they could even figure out a way to improve performance with increasing part count so we can use even more parts to build larger bases/ships.

[bv1]

I've always wondered this too. It seems ridiculous to have to have every single part texture loaded into memory at all time, when there are parts I never use at all.

[Robotengineer]

Load-On-Demand would be a pain. Converting all textures to .dds, and adding a DDSloader would be better IMO.

[Damien_The_Unbeliever]

Well, there's a possibility that the DDS thing has already been done:

Additionally, that branch also contained a tentative implementation of DDS formatted textures for KSP, so far cutting the initial asset loading of KSP by 1/3rd if not more in some cases.

[Beduino]

Load-On-Demand would be a pain. Converting all textures to .dds, and adding a DDSloader would be better IMO.

Actually it's not a pain, it's the sane thing to do. Can you imagine half-life loading all the textures and maps into memory?

It should be something available in Unity actually. Judging from the fact that Cities Skyline also uses Unity and suffers the same fate of having mods and is loading everything into memory.

Maybe it's something they improved in Unity5 but im not certain.

[Robotengineer]

Actually it's not a pain, it's the sane thing to do. Can you imagine half-life loading all the textures and maps into memory?

It should be something available in Unity actually. Judging from the fact that Cities Skyline also uses Unity and suffers the same fate of having mods and is loading everything into memory.

Maybe it's something they improved in Unity5 but im not certain.

The issue is that when you load large crafts, such as bases or stations, you have a huge loading time whenever you switch crafts.

[Van Disaster]

The issue is that when you load large crafts, such as bases or stations, you have a huge loading time whenever you switch crafts.

Even if you preloaded every asset used by every ship in your current persistence file you're still unlikely to load every asset in the game. You can stream textures in a seperate thread & gracefully insert them into the scene - might get the odd missing or blurred texture for a tiny bit but you could do it without pausing the game.

[klgraham1013]

I'd also like to add that, even if there may be down sides to not loading part textures, having all the HD planet textures in memory all the time is unnecessary.

[Eric S]

I've heard (but not confirmed) that one of the memory leaks in KSP has to do with the fact that the memory it loads the on-disk textures into doesn't get released after conversion to the graphics card's (or is it Unity's?) preferred texture format. If that's one of the memory leaks that have been fixed, then this becomes a non-issue. I'm not sure if converting to DDS textures on disk will eliminate this or reduce it, and I'm not even sure that that change is going live with 1.0, but if it is, it will reduce the memory leak even if the memory leak itself isn't fixed.

Why is that memory leak important? Because if you've got a memory leak, you're better off only doing it once, not repeatedly. A load-once and then keep resident method would get around this, but could still cause problems, say you do a grand tour in a single session, you'd then have all the HD planet textures in memory regardless of which one you're in orbit at the end of the tour.

It's possible that the reason that KSP doesn't do dynamic loading/unloading is because of the memory leaks. It's also possible that they just haven't gotten around to it. And yes, it's also possible that they don't consider it important. I can understand the first two as long as there's progress being made, but I'd disagree with the third, though how strongly I'd disagree would depend on how much fixing 0.90s memory leaks and DDS conversion help vs how much the new 1.0 assets hurt.

I haven't run into memory problems with 0.90 even modded, but I've heard that if you're running on an actual 32-bit version of windows your margin for leakage is smaller so even stock crashes after a few scene changes or a few hours. I'd like to see KSP reach the point that you could heavily mod it even on 32-bit windows, but I don't see that as a critical priority for 1.0. Being able to run stock or even lightly modded KSP for hours on a 32-bit OS would be more critical for 1.0, and at this time, I don't think we have enough information to know how close to any of these goals 1.0 will be.

[Eric S]

It should be something available in Unity actually. Judging from the fact that Cities Skyline also uses Unity and suffers the same fate of having mods and is loading everything into memory.

From reading the online documentation, Unity 4 does have the ability to dynamically load and unload assets. I'll admit that there may be catches that I'm unaware of. On the other hand, KSP texture loading has memory leak issues as of 0.90, so dynamic loading/unloading of assets could actually make the situation worse as the memory could get leaked multiple times.

You can stream textures in a seperate thread & gracefully insert them into the scene

Not in Unity 4. This should be possible in Unity 5, but as I understand it, much of the Unity 4 API isn't thread safe and in fact there are safeguards within Unity 4 to ensure that only the proper thread accesses the API. You might be able to bypass Unity's texture file loading, load from the file in a separate thread, then have the main thread load the texture from the memory that the other thread loaded it into, but I'm not sure you're really gaining anything there.

EDIT: ugh, thought there was two similar threads, sorry for two similar posts.

[Gkirmathal]

In my opinion load-on-demand wont do much if the game does not properly unload data it doesn't need anymore. This not unloading of data, being automated (GC) or manually thru code, in my book is called a memory leak.

In my opinion if Squad fixes the not properly unloading of non used data, via GC optimizations or manually culling it, a lot of memory related problems will be solved. And all data can still be loaded in memory on start.

One of my personal main annoyances is when often switching scenes: 1) an hour editing > lauchpad > editor, or 2) KSC > craft > KCS. The ram profile steadily climbs, sometimes it lowers GC at work, but on re entering the editor it adds more memory back than the GC cleared.

Seen this on stock KSP and this issue is even more magnified when using several part packs.

I read in the DevNotes or comments there (coupleweeks ago?), the current GC implementation causes issues when the client over time starts to run high on memory, which causes stuttering and low fps as the GC starts to struggle.

I'm no coder, but this made me think doing it manually might be better than letting U4 handle unloading.

@Eric S, you say you never noticed any memory leak issues? Not even when switching scenes countless times between the editor > launchpad/KCS

If I may ask you for a favor. Could you log an hour or so of: editor > launching > reverting to editor > repeat? Stock or modded, I'd like to know your start and end memory footprint of the KSP process.

ninja edit: load-on-demand would be initially perfect for planets/bodies. It will make it possible to have more bodies in KSP.

Edited April 5, 2015 by Gkirmathal

[NathanKell]

My understanding is this: the Unity 4.x DX9 client will keep shadow copies of textures in system RAM even after they have been uploaded to VRAM and made unreadable-by-software (i.e. told not to keep the shadow copy). This bug does not exist in Unity's OpenGL client, which is why OpenGL mode uses so much less RAM.

This has literally nothing to do with loading and unloading of assets; if you unload a texture, it does indeed unload.

What is relevant to streaming assets is that stock KSP 0.90 has issues with PNG and TGA loading, and even MBMs still have to be compressed. However, in 1.0 there's DDS support, which should make streaming assets much easier (in terms of lacking loader or leak issues with png/tga, and in terms of not having a 'compress' step or, for PNG, a prior 'decompress' step, so there won't even be a performance hit).

Note that all KSP's assets in the "assets" files are already DDS--that's why you don't see a delay while KSP loads them at startup, they load so fast.

It is entirely, entirely technically possible to write a streaming loader for KSP, it has been since 0.20, it just has not been a priority for the devs. Speculating about mysterious issues that might technically prevent it is a fool's errand: there are none, as the mod that does this proved.

[Fel]

Aren't there several posts where SQUAD members directly talked about this very issue? I remember HarvesteR talking as if this was due to limitations within Unity.

[rkman]

Loading textures on demand would only make sense if textures are also unloaded when not needed. That means part textures would have to be loaded every time you switch to another parts tab in the editor. Not doing that would mean eventually all (or at least a large number) of part textures end up and remain in memory.

I could be mistaken but i think planet/moon textures already are loaded an unloaded as needed.

DDS loader demonstrates that just using DDS instead of other image formats saves a ton of loading time and memory. The one thing i don't understand is why Squad has not moved to DDS much sooner in development. It's not the sort of change that might cause problems later in development, and would over the past years collectively have saved us a whole lot of time waiting for the game to load.

[comham]

KSP was designed and built as a game where you stack (a limited selection of stock) rocket parts in stages. Planes are a kludgy afterthought. Dealing with 20 times the assets that squad made wasn't even considered.

[Eric S]

@Eric S, you say you never noticed any memory leak issues?

That came out wrong, even though technically correct. I haven't crashed in 0.90 due to memory leaks. In fact, I can't remember crashing at all in 0.90. Because I haven't crashed, I haven't paid attention to memory usage. I am in no way denying that 0.90 suffers from memory leaks.

I'm not too worried about the memory leak in the VAB->Launchpad scene change because that's one of the few memory leaks that they confirmed that they fixed already. Max said that they've probably fixed 8-12 memory leaks if I remember right, but wouldn't state what any of them were, but one of the devs mentioned that specific one in the dev notes.