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

[rbray89]

So why does activetexturamanagement.cfg 4.1 have "compress_normals=false " while it is "compress_normals=true" on 4.2? D:

And I didn't confuse files, since 4.2 first loading is definitely many times faster than 4.1

Oh, haha, that is the nature of the bug... I realized I never implemented raw, uncompressed textures until it was too late, so when I did add them in 4.2, I altered the config so they would not have to be re-cached, and memory performance would still be similar.

[Agost]

Oh, haha, that is the nature of the bug... I realized I never implemented raw, uncompressed textures until it was too late, so when I did add them in 4.2, I altered the config so they would not have to be re-cached, and memory performance would still be similar.

So, what could happen if I set compress_normals on false in 4.2? Just more memory usage?

p.s.: sorry if I'm polluting this thread with lots of questions, tell me if I'm asking too much

[rbray89]

So, what could happen if I set compress_normals on false in 4.2? Just more memory usage?

p.s.: sorry if I'm polluting this thread with lots of questions, tell me if I'm asking too much

No worries.

More memory usage & higher quality textures, though they are normal maps so you probably wouldn't really notice.

[curtquarquesso]

Hey rbray89,

Have had an issue ever since I updated ATM. Haven't updated any other mods. Was running very stable under the last stable version. Either 4-0 or 4-1, whichever version introduced the hour-long initial load with great stability.

Log: https://www.dropbox.com/s/cjfbu1n9l0uob2k/Player.log?dl=0

Edited December 12, 2014 by curtquarquesso
link

[Agost]

No worries.

More memory usage & higher quality textures, though they are normal maps so you probably wouldn't really notice.

Since I'm tweaking settings, I have a question for you:

What's the main difference between compression and resizing? Is it better ( memory wise) compressing a texture with a scale of 2 or resizing a texture to half width and lenght? Which one gives better image quality?

[Fizwalker]

With 4-2 and the times for caching various files, would itvbe worth it to do the initial boot up inder x64 to run the cache and then run the game in 32?

[daawgees]

With 4-2 and the times for caching various files, would itvbe worth it to do the initial boot up inder x64 to run the cache and then run the game in 32?

Clever idea, but ATM has 64 and 32 bit flavors and you would need to use the corresponding KSP version in order to load.

[rbray89]

Hey rbray89,

Have had an issue ever since I updated ATM. Haven't updated any other mods. Was running very stable under the last stable version. Either 4-0 or 4-1, whichever version introduced the hour-long initial load with great stability.

Log: https://www.dropbox.com/s/cjfbu1n9l0uob2k/Player.log?dl=0

Running with Mac or Linux? Looks like you didn't follow instructions. you May need to load it MULTIPLE times. Looks like you only loaded it once. (no log entries about loading textures from cache files)

Since I'm tweaking settings, I have a question for you:

What's the main difference between compression and resizing? Is it better ( memory wise) compressing a texture with a scale of 2 or resizing a texture to half width and lenght? Which one gives better image quality?

VERY good question. To answer this, we go to the math: an RGB or RGBA texture uses 1 byte per component per pixel, so that is 3 bytes for RGB and 4 for RGBA.

With DXT, those numbers become 1 byte per pixel for DXT5 and HALF a byte for DXT1.

So, to get the same memory value out of your textures, you would have to shrink an RGBA texture by 4 to get the same usage.

Whichever you choose, textures WITH mipmaps are %33 larger.

DXT is lossy, so there is some color error, but overall, it should look better than an RGBA texture, and perform better too as it is yanked in and out of graphics memory.

With 4-2 and the times for caching various files, would itvbe worth it to do the initial boot up inder x64 to run the cache and then run the game in 32?

Probably not. I'd imagine all platforms would fare about the same on the same HW. That being said, if you have enough RAM, and the caching would crash due to memory issues, it might be worth it then.

Edited December 12, 2014 by rbray89

[rbray89]

Clever idea, but ATM has 64 and 32 bit flavors and you would need to use the corresponding KSP version in order to load.

I believe they were talking about running it in x63, and then copying the cache folder out into ATM. Cache files are platform agnostic

[daawgees]

Probably not. I'd imagine all platforms would fare about the same on the same HW. That being said, if you have enough RAM, and the caching would crash due to memory issues, it might be worth it then.

I stand corrected, apologies.

[riederbirk]

I'll see if I get it to work without FAR!

Nope. For now I switched to x86 basic, seems like KSP x64 for Windows really is too buggy.

Great Mod though!

[Agost]

VERY good question. To answer this, we go to the math: an RGB or RGBA texture uses 1 byte per component per pixel, so that is 3 bytes for RGB and 4 for RGBA.

With DXT, those numbers become 1 byte per pixel for DXT5 and HALF a byte for DXT.

So, to get the same memory value out of your textures, you would have to shrink an RGBA texture by 4 to get the same usage.

Whichever you choose, textures WITH mipmaps are %33 larger.

DXT is lossy, so there is some color error, but overall, it should look better than an RGBA texture, and perform better too as it is yanked in and out of graphics memory.

How to choose between DXT and DXT5?

You said that a compressed pixel is 1 or 0.5 bytes, while RGB/RGBA uncompressed pixel are 3-4 bytes: but which compression scale did you take in account? 2? 4?

Moreover, if a DXT pixel is 1 byte, a resized RGBA texture with half width and lenght would have the same data size as the corresponding DXT compressed (but full size) texture, wouldn't it?

I believe they were talking about running it in x63, and then copying the cache folder out into ATM. Cache files are platform agnostic

I think that many mods which block x64 version don't even load their files with the x64 exe

[rbray89]

How to choose between DXT and DXT5?

