[1.0][Release-5-0][April 28, 2015] Active Texture Management - Save RAM!

[TheFireRodan]

BF4 although it has 60 Gig of assets, will only need to load the assets for a given map or level. KSP on the other hand has to load all of the assets into memory because the entire game is 1 huge map/level. KSP has to have all of the assets ready to go in case they are needed.

However, the models+meshes of a singular level outweigh the universe; also, I could go on about Skyrim (visually modded), Watch_Dogs, ect. END OF IRRELEVANCY.

because what we are talking about here is RAM used for the 3D Rendering Engine. and OpenGL uses less RAM to process 3D rendering than DX9. DX9 is the default render for KSP, but you can force it to run under OpenGL or DX11 for that matter, and it will reduce your memory usage drastically. both are done the same way...

create a shortcut to KSP if you do not already have one. and then on the line that says target: type this...

{your KSP install path}\KSP.exe -force-opengl

or

{your KSP install path}\KSP.exe -force-d3d11

you can also tag on to the end another switch "-popupwindow" to force KSP to run as a borderless window.

i.e.

{your KSP install path}\KSP.exe -force-opengl -popupwindow

with either of these 2 methods you will use quite a bit less RAM and allow you to load another mod or 2. or maybe turn EVE up to better quality or maybe just reduce the scaling factor in ATM to get all textures to a better quality.

Wouldn't switching to DX11/OpenGL from DX9 cause some visual bugs? no other game i have played had a smooth transition without the feature hardcoded.

Edited November 27, 2014 by TheFireRodan

[Bob Jub]

I installed this mod and as soon as everything finished loading the game crashed... and I re-installed KSP and it still crashes after I install this mod.. It was working fine with just the large shuttle installed.

[TheFireRodan]

I installed this mod and as soon as everything finished loading the game crashed... and I re-installed KSP and it still crashes after I install this mod.. It was working fine with just the large shuttle installed.

Error log? RAM usage? (task manager should be <3,200mb for KSP.exe)

[Bit Fiddler]

Wouldn't switching to DX11/OpenGL from DX9 cause some visual bugs? no other game i have played had a smooth transition without the feature hardcoded.

Yes there are a few visual issues. mostly people report that during reentry or high speed atmospheric flight the ship textures will bug out. this does not crash the game it just removes the texture from your parts. turns them all black or sometimes pink. and in DX11 there seems to be some black lines on the floor/ground at KSC. however these bugs are very minor compared to the memory saving the 2 modes give you over DX9.

the ability to load more mods has been the bane of KSP since day 1. so like this mod which you sacrifice texture quality for memory savings, you have to make a trade off. What ever you find acceptable to allow the game to run the mods you wish to use. or you must switch to 64bit version which can use far more RAM but then introduces a whole new set of problems in that it is very unstable on any platform other than Linux.

again it is all about compromise. What you are willing to give up in order to get a few more mods installed. as with the 32bit version you are limited to the 4 gigs of ram that a 32 bit application can access. thus with the overhead this leaves around 3.8 gigs of RAM usage until KSP will crash. if you are sitting on the main menu with more than 3.2 you are almost guaranteed a crash as the memory usage fluctuates while the program runs. and just to be safe you really should be on the main menu with under 3 gigs, but even then the memory leak in the .tga loader will bite you after a few reverts or scene changes which cause texture reloads.

[TheFireRodan]

Yes there are a few visual issues. mostly people report that during reentry or high speed atmospheric flight the ship textures will bug out. this does not crash the game it just removes the texture from your parts. turns them all black or sometimes pink. and in DX11 there seems to be some black lines on the floor/ground at KSC. however these bugs are very minor compared to the memory saving the 2 modes give you over DX9.

the ability to load more mods has been the bane of KSP since day 1. so like this mod which you sacrifice texture quality for memory savings, you have to make a trade off. What ever you find acceptable to allow the game to run the mods you wish to use. or you must switch to 64bit version which can use far more RAM but then introduces a whole new set of problems in that it is very unstable on any platform other than Linux.

