[WIP] Loading textures only as required

[Guest]

I've got a problem with the Load On Demand. On an unmodded install of 0.23.5, it doesn't work. "It says that it encountered a problem and was disabled. Requested feature is not implemented.". Something like that. Does it work with 0.23.5 at all?

[raidernick]

I've got a problem with the Load On Demand. On an unmodded install of 0.23.5, it doesn't work. "It says that it encountered a problem and was disabled. Requested feature is not implemented.". Something like that. Does it work with 0.23.5 at all?

You need to install vcredist_x86. I had the same error until I did that. Although if you are playing unmodded there is no reason to be using this it will only make the game performance worse.

[Guest]

Well, it was for testing. I suspected mod conflict, but after booting the mods, it still didn't work. I'll try your suggestion.

[Faark]

New Version 2.2 available, DL Link on the Startpage. It does contain some changes that hopefully improve it a bit, though i would like to read your feedback and thus won't spoil any details.

Although if you are playing unmodded there is no reason to be using this it will only make the game performance worse.

It shouldn't. I cannot yet assure you that it doesn't, since that is one of the reasons this project is still work in progress. But can you really reliably reproduce a performance issue? Sth like "With LOD installed, load saved game A and then doing B takes X seconds. Without LOD installed doing B takes Y seconds where X is significant more than Y."! Since having such a test case would really help but i couldn't find any on my saves, at least not with the latest version 2.2.

Also, is there a way you can make this mod ignore the textures in the FASA Gemini IVA. For some reason is makes you unable to see out the Gemini windows, they are completely black. I tested on a new install of ksp with just this mod and fasa and it is definitely this causing the windows to be black.

Thanks for that info, i will have a look into both... why the texture is black as well as implementing a way to blacklist textures. Should be easy but isn't yet possible.

Does OpenGL have similar functions that could allow for a port of this mod for OSX or Linux?

Probably some day, but the current version is windows-specific and changing that will require a lot of work.

EDIT: Nevermind, tried it and answered my own question. Will send the logs.

Thanks!

[SpacedInvader]

New Version 2.2 available, DL Link on the Startpage. It does contain some changes that hopefully improve it a bit, though i would like to read your feedback and thus won't spoil any details.

Yay for more testing! I've got to say though, for being super alpha, this mod has completely changed my game experience... It's nice to be able to have a large amount of mods installed without having to prune them of extra parts and not have to worry about crashing on load.

Is it possible to expand this to work on planet textures as well? Many planets don't get loaded at all in the average day of play, and it's been mentioned in the RSS thread that the textures for the planets are quite large in some cases, so this may be an area where some memory savings can be found. It also might significantly decrease the impact of running KSP with the planet factory mod enabled, allowing for even more places to explore and exploit within the limited memory budget of KSP.

I would also like to request, if you're willing, for you to start putting up a changelog from version to version so we can see whats being changed with each iteration.

[Proot]

I'm very interested in this mod for the management of my compilation http://forum.kerbalspaceprogram.com/threads/70693-WIP-Renaissance-Compilation-%28artworks-remake%29. This will be a future alternative to ATM or could be used together at some point? Someone have tested both for compare savings and performance? (this texture management plus the basic ATM compression would be great for mod junkies as me)

Edited April 8, 2014 by Proot

[raidernick]

Many planets don't get loaded at all in the average day of play

The planets are actually always loaded. If you use a telescope mod you can zoom in on eelo or any other planet from kerbin and see them as if you were right in front of them. I suspect that this means the textures for these are always loaded and simulating physics even when not near the planet.

[rbray89]

The planets are actually always loaded. If you use a telescope mod you can zoom in on eelo or any other planet from kerbin and see them as if you were right in front of them. I suspect that this means the textures for these are always loaded and simulating physics even when not near the planet.

Well, the scaled body texture is always loaded, but it doesn't have a rigidbody for physics.

[SpacedInvader]

The planets are actually always loaded. If you use a telescope mod you can zoom in on eelo or any other planet from kerbin and see them as if you were right in front of them. I suspect that this means the textures for these are always loaded and simulating physics even when not near the planet.

The point though, is that if you don't look at it, it doesn't necessarily need to be loaded, so maybe if we could have them load on demand like parts, it would save memory until you decide to look at them. In this way, if you're only in visible range of Kerbin, Mun, and Minmus, then you don't have to waste resources sitting on the textures for Eve, Moho, Jool, etc. Just like the parts in the VAB, I'd happily accept a few seconds of fuzzy planetary textures to save a few hundred MB of memory.

[rbray89]