You said that a compressed pixel is 1 or 0.5 bytes, while RGB/RGBA uncompressed pixel are 3-4 bytes: but which compression scale did you take in account? 2? 4?

Moreover, if a DXT pixel is 1 byte, a resized RGBA texture with half width and lenght would have the same data size as the corresponding DXT compressed (but full size) texture, wouldn't it?

I think that many mods which block x64 version don't even load their files with the x64 exe

DXT1 does not have a component for alpha, so it would be compared against RGB, wheras DXT5 has an alpha component and is used with RGBA textures.

Ah, yes, I goofed a bit. The resize factor should be squared to get pixel count factor, so resizing by 1/2 would result in x4 pixel reduction.

[Agost]

DXT1 does not have a component for alpha, so it would be compared against RGB, wheras DXT5 has an alpha component and is used with RGBA textures.

Ah, yes, I goofed a bit. The resize factor should be squared to get pixel count factor, so resizing by 1/2 would result in x4 pixel reduction.

I'll make some tests. Even if it will take lots of time...

Is there any major difference between basic and aggressive other than the main ATM.cfg?

[rbray89]

I'll make some tests. Even if it will take lots of time...

Is there any major difference between basic and aggressive other than the main ATM.cfg?

No. The ATM config is the only difference.

[Agost]

No. The ATM config is the only difference.

Perfect. Tweaking process started, I hope I'll get decent results. Aggressive after some time with Basic is a bit uncomfortable :/

[curtquarquesso]

Running with Mac or Linux? Looks like you didn't follow instructions. you May need to load it MULTIPLE times. Looks like you only loaded it once. (no log entries about loading textures from cache files) :/

I've tried it about a dozen times so far with no result. It finishes the file loading, I see the KPS Loading animation in the bottom right, and it crashes before it gets to the main menu. I'm going to try removing some larger mods to see if it launches.

[Agost]

Just noticed that Interstellar ( Warp Plugin ), which takes a lot of memory, almost doesn't get any compression/resizing at all. Is there any reason for this? Maybe some issue with compression? Sounds a bit strange

[rbray89]

Just noticed that Interstellar ( Warp Plugin ), which takes a lot of memory, almost doesn't get any compression/resizing at all. Is there any reason for this? Maybe some issue with compression? Sounds a bit strange

A lot of those textures are resource maps. Obviously, they shouldn't be compressed or resized, but they also don't need mipmaps for that reason too.

[Agost]

A lot of those textures are resource maps. Obviously, they shouldn't be compressed or resized, but they also don't need mipmaps for that reason too.

Yes, but KSPInterstellar has a whopping 122MB of parts. First override of the .cfg is:

OVERRIDES

{

WarpPlugin/[^/]*

{

compress = true

mipmaps = false

scale = 1

max_size = 0

make_not_readable = false

}

Which means that the whole directory does not get compressed, if I'm not wrong, since the scale is 1. The loading times kinda confirm this, since the whole WarpPlugin/stuff takes way less time than other mods.

Are these lines correct to compress parts only?

OVERRIDES

{

WarpPlugin/Parts/.*

{

compress = true

mipmaps = true

scale = 2

max_size = 0

make_not_readable = true

}

[rbray89]

Yes, but KSPInterstellar has a whopping 122MB of parts. First override of the .cfg is:

OVERRIDES

{

WarpPlugin/[^/]*

{

compress = true

mipmaps = false

scale = 1

max_size = 0

make_not_readable = false

}

Which means that the whole directory does not get compressed, if I'm not wrong, since the scale is 1. The loading times kinda confirm this, since the whole WarpPlugin/stuff takes way less time than other mods.

Are these lines correct to compress parts only?

OVERRIDES

{

WarpPlugin/Parts/.*

{

compress = true

mipmaps = true

scale = 2

max_size = 0

make_not_readable = true

}

WarpPlugin/[^/]*

resolves to "anything in the root of WarpPlugin that doesn't exist in a subfolder". so WarpPlugin/texture.png would be handled by this, but WarpPlugin/parts/texture.png would NOT.

The parts are getting compressed. I just double-checked your logs.

[Agost]

WarpPlugin/[^/]*

resolves to "anything in the root of WarpPlugin that doesn't exist in a subfolder". so WarpPlugin/texture.png would be handled by this, but WarpPlugin/parts/texture.png would NOT.

The parts are getting compressed. I just double-checked your logs.

D:

Well, sorry, I'm not a code expert

Thank you for the patience. I'll probably mix some BA textures to get acceptable results now, in order to reduce ram footprint

[rbray89]

D:

Well, sorry, I'm not a code expert

Thank you for the patience. I'll probably mix some BA textures to get acceptable results now, in order to reduce ram footprint

No worries. I mean to state things factually, sorry if I come off harsh sometimes.

The other thing you can do is reduce the "max" texture sizes in the main config. If you change them from something other than 0, that will be the max texture allowed. This can also be useful for mac computers, to reduce 8k or 4k textures to 2048 as an example. Can save quite a bit of memory that way.

[Agost]

No worries. I mean to state things factually, sorry if I come off harsh sometimes.

The other thing you can do is reduce the "max" texture sizes in the main config. If you change them from something other than 0, that will be the max texture allowed. This can also be useful for mac computers, to reduce 8k or 4k textures to 2048 as an example. Can save quite a bit of memory that way.

Yes, I know that, but now I'm trying with already smaller textures. Is it a good idea to make clouds in BoulderCo not readable?

[rbray89]

Yes, I know that, but now I'm trying with already smaller textures. Is it a good idea to make clouds in BoulderCo not readable?

No. Volumetric clouds won't work then (I'm planning on changing this in the future though).