again it is all about compromise. What you are willing to give up in order to get a few more mods installed. as with the 32bit version you are limited to the 4 gigs of ram that a 32 bit application can access. thus with the overhead this leaves around 3.8 gigs of RAM usage until KSP will crash. if you are sitting on the main menu with more than 3.2 you are almost guaranteed a crash as the memory usage fluctuates while the program runs. and just to be safe you really should be on the main menu with under 3 gigs, but even then the memory leak in the .tga loader will bite you after a few reverts or scene changes which cause texture reloads.

40% of my flights are mach 7 high atmosphere planes, so i'll take my pass.

64-bit ksp had no problems whatsoever for me, excepting that FAR disabled itself.

It appears I had an old mod I forgot to remove that adds a few new constructions around the KSC, which somehow totalled to .4 gigs of RAM.

Adding novapunch 2 had minimal impact on RAM usage.

So, therefore, anything not listed in the /gamedata/boulderco/activetexturemanagerconfigs will likely have a substantially higher memory impact.

Right?

Edited November 28, 2014 by TheFireRodan

[Bit Fiddler]

well in theory the mods not listed will have less impact, as the cfg files to my knowledge are telling ATM to not compress certain textures. therefore, any mod with no cfg, will by default compress all textures.

I could be wrong on this however.

Edited November 29, 2014 by Bit Fiddler

[TheFireRodan]

well in theory the mods not listed will have less impact, as the cfg files to my knowledge are telling ATM to not compress certain textures. therefore, any mod with no cfg, will by default compress all textures.

I could be wrong on this however.

ActiveTextureManagerConfigs/KWrocketry.cfg - entire file

"ACTIVE_TEXTURE_MANAGER_CONFIG

{

folder = KWRocketry

enabled = true

}"

[Zeenobit]

I recently switched from ATM Basic to ATM Aggressive (x86), hoping to reduce my memory usage.

Surprisingly, it seems like that increased my memory usage by around 300 MB.

What gives?

[sidfu]

I recently switched from ATM Basic to ATM Aggressive (x86), hoping to reduce my memory usage.

Surprisingly, it seems like that increased my memory usage by around 300 MB.

What gives?

delte the cache then once game startas all way up restart. the memory reduction dont take effect till send start.

[User Unrelated]

...but even then the memory leak in the .tga loader will bite you after a few reverts or scene changes which cause texture reloads.

So that explains my problem...

I sit around 2.5Gb on the main menu, but after 6 or 7 scene changes/reverts, I almost ALWAYS crash. I had no idea what was going on!

Hm... idk, I feel like there's nothing to do about this besides just deal with it, then. It tends to limit my play sessions to only a few hours, though, which could be seen as a good thing, as if the game ran seamlessly all the time, I'd be there all night!

I haven't had any data loss issues (except for one non-saved craft that didn't get autosaved when it crashed upon leaving the VAB to go to the astronaut complex)

[tajampi]

A notice to anybody who has memory problems with even the agressive version of this installed:

Disable mipmaps.

It can be noticed, but once you get to it, there is no quality difference, and saves a lot of memory (It might not save it on game launch, but comparing the RAM after 5 launches with mipmaps vs 5 with no mipmaps makes the difference )

