Search the Community

I am am making class-specific suits with the class icons on them, is there a way to change the glow texture. I have done everything to make a normal suit including the config and regular texture, but in is there a way to specify a csutom glow texture in the config. I have also extracted the default glow texture from the files.

I am am making class-specific suits with the class icons on them, is there a way to change the glow texture. I have done everything to make a normal suit including the config and regular texture, but in is there a way to specify a csutom glow texture in the config. I have also extracted the default glow texture from the files.

Hi, Perhaps an easy one for you gurus out there. Mods: Eve, scatterer, kopernicus, parallax, planetchine, waterfall. Recently, my planet textures (and aset navball mfd to a degree) become blury. Rover on mun, blurry textures when moving turning. ASET interior navball mfd slightly if rotating in mun orbit, and if looking at mun thru window. Driving me crazy because last week it seemed ok, I dont remember what mod I may have updated last. I just know I had been rover driving on mun earlier last month and hadn't had the issue. I listed some of the mods that impact this, not all mods installed, any thoughts? I even reset setting in graphics and restarted KSP itself, same. It's not a dealbreaker here, just wanting to figure it out and learn in the process, even for someone like me who has played a long time. Most likely if we cant figure it, I figure a mod will update and it will be gone. You all know how it is .... Marc (RW-One)_

I want to have some lights in my cabin, how can i do this? i heard its about texturing, also i use blender and i hope its possible without unity

Hello, I'm texturing some big custom assets and I want them to look similar to the stock space center buildings. Do you know where I can find their interior and exterior textures? Or are they hardcoded? Any help would be appreciated. Thanks!

Planet Texturing Guide Repository This thread will aim to deliver a range of guides and tutorials to cater for those who wish to create planetary textures using a variety of methods, software and mod plugins. Please feel free to contribute any material you think would be suitable to list within this archive and I will endeavor to keep it up to date. ------------------------------------------------------------------------------------ Celestial Body Creation Theory World Generation - by Tyge Sjöstrand Atmosphere Calculators - by OhioBob ------------------------------------------------------------------------------------ Map Making Making Maps Using Photoshop (... and a little Wilbur) - by Jeremy Elford: Turning your hand drawn sketch into a detailed alpha map A Basic Alpha Map Aged, Parchment with a creation method for mountain ranges, trees and trails. One of many options to colour your map 4 ways to give your map a relief using height maps - using Wilbur for one of them. The Genesis of Israh: A Tutorial (Amazing tutorial using Photoshop, Wilbur & Fractal Terrains) - hosted on Wayback Machine Eriond: A Tutorial for GIMP & Wilbur - by Arsheesh Creating Mountains and Other Terrains in Photoshop - by Pasis Realistic Mountains with Photoshop and Wilbur - by Miguel Bartelsman Mountain Techniques using Wilbur and GIMP - by Torq Simply Making Mountains in GIMP & Wilbur - by Ludgarthewarwolf Making Mountains for the Artistically Challenged - by Unknown Painting Heightmaps for Satellite Style Maps - by Theleast Quick Guide for Bumpmaps in Photoshop (Combining Colour and Normals for presentations) - by Pasis Saderan (Creating Land/Ocean maps in Photoshop) - by Tear Realistic Coastlines in Photoshop/GIMP - by Old Guy Gaming Terrain in Photoshop, Layer by Layer- by Daniel Huffman Procedural Planet Textures using Adobe After Effects - by Poodmund How to Make Prodedural Gas Giant Textures using Gaseous Giganticus on Windows 10 - by Poodmund How To Make Gas Giant Textures for Kerbal Space Program Mods - by GregroxMun Gas Giant Texturing Tutorial - by Galileo How to Horizontally Wrap/Create Horizontally Tile-able Textures - by Poodmund Removing Polar Pinching/Distortion from your Planet Map textures - by Poodmund ------------------------------------------------------------------------------------ Software Tutorials Wilbur: Filling basins and incise flow to make eroded terrain Wilbur: Using the tessellation tool Wilbur: Rivers Wilbur: Going from a sea mask to a terrain Wilbur: Rivers and lakes Wilbur: Islands Wilbur: How to generate realistic(ish) terrain below Sea Level Fractal Terrains Tutorials - by Old Guy Gaming ------------------------------------------------------------------------------------ KSP Plugin Tutorials Setting Up EVE Cube Maps - by Poodmund Axially Tilted EVE Textures (Cyclones/Auroras) - by Poodmund PQS Mod:VoronoiCraters Guide - by OhioBob ------------------------------------------------------------------------------------ Software Links NASA's GISS: G.Projector - Global Map Projector Wilbur - Free, extremely powerful noise based terrain generation Fractal Terrains - Noise based terrain generation and colouring, based on Wilbur, License required Libnoise Designer - Procedural Noise Generation tool using Libnoise library. Executable file located in \Bin\LibnoiseDesigner.exe GIMP - Free image manipulation software Paint.net - Free image manipulation software ------------------------------------------------------------------------------------ Please contribute to the above and I will list it in an appropriate section if suitable.