The point though, is that if you don't look at it, it doesn't necessarily need to be loaded, so maybe if we could have them load on demand like parts, it would save memory until you decide to look at them. In this way, if you're only in visible range of Kerbin, Mun, and Minmus, then you don't have to waste resources sitting on the textures for Eve, Moho, Jool, etc. Just like the parts in the VAB, I'd happily accept a few seconds of fuzzy planetary textures to save a few hundred MB of memory.

I'll let Faark comment on this one. If I understood the app, Faark was using the native hooks to detect when textures were recalled, and using the in-game hooks for part deletion and whatnot to know when to unload them, so it may not be an issue of loading them up, but rather unloading when no longer needed.

[Guest]

You need to install vcredist_x86. I had the same error until I did that. Although if you are playing unmodded there is no reason to be using this it will only make the game performance worse.

Well, I've downloaded and tried to install it, it says that I already have a newer version on my machine... So it isn't that, I think. Consider I've got a full Visual Studio 2012 installed already... C++ and all.

Edited April 8, 2014 by Guest

[NathanKell]

For planets, one solution would be to use placeholder textures when not in tracking station and when not in the object's SOI (or the SOI of its children). That won't help with the heightmaps, though, which are MapSOs not textures.

[raidernick]

I'll let Faark comment on this one. If I understood the app, Faark was using the native hooks to detect when textures were recalled, and using the in-game hooks for part deletion and whatnot to know when to unload them, so it may not be an issue of loading them up, but rather unloading when no longer needed.

I would rather this be a togglable setting rather than forced same goes for placeholder textures. I see no noticeable performance/ram impact and I have high res reskins for all the planets. Unloading the planets would make all of the telescope and camera plugins useless as you would then not be able to see them at a distance.

[SpacedInvader]

I would rather this be a togglable setting rather than forced same goes for placeholder textures. I see no noticeable performance/ram impact and I have high res reskins for all the planets. Unloading the planets would make all of the telescope and camera plugins useless as you would then not be able to see them at a distance.

This is definitely sensible as memory issues are system and install dependent, so eventually it would be nice to be able to tweak this mod to suit our current needs.

I would also like to report that this newest version seems to be saving me an additional 400MB.

[Proot]

Too large non part textures for me. I can't use this.

But this looks good, so I'm suscribed and expectant for posterior versions. Good luck and keep on the good work.

[Faark]

I would also like to report that this newest version seems to be saving me an additional 400MB.

That sounds great, any crashes?

@ATM

Since ATM has switch to a similar texture "selection" method as LOD, it both should play fine along each other (As long as you have this new version of ATM!). LOD will run first (since you placed it directly in GameData) and will take "control" of every texture it should be able to handle and leaves the remainder to ATM. Some private messages confirmed it working, but i haven't extensively tested it myself, yet. Mostly because my 5gb test install is still on .23 and i won't modify it until its updated, but was yet to lazy to do so...

@Changelog

Not sure whether that would make a lot of sense, since most changes are internal stuff the common user doesn't care about. Also GitHub does already kinda provide it, thanks to commit & release notes.

@Dragon01

Getting some logs would be nice, if it still doesn't work. Both KSP_Data\output_log.txt and GameData\LoadOnDemand\LoadOnDemand.log, please, if existent.

Edit@Proot

Would love some details... can you maybe even give me a list? (Lod should do so in KSP.log, search for REM_IMG)

__

As for the future development... i don't know, yet. There is a lot of stuff that could be optimized... compression for loaded textures, speeding up loading & especially first "preperation" of a texture. I also really hate that my test environment pretty reliably crashes (in ~2 of 3 tries since 2.2) after preparing around ~1k7/2k8 images due to OutOfMemory but does run though just fine once KSP is restarted. Sure, getting rid of even more always loaded data could be done as well. Offering an easy to use interface to LOD so other mods can load and unload however they want should be easy, but wouldn't save that much. CityLights+Clouds for example take about 60mb, though 40 of them for kerbin and would thus have to be loaded most of the time. Mods like KerbinCity might profit, but only if all of their textures have to be loaded at the same time. I can't really say anything about unloading other stuff like planets, audio or meshes, since i neither know how much memory can actually be "saved" nor how much work it would require.

Maybe for now the best step is to take care of all issues that prevents this mod from moving to an official release in "Releases and Projects Showcase", so especially such suggestions would be very welcome!

[ShadyAct]

I always wondered why Kerbal Space needed to load every texture in the game to start. I mean, what if Skyrim did that?

[Proot]

Loadondemand.log remains white after the first line. In every try. So I can't tell you a lot...

The game loads seem to finish (some times at 2.7GB, some at 3.1GB...), but the game crashes before the main title.

My log: https://mega.co.nz/#!4pMynRJS!WoSNK3NLU9Pz1_eTzfhznnb94Twx1gfTgCNUTJIPesM

