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

[rbray89]

Hey cool!

Suggestion: add support for a CFG file with structure

TextureCompressorBlacklist
{
	texturename1 = true
	texturename2 = true
	texturename3 = true
	// etc
}

And then before compressing a texture, check if the node HasValue(texture url) and if so skip it.

That way any, say, UI textures, that need to be left uncompressed, can be.

I like that. Blacklisting textures.

[Gristle]

Does this mod do the same thing? Can they coexist together to further decrease RAM usage?

http://forum.kerbalspaceprogram.com/threads/49011-Testing-Compressing-Textures-in-Memory?highlight=compressram

[rbray89]

Does this mod do the same thing? Can they coexist together to further decrease RAM usage?

http://forum.kerbalspaceprogram.com/threads/49011-Testing-Compressing-Textures-in-Memory?highlight=compressram

Mine basically has more logic to it. Stops error messages from filling up the logs, skips textures that are already compressed, only does this once.

[Tw1]

The witchcraft is ready! Great! More room to pig out on modsNo more crashes more hopefully!

Edited November 21, 2013 by Tw1

[s20dan]

900MB-1GB reducton in memory use with this and a very heavily modified copy Thanks.

[Camacha]

I am very happy this mod exists, I am sad it needs to exist.

[Stone Blue]

Excellent!...Gonna try this tonight!...

I already cut quite a few hundred MB by using the Squad reduction pack, and deleteing about 2/3's of the stock parts, then I cut another 750-900MB by setting up a 2nd, dual-boot Windows install with services cut to the very minimum, and only minimum necessary hardware drivers (basically just system and video), no firewall/antivirus either (this is the only downside: no internet access while playing, but not really a biggie now, since I recently got a tablet. ), and absolutely NO SOFTWARE installed EXCEPT KSP...

My regular Win7 install runs 1.25-1.4GB RAM at idle...with the cut-down KSP Win7 install, runs at 529MB RAM....All you need is an extra 25GB+(1.5 times your installed RAM for your pagefile), on your harddrive to set up a dual-boot partition.

Edited November 21, 2013 by Stone Blue

[CaelReader]

Cut my RAM on startup from 3.2GB to 2.3GB, Excellent work! It was pretty awesome watching the RAM usage plummet as the textures compressed.

[DresCroffgrin]

Decided to show up and report my savings at about 900 MB. You, sir, deserve the biggest, shiniest medal that these forums have to offer.

[Guest]

I'm seeing roughly 850MB reduction in RAM consumption. Now I can definitely start on reworking my UR700!

Outstanding work!

[MOARdV]

Nice. I went from 2.8 gigs to 2.3. Which makes me wonder how I got down to 2.8 to start with - I'm typically 3.5+. I must have pruned out a lot of disused parts recently. But still, a reduction of nearly 1/6 of the working set is nothing to sneeze at.

Does this generate a full mipmap chain, or does it just convert level 0 to DXT? If it does the full chain, does that mean it's also making mipmaps for PNG files?

[therealcrow999]

I tried that mod with this one, didn't do anything further. So your better off just using this mod.

Does this mod do the same thing? Can they coexist together to further decrease RAM usage?

http://forum.kerbalspaceprogram.com/threads/49011-Testing-Compressing-Textures-in-Memory?highlight=compressram

[sirkut]

I saw a drop in 800MB. Kudos for this!

[Nuke]

i didnt know this was a thing that could be done with a mod. frankly this is something squad should have done a long time ago.

anyway with reference to normal maps, is there a way to use dxt5_nm. this essentially puts the red channel into dxt5 alpha. this makes the channels interpolate independently (color data interpolates together), and also gives you a bit more depth on one channel. there is also a newer format (3dc/bc5) that is essentially a two channel format (they are similar to the way dxt5's alpha works) which could give even higher normal map quality for the same cost. there is also a one channel version that could give us better greyscale quality for things like emmission maps.

http://en.wikipedia.org/wiki/3Dc

Edited November 21, 2013 by Nuke

[NathanKell]

Nuke: http://docs.unity3d.com/Documentation/ScriptReference/Texture2D.Compress.html

TL;DR: Not while using that command.

[rbray89]

i didnt know this was a thing that could be done with a mod. frankly this is something squad should have done a long time ago.

anyway with reference to normal maps, is there a way to use dxt5_nm. this essentially puts the red channel into dxt5 alpha. this makes the channels interpolate independently (color data interpolates together), and also gives you a bit more depth on one channel. there is also a newer format (3dc/bc5) that is essentially a two channel format (they are similar to the way dxt5's alpha works) which could give even higher normal map quality for the same cost. there is also a one channel version that could give us better greyscale quality for things like emmission maps.

http://en.wikipedia.org/wiki/3Dc

Not that I'm aware of.

[Galacticruler]

Now tell me, why aren't you a Squad employee?

[Dante80]

Reporting a saving of 600MB memory (2.2 from 2.8) with a heavily modded load. I think I can put full B9 and AEIS now together with NP,KW,KSPI and NFP!

Thanks a lot man, this is the perfect stopgap until we have a 64bit KSP in windows!

[johnsonwax]

This is really fantastic. Thank you for doing this. I had recently tried to add interstellar and it killed RAM. Runs great now. I'll see if I can squeeze clouds in now.

[Galacticruler]

alright, so I gave it a go, but it seems that I've managed an INCREASE in RAM usage...however this fixed the ocean lag.

[Majiir]

We discussed using a method exactly like this in #kspmodders a couple months back. I wrote a plugin that looks similar to yours, even. At the time, we determined this wasn't practical because most or all textures in GameDatabase are marked unreadable, and Compress() calls simply output an error. Is the GetPixel() call before Compress() solving that problem? That's a nifty little hack.

Have you considered checking texture sizes before and after the compress operations so you can output a hard number on how much memory is saved? Anecdotal reports are often way, way off. (I've had complaints that a Kethane update increased memory consumption by 100MB when thorough analysis shows the plugin only using maybe 100 kilobytes more. A lot of numbers will be inflated by wishful thinking.)

[NathanKell]

Also if you can output the URL of every texture you process, so we can go back and add to blacklist if necessary.

[rbray89]

We discussed using a method exactly like this in #kspmodders a couple months back. I wrote a plugin that looks similar to yours, even. At the time, we determined this wasn't practical because most or all textures in GameDatabase are marked unreadable, and Compress() calls simply output an error. Is the GetPixel() call before Compress() solving that problem? That's a nifty little hack.

Have you considered checking texture sizes before and after the compress operations so you can output a hard number on how much memory is saved? Anecdotal reports are often way, way off. (I've had complaints that a Kethane update increased memory consumption by 100MB when thorough analysis shows the plugin only using maybe 100 kilobytes more. A lot of numbers will be inflated by wishful thinking.)

Yup, Exactly. I found the exact same issue. The GetPixel creates an exception for textures that can't be read. Don't know why Compress Doesn't do the same.

[MaxP]

Hmmm... Reduced allocated RAM from 3.2 to 2.7 GB. Sounds like magic, will test it.

[Xentoe]

Reducting from 3,5 Gb down to 2,2 Gb

Huiiiii

KSP Interstellar

B9

Novepunch

This nice Cloud Mod

Kethane

Near Nuture

ScanSat