Search the Community

Showing results for tags 'textures'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Announcements
    • The Daily Kerbal
  • Kerbal Space Program 2
    • KSP 2 Discussion
  • General KSP
    • KSP Discussion
    • Suggestions & Development Discussion
    • Challenges & Mission ideas
    • The Spacecraft Exchange
    • KSP Fan Works
  • Gameplay and Technical Support
    • Gameplay Questions and Tutorials
    • Technical Support (PC, unmodded installs)
    • Technical Support (PC, modded installs)
    • Technical Support (PlayStation 4, XBox One)
  • Add-ons
    • Add-on Discussions
    • Add-on Releases
    • Add-on Development
  • Community
    • Welcome Aboard
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
  • Making History Expansion
    • Making History Missions
    • Making History Discussion
    • Making History Support
  • Breaking Ground Expansion
    • Breaking Ground Discussion
    • Breaking Ground Support
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL





Found 55 results

  1. HumanStuff A (Slightly More) Realistic Spacesuits, Heads & Staff. For KSP v1.7.3 & UP (should work KSP v1.5+, see note) NEEDS (as a "Dependency") TextureReplacer Intended & Suggested For The Realism Overhaul, RealSolarSystem, & RP-1 Realistic Progression One Mod Families, Will work with just TextureReplacer Note: Suit files should work: KSP 1.5+, Heads: KSP 0.23.5+ (location depending on TR version). Works with current KSP version supported by TR Reason >> KSP v1.5 "Changes: [.] New suits, EVA and IVA [.]." I will support directly KSP v1.7.3 & up in main release Note #1: KSP v1.4.5 (Making History available oddly under "beta's" on STEAM) , Released 26th July, 2018 is the last version that will run on a 32bit OS. HumanStuff HAS BEEN TESTED TO WORK with following "minimal requirement": KSP v1.3.1 & v1.4.5: Windows 2000* (*Requires BlackWingCat Extended Kernel AND DirectX 9.0C)& Windows XP SP3 32Bit with TextureReplacer v3.2 Tested on: AMD Athlon 64 FX-57 CPU, Radeon HD 2600XT 1GB GPU & 4GB Ram running Windows 2000 with additions listed, all unused textures "PRUNED" (ask me) ** DDS LOADER and Active Texture Management. Removed with no noticeable "ill effects" so ..not needed it seems Please PM me for cfg's & how to Prune readme (no longer required on 64bit) I will also support KSP v1.3.1 for RO, RSS and/or RP1 users (last RP1 for 32bit uses KSP v1.3.1) KSP v1.3.1 IS IT, no requests for earlier versions please! Mod for 1.3.1 & 1.4.5 will have separate zips in folder "soon" HumanStuff Wiki Everyone Should Read (they are short and have pretty pics) 01. FREE Tools, Programs & Info Links Compilation 02. Basics: "Alpha" & Non DDS Image Formats Best Uses 03. Basics: DDS Image Formats Best Uses 11. Making DXT Textures, NVIDIA's tool, in Photoshop, Stand alone version is similar * * This has good DETAILED info BUT details using the Nvidia "photoshop tool" (they have free stand alone also) step by step, #3 above uses the much easier better method that allows "measure twice cut once methodology" CKAN: SUPPORTED & LIVE, SOURCE: GITHUB, MIRROR: SPACEDOCK(Current: v1.0.5.1) This work is licensed under a Creative Commons Attribution 4.0 International License. Version Change Log: ______________________________________________________________________________________ A Kerbal Space Program mod to add more realistic visuals for: Recreations of "Human" face/hair features (All are 1024x1024 16M .dds files) Recreations of real life equipment, flags, patches & logo's (All IRL flags/mission & other patches & any "logo's/symbols" I use are public use and allow "open" use/redistribution) Recreations flight suits, IVA, EIVA, IVA space suites. (All are 4096x4096 16M .dds files), "standard/base" suit's only currently, not vintage or futuristic I will be adding "mostly" American/NASA & Russian/CCCP recreations, "mostly" chronologically in order. Starting with "Pre-existing" & "In service" 1951 equip, Thats RP-1's (Realistic Progression One) Career Start date, moving towards "current" equipment, over time. European Space Agency (ESA) equipment & China National Space Administration (CNSA) equipment are planned inclusions. Once I reach the 1983 and 2003 eras, respectfully Plus "KSC Staff & Ground Crew" with attempts to skin tone diversify. Maybe Add Famous Faces To These Plus to add additional "EASE", "LOW EFFORT" & "SPEED" to making GREAT LOOKING TR VISUALS, on suits/heads, YOURSELF! With the the Do it Yourself "Easy Head & Suit Builder/Layered Components Workshop (or LCW) For use with TextureReplacer, perhaps files will work with other texture replacement mods, But thats still untested. _____________________________________________________________________________________ INSTALL NOTE: DO NOT UNZIP/EXTRACT IN KSP FOLDER! Extract and copy the "gamedata" folder to your KSP install directory (example: "C:\Program Files (x86)\my games\Kerbal Space Program") The "BigPack" is a massive library of optional GalaxyTex * EnvMaps; texture "components" for heads & suits; plus various other additional ______________________________________________________________________________________ Major News, See Add-On Dev Thread For All "WIP" Updates: Created "colorMap & NRM's" for alot, GalaxyTex upto 16K & EvnMaps upto 2K, head and head asset upto 4K Created some original "component layers" Do It Yourself textures for: ALL HAVE TEXT LABELED GUIDE! Kerbal head (male & female, plus NRM's), Visors (plus NRM's) and Parachute canopies (no NRM yet): 512x512 to 4096x4096 Suits: 1024x1024 to 8196x8196 Got EYES! (only 256x256 & 512x512 currently) Got artists Jetpack NRM's & Cargopack NRM's (BUT only 1024x1024 or 1K), to test Updates to master have swelled mod in size over 3x (about 3Gb now) Small issue with "albino" Gene, but only in Mission Control scene, and same issue with ground crew scientists & "signal lights people". THOUGHTS PEOPLE? I NEED EXAMPLES OF "NRM's" (OR PROVIDE ONES YOU MADE) FOR THE PARACHUTE PACKS, EVA JETPACKS, & CARGO BACKPACKS I"D BE GRATEFUL. Currently a WORK IN PROGRESS! I aim for constant improvement. These are "standard" suit, not vintage (.V) or futuristic (.F), so as many people can enjoy them as possible & because neither looks very "realistic" compared to the standard suit. > This is my 1st mod, and 1st GitHub project, if I did something wrong please tell me. Read note below for credit where credit is due < ______________________________________________________________________________________ Gallaries (WIP) OUTRAGEOUSLY LONG GALLERY AND RUN ON "BLAH-BLAH" BY ME, WILL EDIT TO CLEAN-UP! (BIG Spoiler used to hind my craziness) ______________________________________________________________________________________ - SOON: Create "component/part" template files to "build" custom Suits with - Many more to come, have a CCCP/NASA era look alike? Ask, submit and I'll add it. Included Heads in Default Folder for TextureReplacer (also a copy of each in skins folder) Next: - Fix "Gene Kermin" files (If you know how or have suggestions, PLEASE message me!) - Add "Famous Faces", recreations of the faces (best I can) from space exploration history, Maybe "Gene Kranz" & "Wernher von Braun", and of course the NASA HAWK "Bobak Ferdowsi" could be added to KSC ground crew.... - Locate "Linus Kermin" files, see if I can add more skin tone diversity to ground crews in VAB/SPH by substituting in an Asian skin tone in grey hardhat, Black skin tone in yellow hardhats and see if scientist and "marshallers" (air/space craft ground movement guiders with 2 handheld "light wands") share a head file as they have different hair tones (if they do not, i'll add Hispanic skin tone to one) Included Head/Face/Hair, in skins folder for Texture Replacer I will be using the KSP2 head by @Chubby_Hamster to have a neat/trim "ducktailed" and/or "frenchforked" goatee and neat connected moustache NEXT: - Identical male hair & facial hair options, plus "old hair" for all skin tones currently present. - For females faces: 3 faces and hair style options for each skin tone present, attempt 1 "old hair" for each - Have each "head/face" have "old" counterpart - SOON: Create "component/part" template files to "build" custom Faces with ___________________________________________________________________________ SOON: Included Historic Craft Files, for RP1 Only, in Historic folder of HumanStuff - Plus more! ____________________________________________________________ For use with TextureReplacer, perhaps files will work with other texture replacement mods, But thats still untested. SOURCE/DOWNLOAD: GitHub (Current v1.0.5.1) Real Humans by Clifton Marien is licensed under a Creative Commons Attribution 4.0 International License. ^- This is HumanStuff's "Great Grand Daddy" legacy: Original thread/files lost to the monsters that lurk at the edges of the web Credits - Had to spoiler due to length, PLEASE FORGIVE: Anyone may reuse, edit or redistribute these files, as per terms of very forgiving "CC 4 by SA" licence (&its "art" I dont sell or make issues of "ownership" on) .I only want to be credited, as I did for others. ______________________________________________________________________________________ PLEASE MAKE MORE STUFF, ASK AND SUBMIT IT & I'LL TO ADD IT THE TOO MOD CKAN: SUPPORTED & LIVE, SOURCE: GITHUB, MIRROR: SPACEDOCK This work is licensed under a Creative Commons Attribution 4.0 International License. Currently a WORK IN PROGRESS
  2. 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 = 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
  3. Hi, we received a redundant pull request to add another copy of this mod to CKAN. You don't need to do that, everything works fine if you upload new releases to the original mod. This extra copy should probably be deleted:
  4. 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!!! [config] build id = 02917 2020.06.29 at 15:18:37 PDT Branch: master language = en-us distribution name = Steam
  5. 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.
  6. 2.0 coming soon 1.4 Media 2.0 License
  7. 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
  8. 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 World of Gotha 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 - Free image manipulation software ------------------------------------------------------------------------------------ Please contribute to the above and I will list it in an appropriate section if suitable.
  9. 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
  10. 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!
  11. 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.7.0-001 25-05-2019] Works for SSTU release or later. 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 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 as follows: Open the GeneralConfiguration.cfg file in the /000_TexturesUnlimited directory and edit the following line: // specifies the total height of the recoloring GUI recolorGUITotalHeight = 840 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!
  12. My kerbals don't wear their helmets in IVA, and I wonder if there is a way to fix that.
  13. 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!
  14. 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.
  15. Procedural Parts and its supporting texture packs include a number of interesting textures that are unique in color or styling, or are simply different enough from the others that it can be difficult to use them seamlessly on your craft designs. This texture pack attempts to build sets of related textures around the unique ones, or fill in some gaps in the existing sets. Have you ever wished for more dark red textures to go with the default Mu texture? Or how about the set of assorted black & white blocks and stripes, except in navy blue and white, or soyuz green and white instead? Well, here they are. All textures are derived and edited from default Procedural Parts textures or other texture packages with permissive licenses. Credits for original artwork are as follows: Corestar - MainSailor Skylab - MainSailor Vanguard - MainSailor Charcoal - MainSailor Delphi - MainSailor SoyuzGreen - Chestburster GreySide - Chestburster RedstoneStripes - Chestburster TitanStripes - Chestburster PlainWhite - Chestburster Mu - Dante80 CryogenicOrange - blackheart612 StockEnd - Ancient Gammoner This texture pack is compatible with all versions of KSP that are supported by the Procedural Parts mod. Download from SpaceDock Installation: Merge the included GameData folder with the GameData folder in your KSP folder. These textures require Procedural Parts to function. MainSailor and blackheart612 texture packs are recommended. License: Creative Commons -- Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)
  16. So I´ve downloaded this material here: and I tried to apply it to a project I’m making, I am a beginner on blender, and the material is not even close to what it is supposed to look like. at first, everytimei rendered it just showed up brown with no texture on, then i read on a forum to activate UV maping, and so i did, there wasn’t anything there so i clicked the plus button to create one and now it stays like this: I dont know what to dooo ;-; Help!
  17. So, I've been playing ksp for some time and one day most of the textures decided to glitch and stretch out for miles and I wanted to know if this was a fixable problem or common and if it might be my graphics card thats too old to run ksp properly.
  18. Rover 6428

    Kerbal IVA

    Dear Reader, Please could you advise me how or where to change the settings for kerbal helmets. It is just that I want to make them wear their IVA helmets during launch or decent. Kind Regards, Rover 6428
  19. 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.
  20. For example, I set orange-grey textures for 1.8 tanks in in the VAB-list, and I want them to stay that way after reloading the game
  21. Hello, how to create textures like stock ones? Textures that match the style and brightness. Stock textures have some alpha channel or sth in it that makes them less shiny and bright. Is there some way to recreate this?
  22. Hello everyone. Some days ago i reinstalled mods and find out some problem with parts miniatures. Steam consistensy check was failed, one file (26kb) was re-downloaded. It didn't resolved this issue. I performed a clear install, but got the same. Check always fails on this 26kb file, if i launched the game after previous check. Installation to another hdd does not help too. I'm not alone in this situation, one man in steam community replied in my topic about same issue.
  23. I'd like to gauge if there is interest in creating a community curated list of VARIANTTHEMEs, which would serve a function similar to Community Tech Tree, Comm. Resource Pack, Comm. Category Kit. The aims would be to prevent redundancy, avoid name collisions, ensure that different mods play well together, and present an overall consistent, well-organized categorization of modded variant themes to players, to achieve a better user experience. What are variant themes? With 1.4+ KSP has gained texture switching as part of the stock game, and the new VARIANTTHEME config node to go with that. Variant themes serve to group together the part variants of different parts, that have the same design theme (i.e. "look-and-feel"). This makes it convenient and user friendly for players to switch multiple parts at the same time, to achieve a particular look-and-feel for the craft they are building. With one click in the "Variant Themes" tab in advanced mode in the editor, the player can apply a theme to all applicable parts on the craft currently being edited, or to set that theme as the default for applicable parts when picked out from in the part palette -- rather than have to adjust each part one by one. These are variant themes. They can be accessed in advanced mode in the editor. The variant themes that are built-into stock KSP are defined in GameData/Squad/Parts/VariantThemes.cfg As an example: these panel parts from the Making History expansion each have three part variants. The part variants are defined in ModulePartVariants of the respective part's cfg files. Using the part action window in the editor, you can switch a part between its variants, but doing it this way only works for one individual part at a time. But each of the available part variants are also associated with a variant theme -- this is themeName or baseThemeName value in ModulePartVariants in the part cfg. Being associated with variant themes allows you to click on these icons: And it will "apply" the selected theme -- all the parts on the craft that have such a variant will be switched to that variant. It is optional to associate a part variant with a variant theme. But doing so is useful and user friendly when multiple parts have variants of the same "theme" (hence the name). Why should I care? If you reskin existing parts from stock or other mods. e.g. Back In Black You would obviously like to have a VARIANTTHEME that corresponds to the look-and-feel that you are creating in your mod. So, you set that up. Great! But wait, you're not done yet! What about the original look of the parts that you have modified? When you added your version, a "base" part variant was also automatically created for the original version of the part. You could just leave that as-is , but then the player won't have an easy way to revert multiple parts en masse to their original design. Okay, so let's create a VARIANTTHEME for that... what should it be called? Reasonable choices might include: "stock", "default", "original", etc. If different mods use different names/themes for the same purpose, it could result in a clutter of redundant themes in the UI, messy and potentially confusing. We should standardize. Furthermore, due to a technical limitation of Module Manager we cannot use a clever MM patch that will "add the 'default' VARIANTTHEME if it doesn't already exist". So, for multiple mods to be able to use the same "default" VARIANTTHEME for resetting parts to the original version, we need that to be defined in a community standardized config that gets included by the various mods as a dependency. Additionally, from a technical standpoint, how to ensure that your mod plays well with other mods? In particular, what if someone else also makes a reskin mod that touches the same parts? How can we prevent "Back In Black" and "Racy Red" from stomping on one another's MM patches? We should explore and develop best practices for how to do this. Electrocutor's guide is a good starting point. If you make (a) part(s) that have different textures to choose from. e.g. Hawkspeed Airstairs You might have different textures that are designed to fit in with stock parts, or various other mods. What should you name the different variants? For starters, do we say "stockalike", "stock-alike", or "stock-like"? Standardizing on a common set of VARIANTTHEMEs would avoid redundancy and confusion. Even if your mod has just one part -- since you don't have a natural "collection" of multiple parts to group together, it might seem pointless to set up your part config to use themes. But that's not true -- it is useful to be part of a standard set of themes, that groups different parts from different mods together if they offer the same "look" -- it enables easy texture switching by the player. And when it comes to textures for matching with other mods, there are further considerations. Consider my airstair part -- in addition to stockalike option, it comes with an alternate texture that matches the unique look of Firespitter bomber parts. Those parts aren't shipped with any variants, so okay, I go ahead and label my texture "Firespitter". ... but what if a reskin mod comes along and adds a new variant on top of the original Firespitter parts? They can call their new variant whatever they want, but if they file the original Firespitter look under "default", then we have one theme (the "look") split into two different themes (VARIANTTHEME) -- a player would have to pick "default" to reset the Firespitter parts back from the reskinned version, whereas for the airstair it is the "Firespitter" option. Not very intuitive. If you make parts that don't have alternative textures, but come "in a set" -- stockalike, or your own unique design. You might think this is none of your business, but hang on. If other modders create additional textures to reskin your parts, wouldn't you like to have a say over what the original look of your parts should be filed under? For instance, stockalike mods (e.g. Airplane Plus) may prefer to be grouped with other mods' parts under "stockalike" rather than a meaningless, generic "default". Whereas in the case of a mod whose parts have a unique aesthetic (e.g. keptin's original KAX textures) it may be appropriate to specify its own VARIANTTHEME. Although the mod itself doesn't ship with any variants, and thus doesn't initially have any use for the theme, it provides: a) a target theme for other mods to group their "compatible" variants under, and b) if someone else makes a reskin, then the original look can be placed under this theme, along with those from (a). - * - * - * - To kick things off, pinging a few people that this might be relevant or interesting to (based on threads/conversations I've seen elsewhere in the forum) @Electrocutor @XLjedi @Rodger Please discuss, etc etc.
  24. As you can see, the part texture on left column is missing, how to fix it?