EDIT: Also, deleting texturecache folder seems to reduce the RAM usage another 600 MB (I don't know whats going on with my ksp installation...)

Cheers!

Edited December 3, 2014 by tajampi

[TheFireRodan]

A notice to anybody who has memory problems with even the agressive version of this installed:

Disable mipmaps.

It can be noticed, but once you get to it, there is no quality difference, and saves a lot of memory (It might not save it on game launch, but comparing the RAM after 5 launches with mipmaps vs 5 with no mipmaps makes the difference )

EDIT: Also, deleting texturecache folder seems to reduce the RAM usage another 600 MB (I don't know whats going on with my ksp installation...)

Cheers!

That's likely from the cache inside from using the basic then upgrading to aggressive, and/or mods you uninstalled.

[rbray89]

Direct DXT loading is on it's way... Looks like I just have to do a little bit of rotation.

[LMA]

Which is the aggressive one to download?

[Virtualgenius]

With ATM and Open GL my game experience is far better than it ever has been. ATM was by far the best mod I ever downloaded and the opengl switch was just the cream cant wait for the new version

[Agost]

A notice to anybody who has memory problems with even the agressive version of this installed:

Disable mipmaps.

It can be noticed, but once you get to it, there is no quality difference, and saves a lot of memory (It might not save it on game launch, but comparing the RAM after 5 launches with mipmaps vs 5 with no mipmaps makes the difference )

EDIT: Also, deleting texturecache folder seems to reduce the RAM usage another 600 MB (I don't know whats going on with my ksp installation...)

Cheers!

Do you use EVE/ Better atmosphere? How does disabling mipmaps affect these mods?

Edited December 6, 2014 by Agost

[BudgetHedgehog]

I just installed the latest version of DDSLoader and ran Lillemans KSPtoDDS tool. Loaded up KSP and it crashed during startup. Monitering memory usage, never peaked above 2.3Gb, average was just below 2. Running KSP 0.25 x86 OpenGL, worked fine before DDS conversion so why am I posting here? The stack trace points to ATM. Anyone got any ideas? Did I do something wrong, are DDSLoader 1.7 and ATM 3.8 not compatible? Is ATM just not needed if I have DDSLoader?

Stack trace:

========== OUTPUTING STACK TRACE ==================

(0x5F9D1663) (atioglxx): (filename not available): DllMain + 0x663
(0x602A91DC) (atioglxx): (filename not available): DrvPresentBuffers + 0x89b0dc
(0x602B8705) (atioglxx): (filename not available): DrvPresentBuffers + 0x8aa605
(0x602B7605) (atioglxx): (filename not available): DrvPresentBuffers + 0x8a9505
(0x602B560E) (atioglxx): (filename not available): DrvPresentBuffers + 0x8a750e
(0x6024FD08) (atioglxx): (filename not available): DrvPresentBuffers + 0x841c08
(0x602524E4) (atioglxx): (filename not available): DrvPresentBuffers + 0x8443e4
(0x60254338) (atioglxx): (filename not available): DrvPresentBuffers + 0x846238
(0x602868DD) (atioglxx): (filename not available): DrvPresentBuffers + 0x8787dd
(0x6028681B) (atioglxx): (filename not available): DrvPresentBuffers + 0x87871b
(0x6023E759) (atioglxx): (filename not available): DrvPresentBuffers + 0x830659
(0x5FA98AF8) (atioglxx): (filename not available): DrvPresentBuffers + 0x8a9f8
(0x5FE29109) (atioglxx): (filename not available): DrvPresentBuffers + 0x41b009
(0x003E91AB) (KSP): (filename not available): AnimationEvent::Transfer<StreamedBinaryRead<1> > + 0x8438b
(0x003E03A4) (KSP): (filename not available): AnimationEvent::Transfer<StreamedBinaryRead<1> > + 0x7b584
(0x0014E259) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x40d69
(0x0014C4AB) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x3efbb
(0x0026CB55) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x15f665
(0x0408AA1F) (Mono JIT code): (filename not available):  (wrapper managed-to-native) UnityEngine.Texture2D:LoadImage (byte[]) + 0x2f (0408A9F0 0408AA5D) [03764E70 - Unity Root Domain] + 0x0
(0x141097DE) (Mono JIT code): (filename not available):  ActiveTextureManagement.TextureConverter:IMGToTexture (ActiveTextureManagement.TexInfo,bool,bool) + 0xae (14109730 14109AB1) [03764E70 - Unity Root Domain] + 0x0
(0x1410601F) (Mono JIT code): (filename not available):  ActiveTextureManagement.TextureConverter:GetReadable (ActiveTextureManagement.TexInfo,bool) + 0x25f (14105DC0 141060AC) [03764E70 - Unity Root Domain] + 0x0
(0x141058FE) (Mono JIT code): (filename not available):  ActiveTextureManagement.CacheController:RebuildCache (ActiveTextureManagement.TexInfo,bool,bool,bool) + 0x2e (141058D0 14105D56) [03764E70 - Unity Root Domain] + 0x0
(0x1410585E) (Mono JIT code): (filename not available):  ActiveTextureManagement.CacheController:FetchCacheTexture (ActiveTextureManagement.TexInfo,bool,bool,bool) + 0x66e (141051F0 1410586F) [03764E70 - Unity Root Domain] + 0x0
(0x1410409D) (Mono JIT code): (filename not available):  ActiveTextureManagement.DatabaseLoaderTexture_ATM:UpdateTexture (ActiveTextureManagement.TexInfo) + 0x54d (14103B50 141040DC) [03764E70 - Unity Root Domain] + 0x0
(0x141038BD) (Mono JIT code): (filename not available):  ActiveTextureManagement.DatabaseLoaderTexture_ATM/<Load>d__4:MoveNext () + 0x75 (14103848 14103916) [03764E70 - Unity Root Domain] + 0x0
(0x14103981) (Mono JIT code): (filename not available):  (wrapper runtime-invoke) <Module>:runtime_invoke_bool__this__ (object,intptr,intptr,intptr) + 0x41 (14103940 141039EA) [03764E70 - Unity Root Domain] + 0x0
(0x100F00B6) (mono): (filename not available): mono_set_defaults + 0x22bf
(0x1005D6DF) (mono): (filename not available): mono_runtime_invoke + 0x51
(0x00135C38) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x28748
(0x001D09F5) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0xc3505
(0x001D0B7E) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0xc368e
(0x001D09A1) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0xc34b1
(0x0012556D) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x1807d
(0x001257A3) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x182b3
(0x001277E1) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x1a2f1
(0x00128BAB) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x1b6bb
(0x002822E2) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x174df2
(0x040551FF) (Mono JIT code): (filename not available):  (wrapper managed-to-native) UnityEngine.MonoBehaviour:StartCoroutine_Auto (System.Collections.IEnumerator) + 0x2f (040551D0 0405523C) [03764E70 - Unity Root Domain] + 0x0
(0x040551BC) (Mono JIT code): (filename not available):  UnityEngine.MonoBehaviour:StartCoroutine (System.Collections.IEnumerator) + 0x14 (040551A8 040551C1) [03764E70 - Unity Root Domain] + 0x0
(0x0405A9D7) (Mono JIT code): (filename not available):  GameDatabase/
:MoveNext () + 0x178f (04059248 0405B9E7) [03764E70 - Unity Root Domain] + 0x0
(0x04055361) (Mono JIT code): (filename not available):  (wrapper runtime-invoke) <Module>:runtime_invoke_bool__this__ (object,intptr,intptr,intptr) + 0x41 (04055320 040553CA) [03764E70 - Unity Root Domain] + 0x0
(0x100F00B6) (mono): (filename not available): mono_set_defaults + 0x22bf
(0x1005D6DF) (mono): (filename not available): mono_runtime_invoke + 0x51
(0x00135C38) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x28748
(0x001D09F5) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0xc3505
(0x001D0B7E) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0xc368e
(0x001D09A1) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0xc34b1
(0x0012556D) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x1807d
(0x001257A3) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x182b3
(0x001257DF) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x182ef
(0x0010F0AE) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x1bbe
(0x0019F587) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x92097
(0x00213E4B) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x10695b
(0x0021566B) (KSP): (filename not available): Behaviour::Transfer<SafeBinaryRead> + 0x10817b
(0x0047E948) (KSP): (filename not available): AnimationEvent::Transfer<StreamedBinaryRead<1> > + 0x119b28
(0x004B3830) (KSP): (filename not available): AnimationEvent::Transfer<StreamedBinaryRead<1> > + 0x14ea10
(0x750D919F) (KERNEL32): (filename not available): BaseThreadInitThunk + 0xe
(0x77160BBB) (ntdll): (filename not available): RtlInitializeExceptionChain + 0x84
(0x77160B91) (ntdll): (filename not available): RtlInitializeExceptionChain + 0x5a

========== END OF STACKTRACE ===========

Full log.

Edited December 7, 2014 by ObsessedWithKSP

[Kerbas_ad_astra]

I use ATM and DDSLoader together (with just about all of my textures converted to DDS) just fine -- not to say they will always work together, but there would have to be some other factor involved.

[Black-Talon]

Direct DXT loading is on it's way... Looks like I just have to do a little bit of rotation.

Hype all the *EXCITEMENT* !!!!

[rbray89]

Alright, so DXT loading is on it's way... and WOW. Loading is fast. Blazing. Memory usage is down, and things look great!

Downside is the first loading takes a LONG time. A REALLY long time. Good news is that it only has to happen once.

For brave souls: https://github.com/rbray89/ActiveTextureManagement/releases/tag/4-0Beta

[Agost]

Alright, so DXT loading is on it's way... and WOW. Loading is fast. Blazing. Memory usage is down, and things look great!

Downside is the first loading takes a LONG time. A REALLY long time. Good news is that it only has to happen once.

For brave souls: https://github.com/rbray89/ActiveTextureManagement/releases/tag/4-0Beta

Does it require DDSLoader?

Moreover, what should I do with B9 ATM .cfg? Replace your stock one with that or just delete the one in BoulderCo?

[bstpierre]

On my install (63 folders in GameData, AVC reports 29 mods and I've removed many similar parts), I usually sit at 1.78G on the startup screen, with ~1.8G in the VAB in an otherwise empty sandbox save with a modified cfg with scale & normals_scale set to 8.

With the aggressive 4.0 beta installed with scale back up to the default of 2, I'm now sitting at 628MB(!) on startup screen and 950MB(!) in the VAB.

Generation of the cache took well over an hour, and it was well worth it. I'll report back later today after having played a while if I notice any issues.

[Saint-Stanislas]

Similar Result here ( with 4.0 )

Scaled down from 2.3Gb/2.6Gb to 1.7Gb/1.9b. It took around an hour and a half to load, I'm restarting too see how's the second loading time. Also, I have tried exiting the game from space center, and when I press " Back to Main Menu" the small menu screen stays on while a loading screen appears in the back. You can still resume the game and it's going back to space center...

I don't have a log and use tons of mods, there are good chances it's something else that I installed at the same time ( UbioZurWelding tool or VesselViewer ).

[BudgetHedgehog]

Mine (aggressive 4.0) crashed during load because it ran out of memory ¯\_(ツ)_/¯

[Saint-Stanislas]

On my install (63 folders in GameData, AVC reports 29 mods and I've removed many similar parts), I usually sit at 1.78G on the startup screen, with ~1.8G in the VAB in an otherwise empty sandbox save with a modified cfg with scale & normals_scale set to 8.

With the aggressive 4.0 beta installed with scale back up to the default of 2, I'm now sitting at 628MB(!) on startup screen and 950MB(!) in the VAB.

Generation of the cache took well over an hour, and it was well worth it. I'll report back later today after having played a while if I notice any issues.

Are you using DDS loader at the same time ?

My atm configs are as low as before the installation, scale and normal resize to 8, and no mipmap, but You get stronger effects somehow. Maybe some texture I ddsified would have been handled better by atm?

I have not much understanding in this, but I guess I could exclude dxt files when I convert to dds so they would be managed by atm again. Could this be the difference explaning our performance difference ?