[1.10.x, others] Drop-in Replacement Textures v1.10.0.0

[Cydonian Monk]

8 minutes ago, Cheif Operations Director said:

This does make the game more glitchy when selecting things is that possibly because the photo has a ton of graphics. I'm running on a laptop so I do not have a ton of tolerance.

It's possible. That's a 4k skybox texture, so it's probably not the best option for something that's resource limited.

[Poodmund]

@Cydonian Monk, would you possibly consider adding the ability to locate texture files elsewhere within the GameData directory and point them towards DiRT using Module Manager configs (akin to how TRR lets you do so but not TR). This would greatly increase the amount of interoperability/compatibility between mods that use may use DiRT without having to overwrite each other and causing issues down the like, especially in situations like installing through CKAN (as CKAN does not allow interactions between files/textures that already exist at the same location),

I am looking for mods that can support my skyboxes going forward but would like to find one that will support CKAN installations through remote pathing outside of the main plugin's directory as stated above.

[Cydonian Monk]

4 hours ago, Poodmund said:

@Cydonian Monk, would you possibly consider adding the ability to locate texture files elsewhere within the GameData directory and point them towards DiRT using Module Manager configs.

I'll take a look at it this weekend. Answer is probably yes. Doesn't seem like it would be too bad, especially if only soft linked to ModuleManager. (It already loads configs and textures from paths outside of DiRT, so MM integration wouldn't be much more to add.)

Edited September 11, 2018 by Cydonian Monk

[Poodmund]

I don't know how familiar you are with CKAN's behaviour but basically it does not allow interactions to take place with existing files; quite rightly so as it ensures that mods that are installed are not tampered with by other mods that could lead to issues. 

You'll have to excuse the TextureReplacer node name (I'm on mobile an cannot edit it) but I previously suggested, elsewhere, a Module Manager config notation or something similar to allow for this directory pathing if you're looking for somewhere to start from. 

@TextureReplacer
{
    Directories
    {
        Default = GameData/Custom
        EnvMap = GameData/Custom/CustomSubFolder        
    }
}

Allowing for individual textures to be renamed and pointed towards the default texture names could also be very handy to allow for interopability but would be going above and beyond. i.e.

DiRT/default/rockyMoon01.dds = MyCustomMod/default/texture.dds

[Thygrrr]

On 3/27/2018 at 5:30 AM, Cydonian Monk said:

@Gordon Dry

As a test I grabbed the GalaxyTex_NegativeX and very crudely bucket filled the dark bits. The top texture was Red, each mipmap under that I shifted downwards through Blue and into Green. This was the result in the map view:

As you shift the camera, the renderer does pull in the lower mipmaps at the more distant corners, as one would expect. This will presumably still give you the usual performance benefits of using mipmaps, and to be honest I've never noticed the loss in quality of stars on the backdrop. This would likely be very apparent in mods that add telescopes (such as Tarsier).

Mipmaps are not a performance measure, as number of texels sampled (i.e. texture memory reads) will be determined by the filter method and the number of fragments generated. In fact, this simple filtering of textures that get minified causes aliasing, and it's especially bad when you have lots of small details in your texture (think lots of little stars)