Diverse Kerbal Heads Diversify your Kerbals with unique faces and hairstyles! Original work by @Sylith, @shaw, @IOI-655362, and @Cosmic_Farmer. v1.1.1 Reconverted male head png textures into dds for better results. Moved pre-1.0 female kerbal heads into a zip file to prevent textures loading into ram. Dependencies Texture Replacer Replaced Downloads SpaceDock License CC BY 4.0 Looking for Diverse Kerbal Heads 1.0 for Texture Replacer 2.4.13? Find it here on Curse! Thank you to all the creators who came before.

hi everyone, i try to install city lights with SVE for almost a week now and tried many different configs\textures but all the time the final result is a flickery mess i can't stand. i am not considering myself a modder and i'm probably lacking some knowledge so if anyone can shed me some light on what should i do to make it work properly i'd be hella happy;) also i think it's important to mention that i managed to get it to work a couple of times and even launch the game multiple times without this problem but the next day it's all the same. i am losing my sanity here

cancled

Discontinued, [snip] Humanstuff content of my creation is now a "AGPLv3" project Please report any use of any content licensed as such in other sources to me directly.

Quicktex Available on Github License: LGPL Quicktex is a python library and command line tool for encoding and decoding DDS files. It is based on the RGBCX encoder, which is currently one of the highest quality S3TC encoders available. Quicktex has a python front end, but the encoding and decoding is all done in C++ for speed comparable to the original library. While it is not only useful for KSP, KSP is what I initially made it for, so I think it can go here for support and visibility. It should have higher quality than NVTT or DDS4KSP, while still being reasonably fast, as well as having a (in development, unstable) python API for custom scripting and tricky image types like light cookies. Installation If you are on macOS, you need to first install openMP from homebrew to enable multithreading, since it is not included in the default Apple Clang install: brew install libomp To install, just install from PyPI using pip (the package manager built into python) pip install quicktex and setuptools will take care of any python dependencies for you. The package also makes tests, stub generation, and docs available. To install the required dependencies for them, install with options like so (Docs are still a work in progress): pip install quicktex[tests,stubs,docs] Quicktex will be available on Pypi once it is out of alpha. Usage Usage: quicktex [OPTIONS] COMMAND [ARGS]... Encode and Decode various image formats Options: --version Show the version and exit. --help Show this message and exit. Commands: decode Decode DDS files to images. encode Encode images to DDS files of the given format. To decode DDS files to images, use the decode subdommand, along with a glob or a list of files to decode. To encode images to DDS files, use the encode subcommand, plus an additional subcommand for the format. For example, quicktex encode bc1 bun.png will encode bun.png in the current directory to a bc1/DXT1 dds file next to it. For KSP textures I recommend quicktex encode auto -r [filenames] encode and decode both accept several common parameters: -f, --flip / -F, --no-flip: Vertically flip image before/after converting. [default: True] -r, --remove: Remove input images after converting. -s, --suffix TEXT: Suffix to append to output filename(s). Ignored if output is a single file. -o, --output: Output file or directory. If outputting to a file, input filenames must be only a single item. By default, files are converted in place.

Here are some screenshots for comparison: I am using KSP version 1.3.1 I'm not able to upload images here, So please refer this link: https://imgur.com/a/nQ0FJ2T, Not only those planets but moons as well, textures in the map mode looks fine but when in game mode it looks pixelated blurred and not clear. This problem persists in both the texture packs 4k and 2k. I tried with 4k first, but same problem, then I replaced it with 2k thinking my laptop is not supporting 4k, again same problem. The hardware is compatible. So what is the issue? Also before installing all the other mods unrelated to Astronomer's visual pack I tested it once but, same problem. Please tell me how to fix it? EDIT: Kerbin looks just fine both in Map and game modes, Problem is with only other planets. AND I used CKAN to install mods.

