[Plugin][0.23] KSPaint - Texture Coloruing Made Easy - Alpha V0.1

[ChevronTango]

This is my first mod, though I've been on the Forums as a lurker for quite a while. Not sure how good this has come out but I thought I'd post where I'm up to and see if Excitement got stirred or if people feel it not worth much.

KSPaint is a tool to Color/Skin your spacecraft parts in game, per craft, and per part on craft. While in the VAB or SPH you may select a part and in the ActionGroups Tab, Choose how you'd like it Colored. Many ColorModes are currently implemented but not extensively tested, and more and exciting ones are on the way. The Author recommends sticking with Normal for now.

When a part is selected and the PopUp open you choose the blend mode (stick with Normal for now but the others should still work), the Red, Green, Blue values of the color you want and the Alpha (transparency) of the color overlay.

IMPORTANT - Not all Textures in game can be edited

Due to Factors beyond my control Textures imported by Squad generally aren't readable and so are incompatible with this mod

A workaround is to use addods where the Textures are readable (B9 is good) or to use TextureReplacer where the textures are readable on the stock parts

I'll Update with more Information soon.

Currently I'm not allowing Distrubution or Use of my source by others. This will likely change when later versions come out.

Download - MediaFire

Still To be Developed:

Importing Images

Multiple Layers

Replacing Non-Readable Textures

Improved UI

Clone Texture Style From one part to another

Update all Textures Parts with multiple Textures Defined

Edited February 11, 2014 by ChevronTango
Adding Details

[lyndonguitar]

nice,, What are the differences between KerbPaint and this?

Can I paint custom parts?

[ChevronTango]

KSPaint allows for texturing of any part providing its texture is readable. I've tested this with Infernal and B9 with no problems, so its really only the stock parts that are problematic atm, but those will soon be fixed so this becomes universal. The plan is for the Texture Editor in game to have layering and blending similar to most image editing suites, hence the rather large amount of blend modes that seem superfluous with only solid colors atm, but in addition I'm looking to have importable textures, because having hot rod flames, go faster stripes, or the British Airways Tail Fin sounds like a giggle.

KerbPaint was an inspiration for this, and in many ways at the time of writing is likely to be a preferred choice for most, but the aim is for KSPaint to become more powerful and universal. Bare in mind this is my first mod so its going to be a little rough around the edges.

[rasheed]

Sorry i don't get it, i select a custom part in SPH and nothing happens?

EDIT: K it doesn't work on some non stock parts?

e.g PWings

Edited February 11, 2014 by rasheed

[ChevronTango]

Whether a part works or not with this is down to whether the texture it has is readable, which is a Unity Feature that defaults to false for most parts. If it works with a part then you need to select (left click) the part whilst in the ActionGroupEditing mode, not PartEditing mode. If you've used the TextureReplacer I've linked to in the OP then all the wings (not Control Surfaces) will be paintable. b9 by default should all be paintable aswell but I haven't checked every part yet. Please do bare in mind this is a very early alpha release.

EDIT: I will be looking at getting this working for all parts, its the highest priority of the current development stream. If anyone has any input on this please PM me.

[Faark]

Textures can be unreadable for other reasons than "is stock part". True, stock-ksp does load all its MBM files as unreadable, but normal maps will become unreadable as well and some texture related mods do this as well. It kind of makes sense, since this means Unity/DirectX can transfer the texture to GPU memory without keeping another copy in system RAM (=> kinda less memory usage). As for "how to fix t hat"... well, you can't, afaik. You can either go native and use e.g. DirectX directly to read the texture (you should try to avoid that for a number of reasons) or manually load the texture from disk...

I haven't yet tried it, but from looking over the code:

- where do you prevent the game from copying the texture when the player has not selected a custom color? You know, since this should be the default for most cases & memory isn't free. Sure you have alpha == 0, but the default value for every part seems to be 3/4

- where do you re-use textures painted in a specific color? Same reason as above... the img in your start post could save 6 textures that way

- mipmapCount is always > 0, you want to check it for > 1

- why do you manually update mipmap levels? That should be done by Unity / DirectX for you. Thats actually the reason you pass "true" to Apply

- I'm pretty sure GetPixels32 does returns a new array and copies the textures data into it. In that case you might not have to create another one

- What about other texture formats? That currently annoys me in an own project. Do you plan to stick with ARGB32 for everything in a longer term?

[ChevronTango]

As stated, its an early alpha I bashed out this weekend. I'm aware that its not just stock parts that are unreadable. I have some rough leads on possible solutions but I imagine this will likely be the hardest part of the mod, so the fact that I have something working around that at the moment I'm counting as a victory, though we're hardly off the starting block with this yet.

I've set the default to be colored so that you can see the mod working when loaded(This won't be so in the release, but I figure if people are trying this out it would be good for them to see it working). I'd need to do a check the target color array to make sure it matches the source exactly before defaulting to no Overriden Texture, but with alpha == 0 that's a guarantee, so quicker to do it that way for now and add the comparison in later.

I've thought about a single pool of textures from which to draw from and will likely implement this for efficiency at a later point. We're still in the proof of concept phase so little things like that have fallen by the way side, but are on the drawing table. I've currently got the popups using the same popup by reference so I don't think it'll be a stretch to apply this to other parts.

The mipmap stuff is very useful to know. I figured there was a flaw in what I'd rather hastily looked up and written in a single weekend so thanks for the pointers there (I started this Saturday Lunchtime and finished Sunday Lunchtime, don't judge me, I do have a life honest... ).

ARGB32 is what I'm currently sticking with for now, as its going to be the simplest with regards calculations and such. If there's a good reason to expand beyond this I'll make a move to adopt it but it seems like a good enough sticking point for now.

All in all there's still a long way to go but I appreciate the pointers and hopefully should be able to get on to a lot of this in the next few weeks.

Edited February 11, 2014 by ChevronTango