Jump to content

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


rbray89

Recommended Posts

Hello guys, so i have agressive version of it , but agressive version does not apply to rla stocklike or near future mods, or they texures are in such a way i cant notice difference between normal and agressive compresion, i think they dont get compressed enough or at all, i see texture drops in stock and KW stocklike and b9 parts. i see nothing in these parts, i also dont get IVA texture reduction at all, no efect on that, but i am using rasterprop and do a lot of IVA so i am not going to complain about that, funny thing is, previously agressive compressed IVA as well, when i made an edit, ATM jumped back to basics, it quit being agressive on anything, same goes for the RLA and near future packs, if i make a change , it turns to basic, and i endup re installing agressive, maybe im doing something wrong, anyone has encountered similar problems?

Link to comment
Share on other sites

Hello guys, so i have agressive version of it , but agressive version does not apply to rla stocklike or near future mods, or they texures are in such a way i cant notice difference between normal and agressive compresion, i think they dont get compressed enough or at all, i see texture drops in stock and KW stocklike and b9 parts. i see nothing in these parts, i also dont get IVA texture reduction at all, no efect on that, but i am using rasterprop and do a lot of IVA so i am not going to complain about that, funny thing is, previously agressive compressed IVA as well, when i made an edit, ATM jumped back to basics, it quit being agressive on anything, same goes for the RLA and near future packs, if i make a change , it turns to basic, and i endup re installing agressive, maybe im doing something wrong, anyone has encountered similar problems?

I don't know about most of what you wrote, but here: https://dl.dropboxusercontent.com/u/59567837/NearFuture.cfg is a config I use for texture compression of NearFuture stuff with ATM. Add it to your GameData/BoulderCo/ActiveTextureManagerConfigs or whatever the folder is called and it should (maybe?) work. No guarantees!

Link to comment
Share on other sites

With KSP being 64bit, will this pack still be needed? I know it might still be needed for some users with less RAM, but with 16Gb, should I still use this? I'm asking because I'm waiting for most mods to update before "officially" upgrade.

Link to comment
Share on other sites

It will be needed to fix KSP texture loader issues.

Care to elaborate? I would prefer to run without this mod (no offense to the creator!) if possible as I would prefer to keep my textures looking as high quality as I can.

Link to comment
Share on other sites

Care to elaborate? I would prefer to run without this mod (no offense to the creator!) if possible as I would prefer to keep my textures looking as high quality as I can.

Haha, I'D even prefer if people were able to run without this mod :)

Link to comment
Share on other sites

AFAIK .24 didn't do anything to the PNG mipmap issue or the TGA-uncompressed issue. Your experience differ?

(Also, I *think* that textures by default are made unreadable, which would screw with EVE unless ATM made the clouds etcs readable)

Link to comment
Share on other sites

AFAIK .24 didn't do anything to the PNG mipmap issue or the TGA-uncompressed issue. Your experience differ?

(Also, I *think* that textures by default are made unreadable, which would screw with EVE unless ATM made the clouds etcs readable)

The PNG and TGA issues may still be present, but only normal maps are made un-readable.

Link to comment
Share on other sites

I guess my point is i'd prefer to NOT have mipmaps if possible. I have more than enough system and vram to handle huge jass textures.

mipmaps take up more memory (~33% more), and make the textures look much better...

Link to comment
Share on other sites

mipmaps take up more memory (~33% more), and make the textures look much better...

Um I don't want to argu with you since you made this mod, but the purpose of mipmaps is to provide additional lower resolution versions of a texture for performance reasons. So that as an object gets garter away and smaller on scree, it can display a lower resolution, less memory cost texture and in theory still look just as good.

It isn't going to make the textures look any better. At best when working perfectly, it makes them look "just as good". I'd just prefer to always use the full resolution when possible and not bother with mipmapped versions and I have plenty of memory for the full versions.

Link to comment
Share on other sites

Um I don't want to argu with you since you made this mod, but the purpose of mipmaps is to provide additional lower resolution versions of a texture for performance reasons. So that as an object gets garter away and smaller on scree, it can display a lower resolution, less memory cost texture and in theory still look just as good.

This is incorrect. Mipmaps allow for more accurate display of a texture map when scaled down, reducing aliasing from fast/cheap realtime scaling of the full-sized texture. They are loaded into memory along with the full-scale texture and so result in an increase in video memory usage.

Edited by jrandom
Link to comment
Share on other sites

This is incorrect. Mipmaps allow for more accurate display of a texture map when scaled down, reducing aliasing from fast/cheap regular texture scaling.

Ok lets just say we are both right. Yes, the aliasing issue is possibly dealt with better by mipmapped versions, though i'd argue that the scaling in GPUs is so good now that that particular benefit is not really an issue anymore.

The MAIN reason for MipMaps, originally when they started back in the day, was to reduce overhead. Back when computers struggled to display even the crappiest graphics, you had to optimize things everywhere you could and one way to do that was to use lower resolution textures on objects that were smaller on screen IE as they got farther away, switching to a lower resolution to save memory.

So let's just agree to disagree and say we're both right? :P

Link to comment
Share on other sites

