[WIP] Loading textures only as required

[Faark]

Hey Unanimous,

you are talking about version 3.1 i linked in the post above yours? I cannot reproduce this error on my test installs. Could you please share you KSP_Data\output_log.txt and GameData\LoadOnDemand\LoadOnDemand.log?

[UnanimousCoward]

Hey Unanimous,

you are talking about version 3.1 i linked in the post above yours? I cannot reproduce this error on my test installs. Could you please share you KSP_Data\output_log.txt and GameData\LoadOnDemand\LoadOnDemand.log?

Try this link...

Edit: Yes, I did mean 3.1. Screen grab:

Edited June 9, 2014 by UnanimousCoward

[Faark]

Thanks.

Wow, you have a lot of mods screaming in your log files. The one LOD complainied about seems to be caused by TR killing textures unrelated to LOD. But LOD still didn't expect such "invalid" textures when it collects debug infos about textures it doesn't manage. So yes, nothing serious at all in case this particular case, though I've uploaded a fixed version (same link). Also interesting that it doesn't happen on the last version.

___

Anyone else found any issues or can i update the start page link?

[UnanimousCoward]

Thanks.

Wow, you have a lot of mods screaming in your log files. The one LOD complainied about seems to be caused by TR killing textures unrelated to LOD. But LOD still didn't expect such "invalid" textures when it collects debug infos about textures it doesn't manage. So yes, nothing serious at all in case this particular case, though I've uploaded a fixed version (same link). Also interesting that it doesn't happen on the last version.

___

Anyone else found any issues or can i update the start page link?

Umm, still get same issue at main menu... Same DL link, right? I've tried it twice and same problem. No stress, I can just ignore it as it seems to work anyway.

Probably one of my many other mods throwing a hissy fit. I've noticed all the exceptions before, but my game is pretty darn stable, so I figured :shrug: If it ain't that broke that it screws things up, don't bother fixing it...

I'm amazed and gratified by your incredibly quick responses, BTW. Better "customer service" than almost anybody I pay for their services...

[Beetlecat]

Thanks again for the reports, it should be fixed with the next version.

Actually, here it is: LOD 3.1 - TGA transparency fixed, Parts not loading fixed

Yay! Cheers for that.

Parts not loading -- by this do you mean texture replacer part textures, or are those still off-limits?

[Faark]

@Unanimous

Fu my fault, i uploaded the wrong file (same as earlier). Please try again, i've now uploaded the correct one.

@Beetlecat

Its just about the bug reported by BananaDealer. TR replacements for parts are still not supported.

[BananaDealer]

@Unanimous

Fu my fault, i uploaded the wrong file (same as earlier). Please try again, i've now uploaded the correct one.

@Beetlecat

Its just about the bug reported by BananaDealer. TR replacements for parts are still not supported.

Yep, the new version seems to have fixed the issue.

[Bloodbunny]

Nice! A new update to a mod that just keeps getting better.. Though I must say, it looks like 64 bit KSP may eclipse this fairly soon.

[Guest]

Not really. If KSP keeps loading all textures on launch, it'll be hitting all sorts of limits. In most games, LOD-like functionality is normal and hardcoded. KSP's way of handling textures is downright idiotic, as is it's handling of a case when there's not enough space to load them.

[beaucoupzero]

Thank you Faark, IVA transparency is no longer an issue. keep up the good work!

[dRuPpI]

I don't really want to know anything about TGA file formats, to be honest. That is why i am using external code to take care of that and it seem to handle quite a few cases. I have no idea who is breaking the format rules (and frankly don't want to know), but this mod a. has to load those apparently somewhat frequently used TGAs properly and b. most other loaders i've found on the net and could switch to seemed to be very "limited", thus also not an optimal solution.

Instead I now have modified the current loader to default to Argb for 32bpp TGAs. We'll see whether this breaks sth else... please leave a note in that case.

Thanks again for the reports, it should be fixed with the next version.

Actually, here it is: LOD 3.1 - TGA transparency fixed, Parts not loading fixed

why not adding a PNG Converter to LOD?