I have a texture bug after installing scatterer on 1.8.1. U have to zoom in or be very close to the ground for any texture to appear (on all planets). A link with a screenshoot: https://imgur.com/a/kIn58Ey

So, I've been having a problem with some of the textures in KSC Extended (and it's dependencies I suppose). Namely, they've gone black. I've installed the latest versions of the listed dependencies on the 1.8.1 version of KSP with both DLC expansions. I'm unable to pin down the cause and I am also running my KSP in OpenGL, if that may be the problem. If someone can find a solution, that would be well appreciated!

HumanStuff -Add-On Develpoment Thread MOST CURRENT UPDATE: We have a HumanStuff Wiki NOW ! MASSIVE changes to mods file structure. I did not realize how "involved" I would become in making sure I got the added realism "just right", in 1 day the mod had tripled (3x) in size from 900Mb to 2.7Gb. But I got a 6000x6000px (6K) Skybox thats "cubic correct to the plane of the solar elliptic" from @Galenmacil's work, very bright method, I think I can use this method to create a 8K and 16K RSS correct GalaxyTex (skybox) and 1K (1024x1024) EnvMaps (I already made the 512x512 EnvMaps & 4096x4096 GalaxyTex, also correct for RSS) I quot: PS: NOPE! Tested these "older" files, they are in someway not working out in my compression programs as "nice looking". Space Engine captures of smaller size (4K) are far nicer when compressed to DXT5 or BC7, even as DXT1. ^Can anyone assist with this ^ IS THIS STILL TRUE? About GaxaxyTex & EnvMaps? Same "root" image can be used on both?: _________________________________________________________________________________________________________________________________ A (Slightly More) Realistic Spacesuits, Heads & Staff. For KSP v1.5+ NEEDS (as a "Dependency") TextureReplacer Intended & Suggested For The Realism Overhaul, RealSolarSystem, & RP-1 Realistic Progression One Mod Families, Will work with just TextureReplacer (^Current "Poorly Made Hack Job Title Image" For HumanStuff^) Forgive place holder post(s), trying to organize a lot, for me, my very 1st mod/github thing ever ________________________________________________ Plans, Progress & Issues: *Complete the Do it Yourself "Easy Head & Suit Builder" Layered Components Workshop (LCW, for short)* A set of helper PNG/DDS files to assist users in learning to make heads and faces, or all more custom options to users that may be unable to complete the process personally (aka they are limited to pre-made heads and suits) GENE KERMIN <- I am lost to why he works in 1 scene but not others....and "albino" why? Others dont have this issue unless they use gene's head (some SPH/VAB ground crew) Low Resolution (1/2 the current image sized listed), Standard Resolution (Current image sizes as listed), High Resolution (twice the current sizes listed) & "All Resolutions" (All in 1) packs JUST READ THIS: must Env folder (reflections) images be PNG ONLY to work? NOT DDS AT ALL?? ________________________________________________ Current Project I'm Working On For This Mod: @Aazard (thats me) has been starting at the start.... mostly making sure i'm not breaking the file structure or "blowing up" it working right. Also that I'm following "all the rules" to the letter (next to the really serious letter, I'm an easy going man), in regards to the EULA, TOS and licence terms of any inclusions I'm working on 1950's suits ALOT. Early USA/CCCP high altitude flight suits and Mercury IEVA suits are "mostly done" GENE KERMIN <- I am lost to why he works in 1 scene but not others....and "albino" why? Others dont have this issue unless they use gene's head (some SPH/VAB ground crew) Also I am breaking down all the dds files, "4096/4K files" looking for "8192/8K files", attempting to optimize them: Env: 256x256 bit depth 24, optimization pass 1= fail (I inverted in game view when making png into dds, noobism).. pass 2 = I "deepened blacks" BUT see no naked eye or file attributes (size) difference... so= done? Looking into 512x512 options... JUST READ THIS: must Env folder (reflections) images be PNG ONLY to work? NOT DDS AT ALL?? Trying @Galenmacil's RSS Correct Ultra High Resolution Unique Galaxy Background CubeMap @6000x6000 Heads: 1024x1024 bit depth 32, file name fixes = done, location for TR fixes = done, images "cleaned" = huge difference in "color" quality! make into compontents = WIP... Looking into 2048x2048 options Suits: 4096x4096 bit depth 32, pre ksp v1.5 suits cant be reworked only remade...so = done, make into compontents = WIP.. Looking into 8192x8192 options GalaxyTex: 4096x4096 bit depth 32, pass 2 = I "deepened blacks" BUT see no naked eye or file attributes (size) difference... so= done? Looking into 8192x8192 options ________________________________________________ Current Project Community Members Are Working On For This Mod: @Chubby_Hamster was reworking the SK-1 IEVA and A7L "Inner layer" IVA suits last I heard from him, he is much better than I am with this and his work is very high quality, IMHO. There is no "confirmation" of final submission currently, forgive if this announcement is in error ________________________________________________ Current Community Suggestions & Authour Requests: Please feel free to make suggestions for anything! I'm looking for higher resolution (native/original not "upscaled") png or dds images for all base "template building" and for the high resolution pack, and also to "downscale" to the lower resoloution packs (mostly to have everything the same & PREVENT quality loss to highest resolutions I desire: env 512x512, heads 2048x2048, skybox/suits 8192x8192, all with bit depth of 32 hopefully Cfg files... these are not new to me i've edited many and the mods I use often require (or used too) "fix by users"... but writing my own "with a goal" is NEW. anyone REALLY understand MM and TR cfgs in general that I could ask direct questions too (that has the willingness to explain/help me for like 15 minutes) Current Poll & Featured Art/Screenshots Of The Week: *This Weeks Deadline: 09/18/2020 at 09:01 PM EST (UTC -5) Last Poll Results: There was no "last poll", below is the 1st Latest Poll: What Famous Face From History Do You Prefer To be The 1ST Added to Pack in "Famous Faces"? (All 5 will be added plus more over time*) *With-in the limits of game, Texture Replacer and my skills (not in that order...) Next Poll Thoughts/Options: There are no "Next poll" ideas or suggestions, yet ________________________________________________ I will make reposts of info from main thread them spoil out original post, mostly to "clean up" & to save "page length" on main release thread. Preview of my mad art skills: Ummm how do I reverve 2nd post slot? lol