[SpacedInvader]

That sounds great, any crashes?

No crashes as of yet. Crash I experienced with the previous version were almost always resulting from part heavy vehicles rebuilding multiple times (return to VAB mostly) which that version just didn't handle very well. I've kind of trained myself not to do that, but I guess I could go back to old habits for the sake of testing

[Faark]

Looks like TextureReplacer might interfere with LOD.

Hm, TextureReplacer doesn't seem to replace part textures, so that shouldn't be a problem. But it does try to compress all textures... likely including the ones this mod wants to handle. You might want to try turning it of in your TextureReplacer.tcfg (isCompressionEnabled).

But the actual exception details aren't in that log & should be found in GameData\LoadOnDemand\LoadOnDemand.log, in case turning of TextureReplacers compression doesn't help.

Crash I experienced with the previous version were almost always resulting from part heavy vehicles rebuilding multiple times (return to VAB mostly) which that version just didn't handle very well. I've kind of trained myself not to do that, but I guess I could go back to old habits for the sake of testing

K, will test around a bit and see what i can improve. Even fast VAB browsing could use some improvements... i have to admit

Edited April 9, 2014 by Faark

[Lifeforce87]

This plugin is so awesome, iam using KAS, kethane, ex. launchpads, near future propulsion pack, EnvironmentalVisualEnhancements, RasterpropMonitor, LLL Full, Universal Storage, TweakableEverything, Procedual Wings, Ferram Aerospace Research, Skillful Combat dammage and weapons mod, Ksp interstellar, Procedual Fairings, chatterer, quantum struts, DMagic Orbital Science and RLA stockalike parts at the same time mostly without any problems. It only crashes sometimes while clicking through the part tabs in vab / sph. Awesome work!

And sorry for my english, its not my native language

[Bloodbunny]

I'm glad this awesome little plugin is still being developed. Random crashes were down, but still there in 2.1. I check the thread and lo and behold, a new update . Will try straightway!

Lifeforce: Yup, that is the only time it seems to crash.. not sure what is causing it. I found the crashes can be *somewhat* reduced by letting the textures load fully before switching pages. Crashing in the VAB/SPH is BAD though because of the potential for lost work. You might try loading all textures in the VAB if you can get under the memory ceiling, then unloading them before going to the pad.

[Eggman360]

I'm glad this awesome little plugin is still being developed. Random crashes were down, but still there in 2.1. I check the thread and lo and behold, a new update . Will try straightway!

Lifeforce: Yup, that is the only time it seems to crash.. not sure what is causing it. I found the crashes can be *somewhat* reduced by letting the textures load fully before switching pages. Crashing in the VAB/SPH is BAD though because of the potential for lost work. You might try loading all textures in the VAB if you can get under the memory ceiling, then unloading them before going to the pad.

That's a good idea unloading them after launch

To compliment this I'm developing an add-on to the procedural parts mod that aims to reduce the part count in the VAB/SPH by rolling a mod's resource storage tanks into single procedural ones per mod, check out my thread: http://forum.kerbalspaceprogram.com/threads/75761-WIP-%280-23-5%29-Procedural-Parts-mod-compatibility-extra-tanks and tell me what you think the examples used are for TAC life support

[Proot]

Looks like TextureReplacer might interfere with LOD.

But the actual exception details aren't in that log & should be found in GameData\LoadOnDemand\LoadOnDemand.log, in case turning of TextureReplacers compression doesn't help.

Excuse me, I didn't see this until now. GameData\LoadOnDemand\LoadOnDemand.log remain empty in every try to load the game.

I guess that's another symptom.

[Quiana]

I know this is slightly a derail but for those asking about 8.1 and KSP? Yes, it works fine, brilliantly even. Though I think my joystick is the issue at times with throttle control (it likes to get stuck at 5-10% throttle as the 'base' and require me to unplug/replug it while running). Even then it will reconnect and the game recognizes it just fine with the throttle back to normal. It is also really, really stable in terms that even a GPU crash can sometimes recover and continue playing a game on the rare chance one does occur (I've had Far Cry 3 nuke my video card and Windows managed to restore it, while the game was running, and pick up where it left off).

As for the mod, I'm curious if this would completely negate the use for ATM or not. I haven't visually noticed any differences in texture quality with it (I run basic and have settings cranked up to silly) but then again, not all texture issues would be noticed when working at medium distances from objects. Even close-up I have not really noticed any significant difference in it, then again I'm sure if the load on demand can be worked to a fine-tune it might just not require worrying about compression. Not to excuse some textures which are far too large though (who makes 1024x1024 textures for a tiny button after all? X.x).