[Beetlecat]

@Unanimous

Fu my fault, i uploaded the wrong file (same as earlier). Please try again, i've now uploaded the correct one.

@Beetlecat

Its just about the bug reported by BananaDealer. TR replacements for parts are still not supported.

Cool beans.

3.1 fixes the window transparency using the original mod file. I may have been distracted by that mission enough to not notice, but there are quite a few other detail textures still missing when using LOD:

Javascript is disabled. View full album

--Maybe this is simply up to the mod author to do this "properly" -- I've not seen this type of thing on squad IVAs. And, to be honest, a minor annoyance for what LOD brings.

Edited June 10, 2014 by Beetlecat
pictures

[Bloodbunny]

Most things are fixed, but Raster Prop Monitor still has issues

Edited June 10, 2014 by Bloodbunny

[BananaDealer]

Found another little hiccup just now, whilst designing a new shuttle...

The External Tanks from the Shuttle Engines mod turn up black, both in the catalog (as thumbnails) and after getting placed.

Oh, and here's the log...

https://www.dropbox.com/s/pgehslcxqwetokf/LoadOnDemand%20%281%29.log

Edit: Some other parts are showing missing/black textures as well...

Edited June 10, 2014 by BananaDealer

[Guest]

Strangely, they all work fine for me... I'll update to the latest version of everything, though.

[SebFierce]

Transparency issue seems mostly fixed with the new version, nice

Unfortunately my game still crashes on either "return to SPH/VAB", logs are here (in case they got missed two pages ago ): https://mega.co.nz/#!FAFgFDZa!FQRyPW4IensIeV0-p87JejWpbczquo6mlEmw7IvwMCA

[Faark]

Most things are fixed, but Raster Prop Monitor still has issues

RPM works fine on my test installs (Screen) with the latest LOD. Are you sure this isn't caused by some other mod? And what other mods are involved anyway?

Found another little hiccup just now, whilst designing a new shuttle...

[..]

The External Tanks from the Shuttle Engines mod turn up black, both in the catalog (as thumbnails) and after getting placed.

I may have been distracted by that mission enough to not notice, but there are quite a few other detail textures still missing when using LOD:

*sigh* Thats the kind of the issue i was afraid of... the now existing alpha channel is causing trouble in case its badly used. Had a similar problem while down-scaling images to low res not-loaded-thumbnails. They don't look great anyway, so i could use a crappy looking workaround. But that's ofc not acceptable for full detail images.

Thanks for the reports, guys. I'll look into it.

Transparency issue seems mostly fixed with the new version, nice

Unfortunately my game still crashes on either "return to SPH/VAB", logs are here (in case they got missed two pages ago ): https://mega.co.nz/#!FAFgFDZa!FQRyPW4IensIeV0-p87JejWpbczquo6mlEmw7IvwMCA