I need some outside the box thinking Have tried almost everything and I do mean everything 8, 9 or 10 have not had any textures works fine otherwise and I've installed no mods. please help please please please help!!! https://imgur.com/a/A5hJeHh https://www.dropbox.com/sh/2lkfnpltzuysexv/AABtDkX84gedBCdbaUpBsrmHa?dl=0 [config] build id = 02917 2020.06.29 at 15:18:37 PDT Branch: master language = en-us distribution name = Steam

Hello there, I was wondering if it would be possible to implement cubemap support for planets into an update at some point. I really would love to see this, since the DDS format (a texture format used by most if not all unity games) has a max resolution of just 16k. This works fine if your planets are kerbin sized, but when you have bigger planets it can look somewhat stretched. With cubemaps in theory you could have textures up to 64k in resolution in addition to having no stretching at the poles. this would allow for much greater quality and clarity in the textures of larger planets. Thanks so much for your time. Here's an example of what I mean. For anyone who may not know, cubemaps allow for this kind of clarity. but currently this is done by a mod called RVE64K for RSS using a workaround, so it doesn't load properly when not in orbit or in the map view.

2.0 coming soon 1.4 Media 2.0 License

Hello, I am looking for help from anyone with the necessary knowledge of software to help me make cubemaps out of files equal to or in excess of 65,536 x 32,768 resolution. I would like to find a program that would allow me to distort the geometry of an equirectangular scan (2:1 resolution similar to what stock ksp uses) into a cubemap. I have found software that can do the later, but not at the resolutions present. Currently my plan is to export textures as separate color channels as seen above. This means that instead of 5-6GB exports I can get away with 1-2GB ones. From here I would like to convert their geometry, then recombine them and export them as DDS cube-faces. If anyone knows of any software capable of handling this task, please let me know. I believe my pc can handle it, but my knowledge is simply too limited with these sorts of things. But that is why I am reaching out to you people, as I expect there is a lot I do not know yet. Any help is greatly appreciated, -Luci