Agathorn: yeah, AFAIK mipmaps were always loaded into memory; this isn't LOD.

You do however get a performance boost (or did then) because you're sampling from a smaller texture, I think, for your filtering, when you're not on mip0.

Link to comment
Share on other sites

Ok lets just say we are both right. Yes, the aliasing issue is possibly dealt with better by mipmapped versions, though i'd argue that the scaling in GPUs is so good now that that particular benefit is not really an issue anymore.

The MAIN reason for MipMaps, originally when they started back in the day, was to reduce overhead. Back when computers struggled to display even the crappiest graphics, you had to optimize things everywhere you could and one way to do that was to use lower resolution textures on objects that were smaller on screen IE as they got farther away, switching to a lower resolution to save memory.

So let's just agree to disagree and say we're both right? :P

The downsampling is still VERY expensive compared to mip-maps which work perfectly anyways. I wouldn't disable them.

Link to comment
Share on other sites

Ok so yes I did some more reading and your right that the filtering is still far better in mipmaps than on GPUs. I thought they had gotten better than they really had.

BUT I still want to address the memory issue because there is a misunderstanding here. YES they are loading in RAM and take up MORE space. But when you are doing the actual draw calls, with the lower resolution Mips you are in fact saving texture bandwidth. That is what I am talking about. They ARE a performance improvement in actual rendering, even though they use more memory to store the mips.

But yeah, I guess the filtering tech in GPUs hasn't come as far along as I thought they had, so mips are still better overall.

The big problem I have with mips though is if not done right they really can create really bad muddy textures, when a too low resolution mip is loaded for a model.

Link to comment
Share on other sites

The big problem I have with mips though is if not done right they really can create really bad muddy textures, when a too low resolution mip is loaded for a model.

There was some article I read years ago on how Photoshop does downscaling and it covered the "average color" muddy problem. Turns out, downsampling images is way more complex to do correctly than you'd originally think. Most games just completely ignore the problem.

Link to comment
Share on other sites

Getting this trying to load up 0.24.0 with ATM

ATM is unable to start up and the game crashes due to low memory.

Latest version running on Mac OS X (10.9.3)


AddonLoader: Instantiating addon 'ActiveTextureManagement' from assembly 'ActiveTextureManagement'
ActiveTextureManagement: Settings:
ActiveTextureManagement: mipmaps: True
ActiveTextureManagement: compress: True
ActiveTextureManagement: scale: 2
ActiveTextureManagement: max_size: 0
ActiveTextureManagement: mipmaps_normals: False
ActiveTextureManagement: compress_normals: False
ActiveTextureManagement: scale_normals: 2
ActiveTextureManagement: max_size_normals: 256
ActiveTextureManagement: filter_mode: Bilinear
ActiveTextureManagement: make_not_readable: True
ActiveTextureManagement: normal List:
NullReferenceException: Object reference not set to an instance of an object
at ActiveTextureManagement.CacheController.RebuildCache (ActiveTextureManagement.TexInfo Texture, Boolean compress, Boolean mipmaps, Boolean makeNotReadable) [0x00000] in <filename unknown>:0
at ActiveTextureManagement.CacheController.FetchCacheTexture (ActiveTextureManagement.TexInfo Texture, Boolean compress, Boolean mipmaps, Boolean makeNotReadable) [0x00000] in <filename unknown>:0
at ActiveTextureManagement.ActiveTextureManagement.UpdateTexture (ActiveTextureManagement.TexInfo texture) [0x00000] in <filename unknown>:0
at ActiveTextureManagement.ActiveTextureManagement.LoadTextures () [0x00000] in <filename unknown>:0
at ActiveTextureManagement.ActiveTextureManagement.Awake () [0x00000] in <filename unknown>:0
UnityEngine.GameObject:Internal_AddComponentWithType(Type)
UnityEngine.GameObject:AddComponent(Type)
AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup)
AddonLoader:StartAddons(Startup)
:MoveNext()

(Filename: Line: -1)

Edit: (update)

I thought ATM was not actually loading when it got that error but it apparently does. It's trying to build the cache and at some point it's crashing when it's processing Squad's folder. I have to run it again to be sure but it looks like it's building a cache for Squad and at some point that cache is being deleted except for the Agencies folder and everything from that folder except C7AerospaceDivision.*cache looks like I'm hallucinating and the Squad folder definitely isn't being processed because it's hanging when it tries to get past the C7 texture in the Agencies folder....

player.log is spammed with 'Texture '' has no data' 328362 times. And I'm not seeing memory error on these subsequent runs, just KSP stops responding..... I'm no longer actually sure what's happening. Running it again so I can watch what happens in the Squad folder. I did a search btw for the 'no data' message and only really see it mentioned in the Alternate Texture Loader thread where it's mentioned that that message has to do with mods that need to access texture data...

Edit #2: Hanging on the small lander can.

Edited by Starwaster
Link to comment
Share on other sites

Yep.

This is why I was poking rbray to have ATM use bicubic resampling. :)

I found a really nifty "magic kernel" algorithm re-sampler that works surprisingly well. For power of 2 anyways :)

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...