Jump to content

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


Recommended Posts

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.

Link to post
Share on other sites
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.

Link to post
Share on other sites

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

Edited by Tw1
Link to post
Share on other sites

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 by Stone Blue
Link to post
Share on other sites

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?

Link to post
Share on other sites

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 by Nuke
Link to post
Share on other sites
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.

Link to post
Share on other sites

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!

Link to post
Share on other sites

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.)

Link to post
Share on other sites
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.

Link to post
Share on other sites
Guest
This topic is now closed to further replies.
×
×
  • Create New...