Hi guys, I've set my custom EVA visor texture, but I also want it to be applied when I'm in IVA mode. How can I do it? Game version - 1.8.1

(nvm i'm big dumb)

TU / SSTU Color Presets The following config file is intended to replace the stock SSTU list of colors for the recoloring option that can be used on any SSTU part to give it custom colors. This is a list of colors I use in my game-play and should give a large variety of gloss, metallic and matte color options. You can always add your own colors ofcourse by editting the cfg file for colors. Notice I mention colors a lot? Colors... SSTU Color Presets Spacedock [v1.11 11-04-2021] Works for SSTU/TU release for KSP 1.9.1 running on KSP 1.11.x To install: Unzip the archive and move the contents in the /GameData folder to your ../KSP/GameData directory. * note: upon installation this may effect some of the stock colors. REQUIREMENTS You need the following items installed to get these colors to look like they should. - SSTU 0.10.46.158 or later download link - KSP 1.6.1 or later, running in 64-bit mode and forced to DirectX11 TIPS TIP: Change the length of the recoloring GUI in the in-game Textures Unlimited settings menu. TIP: Specular and Metallic sliders It may sometimes not be evident which slider to use for what effect when changing existing, or making you own colors: - Specular: The amount of shiny. Setting to 0 will make the color matte, setting to 255 will make it a mirror gloss. - Metallic: This is basically a contrast slider, raising or lowring contrast from reflections. Set to 0 and it will be flat, set to 255 and you will get light to dark bands that exagerate the lighting. Specular 0 and Metallic 0 will give a matt paint effect, while specular 255 and metallic 255 will give a super metallic mirror effect. Warning: The higher the specular and metallic values, the darker it will look in space as there is no light source to reflect like with the omni-directional lighting in the VAB. Keep this in mind when using colors that look like mirrors in the VAB. Enjoy!

My kerbals don't wear their helmets in IVA, and I wonder if there is a way to fix that.

I'm playing KSP 2 years already and I always thought that only stock KSP can load faster then 5 minutes. My modpack was loading 15 minutes until yesterday. Now it loads in 5 minutes. The same modpack. What changed? I shrinked almost all addon textures in half! I had some issues and need to take a look at addon resourses and I was shocked. People, are you serious? 2k textures??? I mean, it's not Star Sitizen! 2k textures even for a tiny parts!!! That's beyond good and evil. I'm in 3D modelling for games since 2001 and I'm always asking myself "how large will be an object on the screen in the game?" And playing KSP, 90% of time my screen looks like this: Now think about this: every part has a texture of 2048x2048 pixels. Every ~40 pixels wide part has 4000000 pixels texure!!! What a RAM waste. Thus I spent 2 hours shrinking textures and I don't regret this. I got tripple performance gain with no visual difference. So thi is my public appeal to all mod developers. I beg you, review all your textures or release optional low-res packs. 2048 only for huge >5m parts,1024 is more then enough for 2,5-5m parts, 512 for smaller parts and 256 for various bells and whistles. Remember: it's Kerbal Space Program, it's vulnerable to RAM wasting, so pay attention to it. P.S. Near Future Tech mods don't need any optimization. Respect, guys!

Disclaimer: I am not an expert on this, the following is just what I have discovered. Some of this information is deduced based on empirical observation of KSP / Unity behavior. There's only fragmented info out there re: how to set up UI textures. Hopefully by organizing this information together will help put an end to blurry fuzzy UI woes and nasty hacky workarounds. Plugin authors: This will hopefully explain why your buttons/icons/etc are a horrible mess and what you should do to avoid it. Part modders: This does not really affect textures you use in models, but may be informative. (Side note: if you aren't already using DDS with mipmaps, you should be doing so.) Players: This is probably too technical. If you want to fix blurry UI in mods that you are using, see instructions here. So I finally needed to make a mod with toolbar button and ran into the issue where the icon gets all blurry when graphics settings are at less than full resolution textures. Within the modding community I found that: - some modders not aware or haven't address the issue (e.g. low priority, haven't figured out what to do) - blame placed on Unity and it's texture compression (loosely true but not strictly correct) - some workarounds involving DIY reading texture directly from file, ignoring the version in GameDatabase --- file i/o overhead, yucks - some workarounds using textures that are larger than they need to be The crux of the problem isn't actually compression per se, it's mipmaps. If you don't know what they are, you might want to google and read up more, but the short explanation is: mipmaps are just a bunch of smaller copies of the texture which can be used on-the-fly depending on the size required, rather than having to do expensive calculations to get a scaled version from the original at runtime. This is great for model textures, so if you're looking at a capsule in game at close range it would be textured using a high res (or fullres) version of the texture but if it is zoomed out and far away then a lower res mipmap can be used. (See explanation by HebaruSan below.) Depending on what format texture files you're using and how they get loaded, they may already contain mipmaps in the file, or mipmaps may be generated for them during loading. And the problem is, if you have small textures for UI purposes e.g. icons, buttons, you've probably already made it at appropriate size and want it to be used at crisp full res all the time. You do not want any of that fancy mipmap stuff. When a texture has mipmaps, and the Texture Resolution option KSP's graphics settings are set to anything less than full resolution, then the following happens: - At half res, only mipmap level 1 (halved width and height) and smaller is uploaded to GPU <-- "factory default" - At quarter res, only mipmap level 2 onwards is uploaded - At eighth res, only level 3 onwards is available This means that your appropriately-sized, original full res version of the texture (mipmap level 0) simply gets thrown away, so when your UI element is displayed it is forced to use a too-small version of the texture and scale it up. What KSP / Unity does when loading textures Textures are loaded from file into Unity Texture2D object. All of the textures are kept in the GameDatabase along with some metadata in the form of GameDatabase.TextureInfo object. TextureInfo attributes: name: This is the "url" used to lookup a texture when you call GameDatabase.Instance.GetTexture() basically the path of the file relative to GameData folder, minus file extension file: Internal UrlDir.UrlFile format for storing path information texture: The Texture2D object with the texture in it isNormal: whether the texture is a normal map. Note that this can change at runtime. So if you have a texture that isn't a normal map, and then call GetTexture() with asNormalMap true it will (try to) convert the existing texture to normal map, and isNormal flag will be changed to reflect this isReadable: a Texture2D can be set to be "no longer readable" which according to Unity documentation means "memory will be freed after uploading to GPU" and texture cannot be manipulated (e.g. edit the pixels) from CPU side. this flag is supposed to reflect that. isCompressed: whether the texture has been compressed during the loading process. Unity documentation: "Compressed textures use less graphics memory and are faster to render. After compression, texture will be in DXT1 format if the original texture had no alpha channel, and in DXT5 format if it had alpha channel." This flag may be incorrect, it appears to be set as long as there was an attempt to compress the texture with Texture2D.Compress(). But that process can fail, and is usually seen in KSP.log when it complains such as "Texture resolution is not valid for compression: <filename> - consider changing the image's width and height to enable compression" This gives us some insights into the texture loading process. What KSP does when loading each texture depends on the file format, but the general steps include: - read the texture data from file - convert image format (if needed) - (optional) try to compress to DXT - (optional) generate mipmaps - upload to GPU -- behavior depends on Texture Resolution setting, more on this later - (optional) make texture no longer readable (discard from RAM) We can learn more about how different texture file types are handled by observing what happens to them. Below is a partial list of textures info dumped from a stock 1.7.0 install just after GameDatabase finished loading in LOADING scene. I've trimmed it down from the full set. First three letters NRC reflect the three boolean flags. The fourth C shows whether the texture itself is actually DXT format. This is followed by image dimensions, mipmapCount (1 if none) and TextureFormat, then the name of the texture. The source code that dumped this info can be found here, it is part of the unBlur mod. If you install unBlur you can use it replicate the above as well as investigate what KSP is doing to your textures. It provides access to its functionality via a console command in the Alt+F12 debug console so you can inspect individual texture info, disable mipmaps for textures, and dump the full list of textures from GameDatabase. It is also possible to have unBlur dump the state of textures from GameDatabase immediately after loading, while in the loading screen, by turning on verbose debug mode. For details, consult the unBlur forum thread. How the texture resolution setting affects texture loading The texture resolution option in KSP's graphics settings actually control a Unity setting called QualitySettings.masterTextureLimit. The setting is stored in settings.cfg as TEXTURE_QUALITY with 0 = full res, 1 = half res, ... 3 = eighth res. As described earlier, masterTextureLimit prevents the n highest resolution mipmap(s) from being uploaded to the GPU. Per Unity docs, "This can be used to decrease video memory requirements on low-end computers." However, if a texture does not have mipmaps, then the full texture must of course be used. Once the texture has been upload to the GPU, that's the copy we have to work with. If the texture resolution setting was at eighth res when starting the game, that's the quality that you are stuck with -- changing the setting at run time does not appear to have any effect -- because only a lower res version is available in the GPU, and in general because the texture was made no longer readable by CPU side after loading, even if you turn the quality back up to full res, the full res texture data is not available anymore without actually reloading from file again. In cases where the texture is still readable and in RAM, plugins can access the full res version of the texture from there. (This is how unBlur fixes blurry png textures.) How various file formats are handled Based on observations from GameDatabase TextureInfo dumps, including both stock and modded. *.dds These files are already in the compressed format preferred internally. Loading them is fast, because the data is loaded as-is and no conversion is needed. Being compressed, they use less graphics memory and are faster to render. - Loaded format: as per file, i.e. DXT1 (no alpha) or DXT5 (with alpha) - already compressed - mipmaps: as per file - not kept readable *.mbm Old KSP propietary format, very few instances left. - Loaded format: DXT - compressed - mipmaps: yes - kept readable *.png Loading them is slow, because they have to be converted from RGBA32 and additional processing is done. They usually get compressed to DXT5 for upload to GPU, but are kept CPU-readable so also consume RAM. - Loaded format: usually DXT5 - will usually be compressed - mipmaps: may be generated <-- blame your blurry UI on this - kept readable Notes Some stock pngs avoid having mipmaps generated (e.g. Squad/Flags/*, Squad/PartList/SimpleIcons/*, Squad/Strategies/Icons/*) but others do (e.g. Squad/Props/IVANavBallNoBase/*) mechanism not well understood, perhaps hardcoded to identify certain directories (*/Flags/* maybe?) but not sure we can rely on this behavior A very small number of new normal maps (_NRM) for redesigned parts are *.png that store in GameDatabase as RGBA32, unreadable, uncompressed (despite isCompressed true), with mipmaps generated. Squad/Tutorials/YPRDiagram fails to compress, which reveals that pngs are loaded as ARGB32 before getting compressed to DXT mipmaps may still be generated even if compression fails, I have positively observed this (38x38 ARGB32 CommNetConstellation/Textures/cnclauncherbutton.png with mipmapCount of 6) *.truecolor Notably used for small (_scaled) versions of agency logos. Explanation here. Actually renamed *.png files, so loading needs to convert format from RGBA32. - Loaded format: ARGB32 - will not be compressed - mipmaps: will not be generated - not kept readable *.jpg Like png, these are comparatively slower to load. They are compressed to DXT1 since they don't have transparency, and kept CPU-readable after loading to GPU - Loaded format: DXT1 - compressed - mipmaps: will be generated - kept readable Why does it behave like that? If you provide a texture in DDS format, it is already in the format that is used by the GPU, so KSP/Unity takes the file as-is and treats it as what you intended -- so you can provide exactly what you want. If you are using a texture for models, you'd include mipmaps, and things would work great (because that's exactly the use-case they were designed for.) If you are using a texture for UI, you wouldn't generate mipmaps when saving the file, and KSP/Unity will just always use it at full-res (exactly as intended) The texture file is already in the correct format, already compressed, and has mipmaps if you want them. KSP/Unity presumes that everything is as you want it to be, and the texture will no longer be modified by code once loaded, and so discards its data from main memory after it has been loaded into graphics memory. For other formats, however, they need to be converted for use. Because the API doesn't provide a mechanism for us to attach any metadata to png/jpg/etc files to indicate to KSP/Unity what our intentions are and what the texture is for, I think the texture loader simply makes the assumption that whatever textures it loads are for models. So, in general, it will generate mipmaps from the full-res image, and after that it will attempt to compress the texture to DXT for better performance. But it keeps the texture's pixel-by-pixel data available in RAM, in case you might want to write some code that accesses/manipulates that. This is actually a reasonable default assumption, after all, most textures are going to be model textures. As for UI textures, pretty much most if not all of the UI in the stock game are built in Unity, prefabbed, and saved into assets, so that takes care of loading UI textures for the stock game. (Mods could do the same thing, but most of the time it's far too much trouble if all we need is some simple UI.) Anyway, this is the behavior in general for formats like png and jpg. It seems like KSP might have some code that handles special cases in the stock game's data like flag textures (Squad/Flags/*) and icons (Squad/PartList/SimpleIcons/*, Squad/Strategies/Icons/*) so that they don't get treated like model textures. Those cases can be hardcoded because they know about it in advance, but for modders I don't recommend we rely on that behavior. *.truecolor files are the special case, which seems to be added to handle agency logos. Agency logos in general are stored as DDS and are displayed in game at various medium-ish sizes, e.g. contracts window. However, for the part-picker in editor when sorted by manufacturer, it needs to be a small icon. Scaling down from the fullsize logo at runtime didn't work well visually, so smaller "*_scaled" version of the logos were specifically made. These were png files, but as above the texture loader would have generated mipmaps for them and cause blurriness. To deal with that, the files were named as *.truecolor instead and the texture loader instructed specifically to treat them differently, i.e don't generate mipmaps. How to proceed from here UI textures in your own mod Including toolbar button icons for stock AppLauncher or blizzy toolbar. If you are currently using *.png for icon/button graphics, the quick hotfix is to simply rename to *.truecolor. Besides not having mipmaps generated, the other benefit is that it will not be kept in RAM after uploading to GPU. The one downside compared to png is that it will no longer be compressed. Also, like png, it is still slower to load. For long term, if you can convert your files to *.dds without mipmaps would be most ideal: fast to load, compressed, not kept in RAM. If you are using the workaround of reading textures directly from file yourself Specifically the workaround offered here. Stop doing this if it is for textures in your own mod that you have control over. Rename/convert them instead, see above. By reading the file yourself and creating another texture, you incur file IO overheads and consume additional resources for the texture that you create, while the copy in GameDatabase continues to occupy both RAM and GPU. And if not implemented properly, you may be leaking memory. If you have to use the workaround because you have no control over the textures, i.e. they are passed to you by other mods. You can use unBlur, call unBlur to tell it to strip mipmaps from the texture in GameDatabase before you fetch and use it. If you are using the workaround of making textures larger than they need to be This workaround costs a disproportionate amount of disk space and loading time, don't use it. The way that this worked is as follows: Suppose you make a 64x64 image when you actually only need 32x32, this will work at half res settings because the 64x64 copy is thrown away but mipmap level 1 at 32x32 is still available. But at eighth res setting, only mipmap level 3 at 8x8 is available so it doesn't fully solve to problem. You would need to make full res at 256x256 in order for eighth res setting to still have a 32x32 copy. If you have programmatically created Texture2Ds in UI for other reasons Here are tips for best performance and results Make sure you use the constructor that lets you specify mimmap false. Use Compress() if possible. Works more consistently if you do this before making unreadable using Apply(). (ref) Once finished making modifications to the pixel data, call Apply(false, true) to upload to GPU and discard from RAM Make sure you dispose of the texture when done with it. For most monobehaviors (i.e. destroyed/recreated when changing scenes) you should do it in OnDestroy even if it is something you "hang on to", otherwise the texture will not be GC'd and you end up making another copy. Other ideas: you can have a singleton monobehavior with DontDestroyOnLoad that is responsible for hanging on to one copy of textures only. Or init once into a static field. UI textures that require mipmapping If you have UI textures that are larger, such as banners or backgrounds that need to be displayed at different sizes, then you might actually want mipmapping. But then, you'll need some way of getting around the texture quality settings causing the n highest-res mipmaps being discarded. If you find yourself in this situation, my suggestion is to use png format so that mipmaps will be automatically generated for you, but the texture is also kept readable in RAM. After the texture has been loaded into GameDatabase, you will need to fetch the texture -- which is missing first few mipmaps on GPU, but still has full-res data preserved in RAM -- and upload to GPU again, forcing it to include all mipmaps this time. This should be achievable by temporarily forcing QualitySettings.masterTextureLimit to 0, calling Apply(false, false) on the texture, and then restoring the masterTextureLimit when done. (unBlur will also provide such functionality in the future.) Non-UI, i.e. model textures You've probably heard this before, but for fastest loading and best performance you should really encode in dds with appropriate mipmap level.