Its an OutOfMemory error. This is fine (*) if your KSP was already very close to the max amount of memory. But ofc could also be a bug, if there are some memory "spikes" or sth like that (I'd love have a vmmap graph for your particular case, but will also generate one like this it myself). As mentioned early, DXT compression is the next bigger feature coming to LOD (& probably the last till this mod reaches Scope Completion) and should reduce memory usage of loaded texture and thus crashes a lot.

Another approach might be to instead of crash just "abort" the load and display some kind of "could not load textures X. Ignore, Retry, ..." msg. Will think about it.

* = ofc not for the user, but from a development stand point.

Edited June 11, 2014 by Faark

[SebFierce]

Its an OutOfMemory error. This is fine (*) if your KSP was already very close to the max amount of memory. But ofc could also be a bug, if there are some memory "spikes" or sth like that (I'd love have a vmmap graph for your particular case, but will also generate one like this it myself).

I'll make a graph today in the evening and send it to you. Additionally I will try to make some mods I've installed lighter, some of them still contain parts I never use and which I forgot to remove in the first place. Thanks for your help!

Graph:

The values are a bit inflated since I had to tab out of KSP several times to refresh the tool. Still, in SPH and on the runway the values are almost constant but upon reverting to SPH it spikes. Maybe my install just has too little headroom to handle the spike and after that memory usage could continue normal.

Edited June 11, 2014 by SebFierce

[Mihara]

Most things are fixed, but Raster Prop Monitor still has issues

http://i.imgur.com/aRpTi9e.png

...That looks like an unrelated problem.

Grey screens commonly show up when RPM died so hard that it couldn't even complain about it, the most frequent cause in recent weeks is using a version of MechJeb that cannot be linked to because Squad's plugin loader checks for exact DLL versions. The most recent dev builds of MJ have changed version numbering policy to account for this. If RPM got fed a 32x32 font texture, it would happily try to print characters from it anyway, resulting in something amusingly garbled, but not a grey normal map from a spacesuit. (I wish I knew why it's this normalmap and not something else, though.)

[Beetlecat]

just figured out it breaks transparency in the alcor pod.

un-installing

Confirming this is still in 3.1 -- curious, the ALCOR uses pngs for the IVA graphics.

[SpacedInvader]

@Faark: Does the newest 3.1 version have the enhanced logging you had recommended I try out? I've been trying to do some playing in my free time over the last week or so and I've managed to build a station which now crashes the game 100% of the time as soon as it enters physics range when I try to rendezvous with it, something that has made me quite angry at the memory issues of this game. I really need to try and figure out why my install remains so heavy on memory usage, as it would seem that LOD + ATM on aggressive, while a great improvement, are still at the mercy of some other memory hog that is keeping me running on the edge of stability at all times.

I think you may be on to something when you suggested it might be non-part textures, as temporarily removing RSS from my install cut about 300-400 MB out of both the working and commit memory allocations. That being said, I got a similar, though smaller improvement upon removing FASA, which should be almost completely managed by LOD, leaving me to wonder if there is an issue with sheer part count rather than just textures. In addition to this, it seems that highly complex models have a tendency to eat up memory quite rapidly, leading me back to the idea that part models may be an issue as well. The FusTek parts, for example, add about 300MB of used memory when you add one, but then if you delete it and add it again, it actually adds another 150-300 MB, leading to a situation where I've been able to crash the game in the VAB with a high degree of replicability just by adding and deleting the same station part several times.

This also has me wondering if IVA textures are controlled by LOD. FASA has several highly detailed IVAs so if their component parts are not managed by LOD, that may also explain some of the memory use.

Something I'm finding quite odd relating to what I've said above, is that often parts in the game will generate much more memory use than their models and textures should. Again using FusTek as an example, though this applies to FASA, KWRocketry, and many other mods, the actual folder for the entire mod is only 12MB, but then using even a single part in the game garners memory use of as much as 300MB. This can't possibly be a texture issue, so where else could all of that extra memory be coming from?

EDIT: Sorry for the rambling post, I'm a little tired and a lot frustrated right now...

EDIT2: Going back and testing on my dev install which has far fewer mods has shown me that this issue is neither with LOD nor with FusTek in the examples above, but rather somewhere else. On that smaller install, I can add / remove the parts many times without issue. Short of going in and testing each mod in my install, is there any way to figure out where things are going wrong from the logs?

Edited June 13, 2014 by SpacedInvader

[SpacedInvader]

Confirming this is still in 3.1 -- curious, the ALCOR uses pngs for the IVA graphics.

I converted the ALCOR textures to tga and it fixed the black parts. It seems that PNG's aren't all that great in KSP, though converting all one way or all the other also doesn't seem to help much.

So I'm actually quite surprised here... This fix worked fine for v3, but I just upgraded to v3.1 and now it's back to having black parts...

Edited June 15, 2014 by SpacedInvader

[SpacedInvader]

Does anyone know of a way to convert to MBM? I have a theory I want to test....

[raxo2222]

Faark, you forgot to say, that "isMipmapGenEnabled" in Texture Replacer bust be on "never" too.

I'm using new Better Atmospheres.

[Citizen Joe]

Does anyone know of a way to convert to MBM? I have a theory I want to test....

I believe its detailed somewhere on the KSP wiki.