Mipmaps are a quite effective method to reduce aliasing (twinkling pixels) when there is minification, and offer the advantage of a pre-computed filter rather than just the crude bilinear filter that most shaders still use (there are some better filters, but even they aren't nearly as good as, say, a proprerly pre-filtered, contrast enhanced, and sharpened Mipmap that you make in Photoshop or Substance Designer).

The disadvantage is that a full set of Mipmaps will increase the runtime memory requirements for a texture by about 50%.

Anisotropic filtering is a type of Mipmapping that uses Mipmaps of different aspect ratios to allow for crisper images when rendering at very oblique angles, e.g. when looking down a runway. For a Skybox, as the viewing angles are practically never oblique,  normal isotropic Mipmaps are best.


To the Author of this Mod:

THANK YOU for simplifying something that really ought to be as fricken simple as dropping in a replacement file.

Edited September 13, 2018 by Thygrrr

[Cydonian Monk]

@Poodmund I just wanted to point out that using ModuleManager replacements for the DiRT Texture loading path already works with the version of DiRT that's released. (Unless I'm misunderstanding what you're asking for.) If you take a configuration such as the following:

@DiRT_Config
{
	%TextureFolder = CyMonk/Textures/
}

... it will successfully load textures for DiRT from the CyMonk/Textures/ folder (or whatever you enter there) instead of the main DiRT folder. The above worked when I just tested it.

Also, FWIW, if not using ModuleManager, you can use the same type of config file without the MM markup (so, no @ or %) to load paths from a non-standard folder.

If that's not what you're asking for, please clarify.

 

As for your other request:

On 9/11/2018 at 2:31 AM, Poodmund said:

Allowing for individual textures to be renamed and pointed towards the default texture names could also be very handy to allow for interopability but would be going above and beyond. i.e.

... I think I know how to get that working with minimal complexity. I'm hacking on something now that I should have finished soon, but I'm away from home and only now discovered I haven't installed git on my new MacBook so I'll be unable to push changes until I do so. Will almost certainly have something up early Sunday that works (say, no more than 24 hours). I will let you know once that's ready.

Cheers!

[Poodmund]

Thank you for your explanations, yes that should be fine. When you specify the folder for DiRT to also load textures from, does that only apply to the textures that are contained within KSP's "Default" texture directory? It doesn't necessarily matter too much for me personally but would be good to have clarity.

With respect to the other bits, no rush at all! Enjoy real life as you're busy and just do any dev work when you want to. I'm in no hurry.  

[Cydonian Monk]

18 hours ago, Poodmund said:

When you specify the folder for DiRT to also load textures from, does that only apply to the textures that are contained within KSP's "Default" texture directory?

Do you mean "can you replace non-Squad textures added by mods?" Yes, provided it's a texture applied to a surface (and not something like a menu texture).

Or do you mean "can you replace textures that are outside of GameData?" That's a more difficult question, but probably a yes. You could probably even specify a path to LOAD textures from that's outside of GameData provided your config file is inside GameData and you use a relative path (../../, etc). That's worked in the past for things such as audio files, though I've not tried it with DiRT.

 

The point at which DiRT (or TR or TRR) replaces the textures, it's working off of the list of objects loaded into the game by Unity regardless of where they were loaded from. (Specifically it looks for all "Materials" which have a Shader Property containing either a "_MainTex" or a "_BumpMap".) So any texture added to any surface can be replaced provided the texture name is a valid filename.

This causes problems if, for example, you decide to replace a texture that has a non-unique name. (Let's say a texture named "dish", used by two different mods for the surface texture of their satellite dish part.) In that scenario all textures matching the filename of the "new" texture ("dish") will be replaced with this new texture. Without DiRT (or TR or TRR), the game doesn't have an issue with these name collisions as each model specifies the texture by full path. Such naming collisions are difficult to resolve (such as forcing textures to be in a folder structure under the texture folder that mimic the file paths of the texture they're replacing), and the solutions for resolving the issue are outside the scope of DiRT. Thankfully they're a rare occurrence.

Edit: The replacement code doesn't behave quite the way I originally read it, so such name collisions are even more rare. The substring match between the material's texture name and the replacement uses the file path (relevant to the DiRT textures folder) and file name of the loaded replacement texture for a "begins with" substring match. As the material's texture name also includes the full path (for selected textures, specifically those loaded directly from GameData and not from AssetBundles), this meant most mod textures were only replaced if the full path of where the texture is in the mod (or as output by the Texture name export) is also replicated in the DiRT Textures folder.

Interesting reflex that I'm not going to change just yet as it solves problems, though I will better document it on the next release.

Edited September 30, 2018 by Cydonian Monk

[Cydonian Monk]

DiRT version 1.5.1.0 is now available on GitHub: https://github.com/cydonian-monk/KSP-DiRT/releases/tag/1.5.1.0

ChangeLog:
- Recompiled against KSP v1.5.1
- Updated readme with installation instructions and new post-1.5 suit texture names.

Note: I inadvertently introduced a new folder structure with release 1.4.2.0, in which DiRT\ was the root-level of the release zip file instead of the GameData\ and Source\ folders. This structure made it slightly confusing for installation, especially with the instructions I had provided at the time. However, when unzipping the file this structure makes it more obvious as to what was just unzipped (depending on your compressed file manager of choice). It also made my workflow for releasing DiRT a bit easier, which was the source of the confusion. Therefore I have retained this structure and will use it going forward. My apologies to the CKAN folks, as that 1.4.2.0 release likely broke something at that time.

 

Please note - Your old suit textures will no longer work as/of KSP v1.5.0. The updated texture names are in the readme file (as mentioned above), and the models themselves use a new mapping. (The jetpack is the same model with a new texture mapping, which makes them look weird.) I quite like the new ones, but I'm sure I will eventually decide to customize them. Once I have a "mapper" texture showing what goes where on the new textures I'll share it here. As with the Making History suits, the new post-1.5 suits use the same 2k texture for both helmet and suit. There are three in total - 1 for EVA and the 2 IVAs. All 3 use the same normal map.

I have not yet completed the code which will allow individual texture remapping/renaming, which will come in a future release. My first attempt at this didn't work quite as I expected, so I had to put it on the back burner. I am also working on a system to allow for individual kerbal texture mapping (by kerbal name (and possibly class?)) using the same mechanism, though how quickly those changes are completed will depend on how busy I am over the next month.

[Beale]

@Cydonian Monk I really appreciate this. Texture Replacer is great, but a lighter version is just perfection.

[Cydonian Monk]

5 minutes ago, Beale said:

@Cydonian Monk I really appreciate this. Texture Replacer is great, but a lighter version is just perfection.

 Thanks!

I'm just happy folks have found it useful. It's interesting to see that TextureReplacer itself is trending in the lighter direction too now that it's back in active development. (Which was inevitable - Many of the things I gutted from the old TR codebase were obsoleted by previous Unity and/or KSP versions.)

[Cydonian Monk]

DiRT version 1.6.1.0 is now available on GitHub: https://github.com/cydonian-monk/KSP-DiRT/releases/tag/1.6.1.0

ChangeLog:
- Recompiled against KSP v1.6.1

 

This is just a recompile release, and probably an unnecessary one as the 1.5.1 version seemed to work fine in KSP 1.6.1.

Cheers!

[theJesuit]

1 hour ago, Cydonian Monk said:

DiRT version 1.6.1.0 is now available on GitHub: https://github.com/cydonian-monk/KSP-DiRT/releases/tag/1.6.1.0

ChangeLog:
- Recompiled against KSP v1.6.1

 

This is just a recompile release, and probably an unnecessary one as the 1.5.1 version seemed to work fine in KSP 1.6.1.

Cheers!

This has now replaced texture replacer for now for me I only used TR for helmet removal and skybox... but ksp now does the helmet removal.  So cheers!

Peace.

[Eaten by Black Hole]

Where does this Jool comes from 'Background'

[Cydonian Monk]

On 2/17/2019 at 9:04 AM, Eaten by Black Hole said:

Where does this Jool comes from 'Background'

Which one? The Jool in the image in the first post? That's one I cobbled together from a bunch of different sources, and I have no idea if I can distribute it or not (likely not as I don't recall where I got all of the original textures).

Or are you asking which texture in-game Jool uses? In that case it's "gas1_clouds". 

[Eaten by Black Hole]

On 2/21/2019 at 1:41 AM, Cydonian Monk said:

Which one? The Jool in the image in the first post? That's one I cobbled together from a bunch of different sources, and I have no idea if I can distribute it or not (likely not as I don't recall where I got all of the original textures).

Or are you asking which texture in-game Jool uses? In that case it's "gas1_clouds". 

Shows at first open of the page.That looks so beautiful!!!

[Guest]

Hello Cydonian Monk,

I'm currently planning to set up a ksp install as realistic as possible, but since ro/rss are 1.4.5 I either need dirt for 1.3.1, or better 1.4.5. Unluckily I'm not capable of recompiling it, so could you please create these versions as well? If so, as a return I can give you feedback how it's working on Linux.

Thanks!

[Cydonian Monk]

32 minutes ago, bluescreen said:

Hello Cydonian Monk,

I'm currently planning to set up a ksp install as realistic as possible, but since ro/rss are 1.4.5 I either need dirt for 1.3.1, or better 1.4.5. Unluckily I'm not capable of recompiling it, so could you please create these versions as well? If so, as a return I can give you feedback how it's working on Linux.

Thanks!

Hello!

I was using this build of DiRT on KSP v1.4.5 without issue:

https://github.com/cydonian-monk/KSP-DiRT/releases/tag/1.4.3.0

That might also work with KSP v1.3.1, but you'd need to alter the DiRT.version file and change the minimum KSP version to keep it from barking at you at launch.

If you absolutely need it built and linked against v1.3.1 I can try sometime later in the week. Should work, as the codebase I forked from basically dates back to v0.90. Just might need rebuilt due to Unity/KSP changes from v1.3.1 to v1.4.x.

It _should_ work fine on GNU/Linux, given the Unity engine for Linux has most of the same quirks as it does on OS-X/MacOS (all related to filesystem operations), but I'd obviously like to see positive confirmation before I sign off on it. 

Cheers!

[Cydonian Monk]

Two releases today.

First, it appears KSP 1.7.* has finally settled in on a stable-ish release, so I've rebuilt DiRT against KSP v1.7.2. No other changes, and, to be completely honest, DiRT versions from 1.5.* and forward appear to work just fine in 1.7.*. The simple replacements this plugin attempts are fairly standard and not likely to break until a new version of Unity comes along. Still, it doesn't hurt to have everything recompiled-rewrapped-recooked-rewhatevered when new versions of the core assemblies come along. I tend to be excessively paranoid about API and library versions and the like, having been burned by a great many weird linker/loader/it-should-work things over the decades.

DiRT version 1.7.2.0 is now available on GitHub: https://github.com/cydonian-monk/KSP-DiRT/releases/tag/1.7.2.0

Change Log:
- None. Recompiled against KSP v1.7.2

 

Second, I "backported" DiRT and built it against KSP v1.3.1 for those of you who are still using the pre-TakeTwo versions of KSP and/or RSS/RO/etc. I have no idea if anyone will find this particular build in any way useful, but I figured why not.

DiRT version 1.3.1.0 is also available on GitHub: https://github.com/cydonian-monk/KSP-DiRT/releases/tag/1.3.1.0

Change Log:
- None. Just recompiled against KVP v1.3.1.

Cheers,

[jefferyharrell]

Pardon me for asking what may be a dumb question, but should DiRT 1.7.2.0 be used with KSP 1.7.1? Kopernicus and JNSQ aren't on 1.7.2 yet, is the only reason I ask.

[Cydonian Monk]

22 minutes ago, jefferyharrell said:

Pardon me for asking what may be a dumb question, but should DiRT 1.7.2.0 be used with KSP 1.7.1? Kopernicus and JNSQ aren't on 1.7.2 yet, is the only reason I ask.

It's a good question. Since I didn't have an immediate answer I went ahead and tested DiRT 1.7.2.0 in both KSP v1.7.0 and v1.7.1. I saw no issues or even console errors with DiRT in an otherwise Stock+DLC install for either version. I haven't tried it with any other mods, or JNSQ specifically, but I don't expect any issues. 

So I'd say go for it. Let me know if anything exceedingly weird happens and I can build a 1.7.1-specific version.  

[jefferyharrell]

33 minutes ago, Cydonian Monk said:

It's a good question. Since I didn't have an immediate answer I went ahead and tested DiRT 1.7.2.0 in both KSP v1.7.0 and v1.7.1. I saw no issues or even console errors with DiRT in an otherwise Stock+DLC install for either version. I haven't tried it with any other mods, or JNSQ specifically, but I don't expect any issues. 

So I'd say go for it. Let me know if anything exceedingly weird happens and I can build a 1.7.1-specific version.  

Thanks for the quick reply. I'll let you know if anything unusually weird happens.

[Cydonian Monk]

Just wanted to drop in right quick and say DiRT does appear to work in KSP v1.8.0, at least on my MacBookPro using the version built for 1.7.x. Might be a different story on Windows and/or Linux, but my Windows PC is down at the moment so I don't have a way to test that. I do plan to release a version built against the latest KSP v1.8.x and targeting .NET 4.x+, and will update this thread once that's available. Probably this weekend.

One thing to note - DXT-3 textures will no longer work, so if you were using those to replace anything you'll need to have them converted to DXT-5.

 

*EDIT: Just as soon as I posted this, I noticed DiRT _might_ be causing some older stock parts to become transparent in certain lighting conditions (ambient lighting only, no direct sunlight). That might also be a MacOS or straight KSP bug (especially as I haven't been able to reproduce it either with or without DiRT after I first encountered it), but if you're using DiRT and experiencing oddly transparent parts, blame me first. 

Edited October 19, 2019 by Cydonian Monk

[Cydonian Monk]

DiRT version 1.8.0.0 is now available on GitHub: https://github.com/cydonian-monk/KSP-DiRT/releases/tag/1.8.0.0

Change Log:
- Recompile against KSP v1.8.0.
- Updated references for new version of KSP and Unity.
- Now using .NET 4.7 as the build target.
- Removed a couple "using" statements which are no longer used.

Also, this is the first time I have built this plugin entirely in VisualStudio on MacOS. It works and replaces textures as expected on MacOS 10.14.6 (Mojave). As previously mentioned, my Windows PC is presently "down" (and in a few dozen pieces), so I haven't tested this new build on Windows, but I don't expect any issues. I am not planning to update to MacOS 10.15 (Catalina) any time soon, and I don't have access to a Linux box which is capable of running KSP, so I'd greatly appreciate it if anyone which uses DiRT on any of those other platforms would let me know it works. Thanks!

[RoboRay]

I can confirm that the recompile seems to be working fine with KSP 1.8 on Windows 10.

Edited October 20, 2019 by RoboRay