FusTek Station Parts Dev Thread (continuation of fusty's original work)

[sumghai]

I'd say legally his "All Rights Reserved" is worthless, as he broke the rules of your CC BY-SA he was not allowed to publish his work at all unless it's under that same license.

Now that doesn't mean you can just use them, but means he MUST take them down unless he complies by CC BY-SA

That's what I thought.

I did, however, notice the statement "all rights reserved by authors above." - the confusion lies in that I'm listed as one of said authors.

[Bitterkoekje]

I did, however, notice the statement "all rights reserved by authors above." - the confusion lies in that I'm listed as one of said authors.

Confusing indeed. Does this mean does this mean these rights over nothke's assets also apply to you?

Anyway, I think waiting for Nothke's permission might be the best thing to do.

[Starwaster]

That's what I thought.

I did, however, notice the statement "all rights reserved by authors above." - the confusion lies in that I'm listed as one of said authors.

I interpret that as an incorrect citation of your own license. It's incorrect information but it's not an attempt to claim rights nor is it applying a license to any of the works. Just an incorrect / inaccurate conveyance of information.

[sumghai]

Finally got a reply from nothke, although he didn't address the licensing issue (yet)...

[nothke]

Hay guys!

Sumghai contacted me a few days ago to tell me about the UV changes and the licence problem. As I am working on my own game right now, I thought I could make a little break and work on some HD texturing =) It took me a bit longer than I thought.. As is usual xD

Unfortunately, at the time when I already got Kombobulus and Konsequence ported to the new texture system, Sumghai pointed me to Bitterkoekje’s post, and I’ve seen that he already redone them =( Damn, should’ve checked the forum, would’ve spared me some ~4 hours =(

With redoing the old textures, I also made 2 new ones =) I hope you like them =) You can see them here in the album:

Javascript is disabled. View full album

I have not redone “Kerpton†cause I’ve noticed from the mod that InsaneDruid already did MLI blankets, inspired by my textures. Nice work =)

Donwload:

https://drive.google.com/file/d/0B6-Kp1pObiWgU1JaUG8wa3ZhN0E/view?usp=sharing

Note that you MIGHT not be able to run all the textures at the same time, the 32bit KSP will definately crash, check "issues" section below for more info.

I am sorry that I was so messy with the licence back then, and the sloppy credits. I considered the old texture pack to be temporary, until the next map changes when they might be a part of the official mod. In the mean time I left the KSP “modding sceneâ€Â, so it basically went out of my mind.

That being said, the licence on the texture pack is now CC BY-SA 4.0, you can find the details in the license.txt in this pack. I have removed the link from the old post as it's basically "deprecated", but if you REALLY want to use the old textures, know that they are under the same license as the new one, just there's less job for me as I don't need to repack it.

There are some unfinished parts of the current textures, especially the icons (which I just experimented with on the Kirbo), and I am inviting anyone to finish them if they wish =) I am probably not going to touch these textures anytime soon.

While working on the textures, there were some issues that I encountered:

• Memory problems - 4k textures are eating all the memory! With no other mods, I managed to have up to 4 texture packs (2 4k textures per pack, diffuse and normal) in my 32bit KSP, anything over that would just go over 4GB and crash KSP on load. Also, not only RAM memory is the problem, but also the graphics memory, sometimes the game would crash in VAB and the log would say that it was unable to allocate the memory on the GPU. I guess using “half†or “quarter†resolution in the settings would at least run KSP properly, but is not a solution to the problem. I suggest using 2k textures, or remapping the models to a tighter map so they fit into a 2k texture at the current size.
  
• I had to use .tga for the diffuse as .png does not save an alpha channel (note that “transparency†and “alpha†are two different things, 100% transparent pixel in a .png does not save color data, therefore using it for specular map is not possible). The downside of .tga is their big drive size (60MB for 4k texture), but note that KSP loads textures to memory at their uncompressed size no matter what format they are. Also, it seems that KSP doesn’t support compressed .tga-s, they won’t show to me in game. KSP also does not generate mip maps for .png-s for some rason, this is a long standing known issue, which not only makes a pixel jitter when looking at the texture from the distance, but also makes the game render the texture at maximum resolution all the time. Also, all .pngs goes through a decompression process when KSP loads them, which takes some noticeable time for 4k textures. Also note that when in a compressed package all textures together are ~20MB, so the only negative side of tga-s is the large space on the HD.
  
• There are some mapping mistakes that I noticed, for example here and here.
  
• Vertex normals should be corrected so that they follow the cylindrical shape of the modules. At some points, especially around nodes in a node module and windows, seams are quite obvious and really break the nice specular reflection (like here). I know that unity can import custom vertex normals, I have done it before with models from 3ds max, although I don’t know if Blender has an ability of modifying vertex normals directly.
  

[sumghai]

Hay guys!

Sumghai contacted me a few days ago to tell me about the UV changes and the licence problem. As I am working on my own game right now, I thought I could make a little break and work on some HD texturing =) It took me a bit longer than I thought.. As is usual xD

Unfortunately, at the time when I already got Kombobulus and Konsequence ported to the new texture system, Sumghai pointed me to Bitterkoekje’s post, and I’ve seen that he already redone them =( Damn, should’ve checked the forum, would’ve spared me some ~4 hours =(

Took you long enough XD

With redoing the old textures, I also made 2 new ones =) I hope you like them =) You can see them here in the album:

http://imgur.com/a/PHrH4

Kirbo and Kozhukh look very nice, and are excellent additions to the FusTek family.

I have not redone “Kerpton†cause I’ve noticed from the mod that InsaneDruid already did MLI blankets, inspired by my textures. Nice work =)

Yep, MLI Blankets is pretty much Kerpton.

(*pats InsaneDruid on the back*)

I am sorry that I was so messy with the licence back then, and the sloppy credits. I considered the old texture pack to be temporary, until the next map changes when they might be a part of the official mod. In the mean time I left the KSP “modding sceneâ€Â, so it basically went out of my mind.

All's well that ends well

While working on the textures, there were some issues that I encountered:

• Memory problems - 4k textures are eating all the memory! With no other mods, I managed to have up to 4 texture packs (2 4k textures per pack, diffuse and normal) in my 32bit KSP, anything over that would just go over 4GB and crash KSP on load. Also, not only RAM memory is the problem, but also the graphics memory, sometimes the game would crash in VAB and the log would say that it was unable to allocate the memory on the GPU. I guess using “half†or “quarter†resolution in the settings would at least run KSP properly, but is not a solution to the problem. I suggest using 2k textures, or remapping the models to a tighter map so they fit into a 2k texture at the current size.
  

This is one of those "you can't have your cake and eat it too" problems.

When the individual panels shared UVs, I was able to pack everything tightly inside a smaller image; but since your alternative pack required larger non-repeating regions to effectively depict the patterns on them, the image had to get bigger.

Of course, there are a couple of other reasons the current atlas is so large:

- I wanted reasonably high fidelity detail on the modules, including legible text labels. Also, lower resolution normal maps looked horribly pixelated.

- I'm actually future-proofing my texture files so that I have room for things like trusses, optional surface-attached accessories and landing leg kits.

That being said, it's not all doom and gloom:

- KSP 1.0 will soon natively support DDS textures, which offers some reduction in memory as well as much faster loading times. I'm definitely migrating my add-ons to use DDS once 1.0 comes out.

- As mentioned earlier, the high-res textures were made at a time when I wanted the module text labels to be as legible as possible. Since then, I've figured out how to do clever stuff by combining hi-res translucent alpha textures for "floating" text and medium-to-low-res textures for other bits. So if people don't mind significant loss of visual quality, I can reduce the dimensions of the common atlases from 4096 x 4069 px to 2048 x 2048 px, and possibly figure out how to float the "AIRLOCK ACCESS" and "VISITING SPACECRAFT END - INSTALL DOCKING PORT BEFORE FLIGHT" over the top.

(Actually, I'll do the downsizing in just a moment - get ready to grab the latest experimental build, guys)

• I had to use .tga for the diffuse as .png does not save an alpha channel (note that “transparency†and “alpha†are two different things, 100% transparent pixel in a .png does not save color data, therefore using it for specular map is not possible). The downside of .tga is their big drive size (60MB for 4k texture), but note that KSP loads textures to memory at their uncompressed size no matter what format they are. Also, it seems that KSP doesn’t support compressed .tga-s, they won’t show to me in game. KSP also does not generate mip maps for .png-s for some rason, this is a long standing known issue, which not only makes a pixel jitter when looking at the texture from the distance, but also makes the game render the texture at maximum resolution all the time. Also, all .pngs goes through a decompression process when KSP loads them, which takes some noticeable time for 4k textures. Also note that when in a compressed package all textures together are ~20MB, so the only negative side of tga-s is the large space on the HD.
  

I believe there a variations on the PNG format, some of which do allow specular map information (RGBA?). Also, the aforementioned DDS migration will support RGBA textures.

• There are some mapping mistakes that I noticed, for example here and here.
  
• Vertex normals should be corrected so that they follow the cylindrical shape of the modules. At some points, especially around nodes in a node module and windows, seams are quite obvious and really break the nice specular reflection (like here). I know that unity can import custom vertex normals, I have done it before with models from 3ds max, although I don’t know if Blender has an ability of modifying vertex normals directly.
  

Yikes!

Now those I should be able to easily fix if I go over my models with a fine-toothed comb and play around with mesh smoothing / edge split / mark sharp.

[sumghai]

(Quickie) Progress Report, 15 April 2015

Number of days without a KSP-runnable laptop: 77

I'm taking a huge risk with that texture size reduction, guys.

I suspect that visual fidelity would suffer, especially when doing closeups of module text (that is, unless I can figure out how to redo the text as decals just like on the hatches). Could you guys test these for me on your end, and see how badly pixelated these turned out?

[hieywiey]

(Quickie) Progress Report, 15 April 2015

Number of days without a KSP-runnable laptop: 77

I'm taking a huge risk with that texture size reduction, guys.

I suspect that visual fidelity would suffer, especially when doing closeups of module text (that is, unless I can figure out how to redo the text as decals just like on the hatches). Could you guys test these for me on your end, and see how badly pixelated these turned out?

I don't mind texture reduction as this mod with the JSI transparent windows lags the hell out of my computer (it's a laptop, but a pretty powerful one despite the fact that it's from 2008, I call it "Old Reliable" cause it REALLY is. Oh, and I forgot to mention that it is a Mac, I have Bootcamp though. PLEASE no Mac vs. PC debates here, it's a personal preference.)

[sumghai]

I don't mind texture reduction as this mod with the JSI transparent windows lags the hell out of my computer (it's a laptop, but a pretty powerful one despite the fact that it's from 2008, I call it "Old Reliable" cause it REALLY is. Oh, and I forgot to mention that it is a Mac, I have Bootcamp though. PLEASE no Mac vs. PC debates here, it's a personal preference.)

Haha, I see.

Could you try out the latest update and tell me what you think of the reduced-size common textures?

[sharpspoonful]

This is one of those "you can't have your cake and eat it too" problems.

When the individual panels shared UVs, I was able to pack everything tightly inside a smaller image; but since your alternative pack required larger non-repeating regions to effectively depict the patterns on them, the image had to get bigger.

Tbh, I don't care if the texture repeats. Nothke's textures are stunning, but I'd rather be able to use them all by reducing the normal maps/using repeating textures, or limiting the each textures to one or two different parts. Having these massive .tga's eating up limited RAM is neither useful or cost effective.

- I wanted reasonably high fidelity detail on the modules, including legible text labels. Also, lower resolution normal maps looked horribly pixelated.

Avoid text and utilize visual markings on the exterior. Text is great, but I'd be ok sacrificing it all together.

- I'm actually future-proofing my texture files so that I have room for things like trusses, optional surface-attached accessories and landing leg kits.

Thats totally fine, but some slight pixelation isn't the end of the world. Especially considering that you don't control Kerbals from first person.

- KSP 1.0 will soon natively support DDS textures, which offers some reduction in memory as well as much faster loading times. I'm definitely migrating my add-ons to use DDS once 1.0 comes out.

If you think it will reduce memory usage by a lot then I'd be fine with the larger normals.

- As mentioned earlier, the high-res textures were made at a time when I wanted the module text labels to be as legible as possible. Since then, I've figured out how to do clever stuff by combining hi-res translucent alpha textures for "floating" text and medium-to-low-res textures for other bits. So if people don't mind significant loss of visual quality, I can reduce the dimensions of the common atlases from 4096 x 4069 px to 2048 x 2048 px, and possibly figure out how to float the "AIRLOCK ACCESS" and "VISITING SPACECRAFT END - INSTALL DOCKING PORT BEFORE FLIGHT" over the top.

Can you float them like you did with the hatch decal?

[wasmic]

Tbh, I don't care if the texture repeats. Nothke's textures are stunning, but I'd rather be able to use them all by reducing the normal maps/using repeating textures, or limiting the each textures to one or two different parts. Having these massive .tga's eating up limited RAM is neither useful or cost effective.

I don't think it should go back to all the panels being the same texture, but some repetition would be ok.

Avoid text and utilize visual markings on the exterior. Text is great, but I'd be ok sacrificing it all together.

I agree with this wholeheartedly. The text is nice, but icons and pictograms would be better.

[Kanddak]

I've always had to play with texture quality at eighth res to get acceptable performance, so I'm used to everything being a bit pixelated and there's no discernable difference for me.

I wonder if there's some way you could satisfy those of us with tight RAM constraints while still making higher-quality textures available for those who can handle them? I imagine maintaining seperate high- and low-resolution releases would be too much of a gigantic hassle.

[sumghai]

Progress Report, 16 April 2015

Number of days without a KSP-runnable laptop: 78

As mentioned previously, I've gone ahead and shrunk the main textures / normal maps from 4096x4096 px down to 2048x2048 px. Please test this out for me and see if the size reduction offers any performance improvements - if so, this will be the new, permanent size.

I've also opened up Issue #52 to move the following text labels to a separate hi-res translucent alpha image that will "float" over the modules just like the hatch decals:

• CAUTION - BAY DOORS MAY MOVE WITHOUT WARNING on Warehouse / Payload Bay
  
• AIRLOCK ACCESS on Kuest and Kuest Legacy Airlocks
  
• VISITING SPACECRAFT END - INSTALL DOCKING PORT BEFORE FLIGHT on Kirs Docking Module
  

Also, a bit more work on IVAs and in particular, storage lockers - it's slow going, but because many modules will be using lots of these lockers, once these are finished the internals will get populated really quickly:

Fig 85 - (WIP) FusTek Internals (9)

Testers - please grab the latest version of the pack, make a clean install (plus dependencies) and tell me:

- If the reduced textures look okay (ignoring the text labels)

- If JSI RPM makes the mission flag appear on all of the FLEXracks

Edited April 17, 2015 by sumghai
Missing tally for # days without being able to run KSP XD

[sharpspoonful]

-Reduced texture size looked fine for both the stock textures and MSI Blankets, not so much for the KSO textures.

-JSI RPM mission flag and the words "FlexRack" did not appear for me.

[Dave7]

All of the textures look ok to me. I also did not see FlexRack or the mission flag.

[sumghai]

-Reduced texture size looked fine for both the stock textures and MSI Blankets, not so much for the KSO textures.

All of the textures look ok to me.

Sounds good. I'm most likely sticking with the new 2048 x 2048 px size from now on.

The KSO textures are outside my control, since SippyFrog doesn't have the time right now to rework them.

InsaneDruid did have the following to say, however:

Especially since KSP 1.0 will have proper DDS support I don't think that such an reduction will lead to an significant performance gain anymore. But it will reduce texture fidelity, especially as the most parts only use a fraction of the size of the texture. For users that do want smaller textures ksp already has its texture size-slider, and (at the moment) both ATM and dds-loader can be configured to reduce texture size/drop the biggest mipmap, too. So long story short: I would keep the size, so that players who want more fidelity can have them, while players beein desparate can adjust the size ingame wihout problems.

-JSI RPM mission flag and the words "FlexRack" did not appear for me.

I also did not see FlexRack or the mission flag.

This doesn't sound good. I'll check to see if I left out the associated decal file.

[sumghai]

Okay, I've re-exported the internal FLEXrack prop and recommited it. Binary file compare said that the previous version was missing a few bits and pieces, so hopefully the decals (and flags if you have JSI RPM) should show up now.

I've also turned the text markings on the modules into decals - could you guys please also test these too? Thanks.

Next Up:

- Fixing the UV mapping / vertex issues nothke raised

- Turning the module ID symbols into decals on the common texture atlas as well (no more separate icon images / one less FStextureSwitch doohickey)

- Resuming work on IVAs, as usual

[sumghai]

Progress Report, 22 April 2015

Number of days without a KSP-runnable laptop: 84

- All of the parts have been reworked them so that the module ID symbols are now decals and integrated into the main texture atlas itself. This means fewer images alt texture pack makers will have to deal with.

- The other text labels on the modules e.g. AIRLOCK ACCESS are now decals as well. The text is medium-res at close range, while allowing the rest of the parts to have lower-res textures to save RAM.

- I've decided that the yellow and red-rimmed Karmony hatches should be exempt from texture switching, as it is the "signature" of FusTek modules.

- The preceding changes mean that I can now remove most of the FStextureSwitch PartModules, so that one set of controls is able to change the appearance of the entire module (save for the previously-stated exemption). This also means I can drop my request to Snjo to make the Master/Slave FStextureSwitch system.

- The models have also been reworked to fix many of the vertex issues nothke reported; this was particularly prominent in case of the Karmony series modules (Hab, Sci, Utils, Logistics), because my original plan to make them use modular meshes ended up leaving sharp transitions between certain panels. I wasn't able to fix the stress lines near the nodes or the window cutouts, because manually adjusting the vertex normals in Blender to do so requires a non-trivial amount of effort for insignificant gain. As a result, some of the models have been slightly "unoptimized", but I think this is an acceptable compromise.

- Unfortunately, because SippyFrog hasn't got around to updating his KSO texture pack, I've decided to take it out of my repo, since it's not fair on users if I kept redistributing his outdated pack without being able to update it myself. Sippy can rework his textures once he has the time after R0.04a comes out.

Guys, please test the updated parts for me and let me know how the new decals turned out. Also, could you guys please confirm I've fixed the internal FLEXrack decal issue? Thanks.

[curtquarquesso]

Progress Report, 22 April 2015

Number of days without a KSP-runnable laptop: 84

- All of the parts have been reworked them so that the module ID symbols are now decals and integrated into the main texture atlas itself. This means fewer images alt texture pack makers will have to deal with.

- The other text labels on the modules e.g. AIRLOCK ACCESS are now decals as well. The text is medium-res at close range, while allowing the rest of the parts to have lower-res textures to save RAM.

- I've decided that the yellow and red-rimmed Karmony hatches should be exempt from texture switching, as it is the "signature" of FusTek modules.

- The preceding changes mean that I can now remove most of the FStextureSwitch PartModules, so that one set of controls is able to change the appearance of the entire module (save for the previously-stated exemption). This also means I can drop my request to Snjo to make the Master/Slave FStextureSwitch system.

- The models have also been reworked to fix many of the vertex issues nothke reported; this was particularly prominent in case of the Karmony series modules (Hab, Sci, Utils, Logistics), because my original plan to make them use modular meshes ended up leaving sharp transitions between certain panels. I wasn't able to fix the stress lines near the nodes or the window cutouts, because manually adjusting the vertex normals in Blender to do so requires a non-trivial amount of effort for insignificant gain. As a result, some of the models have been slightly "unoptimized", but I think this is an acceptable compromise.

- Unfortunately, because SippyFrog hasn't got around to updating his KSO texture pack, I've decided to take it out of my repo, since it's not fair on users if I kept redistributing his outdated pack without being able to update it myself. Sippy can rework his textures once he has the time after R0.04a comes out.

Guys, please test the updated parts for me and let me know how the new decals turned out. Also, could you guys please confirm I've fixed the internal FLEXrack decal issue? Thanks.

Awesome. Do you have any pictures for the visual people here?

[sumghai]

Awesome. Do you have any pictures for the visual people here?

My current laptop can't run KSP, so no pictures.

Number of days without a KSP-runnable laptop: 84

Besides, these are very minor visual tweaks not worthy of screenshots anyway.

[SebFierce]

Test Log:

Installation:

KSP 0.90.0.705

Fustek Station Parts R0.04a Apr 2015

Dependencies:

CLS 1.1.2.0

Firespitter Plugin 6.3.5

MFT 5.4.3

MM 2.5.13

Ship Manifest 4.1.4.4

RasterPropMonitor 0.18.4

The internal FLEXrack props should now have a FLEXracks decal and a JSI-powered mission flag at the top, as well as a barcode sticker at the bottom

- The FLEXracks have decals, mission flag and barcode sticker when looking into the module from the outside, in IVA said elements are not visible

- Parts tested: Habitation, Habitation A, Utilities, Utilities A, Science, Science A

Instead of separate module ID symbol textures, the icons are now part of the main texture atlas, and are applied over the appropriate module as floating decals

- All module parts have a symbol, all parts have the right symbol

- Parts tested: Resupply, Habitation, Habitation A, Logistics, Logistics A, Payload Bay, Payload Bay A, Utilities, Utilities A, Warehouse, Warehouse A, Science, Science A

Same for the airlock / payload bay door warning labels, they are now decals too

- All airlocks and payload bays have good looking warning labels

- Parts tested: Kuest Airlock, Kuest Legacy, Payload Bay, Payload Bay A, Warehouse, Warehouse A

The Karmony hatches will no longer have texture switching, since I want to keep this consistent across all texture packs

- All hatches except the IACBM 2.5 one have the same texture across texture packs

- Parts tested: Resupply, Habitation, Habitation A, Logistics, Logistics A, Utilities, Utilities A, Science, Science A, compactNode, compactNode A, Kirs, Kuest, Kuest Legacy, Kupola, IACBM 1.25, IACBM 2.5

- IACBM 2.5 retrofit hatch still has texture switching and an old hatch texture

KSO texture pack has been removed as SippyFrog plans to eventually remake it from scratch

- KSO textures don't show up in the FS texture switch menu

- Parts tested: all

MLI Blankets has not yet been updated to the new texture layout

- some MLI blanket textures look okayish, the rest is broken (not a surprise I guess)

MOARdV has been busy with other stuff, and so he hasn't had to time to help me fix the inconsistent viewport shutter animation issue; for now, I'm forcing the shutters to remain open all the time

- Viewports can't be toggled

- Parts tested:Habitation, Habitation A, Utilities, Utilities A, Science, Science A

[Stone Blue]

Dependencies:

CLS 1.1.2.0

Firespitter Plugin 6.3.5

MFT 5.4.3

MM 2.5.13

Ship Manifest 4.1.4.4

RasterPropMonitor 0.18.4

Wait...Are these ALL dependencies, now, or dependencies and SUPPORTED mods?

Edited April 27, 2015 by sumghai
Fixed broken quote

[sharpspoonful]

Dependencies:

CLS 1.1.2.0

Firespitter Plugin 6.3.5

MFT 5.4.3

MM 2.5.13

Ship Manifest 4.1.4.4

RasterPropMonitor 0.18.4

Wait...Are these ALL dependencies, now, or dependencies and SUPPORTED mods?

Firespitter, MM, CLS or ShipManifest, RPM, and MFT are hard dependencies.

Firespitter will allow you to switch between textures.

Module Manager allows for the quick .CFG edits to hook into the parts.

CLS/ShipManifest allows you to move kerbals around your parts.

RPM allows for the ability to see into the habitable parts.

MFT allows for you to edit the resupply container to resupply your station.

Edited April 27, 2015 by sumghai
Fixed broken quote

[sumghai]

Hey Seb, mucho gracias for the test report. As you found out shortly before 1.0 dropped, I fixed those couple of issues you mentioned

I've also moved these posts to the dev thread, since that's where Test Logs should go.

Wait...Are these ALL dependencies, now, or dependencies and SUPPORTED mods?

To clarify:

- The only hard dependencies that you must have are ModuleManager, JSI RasterPropMonitor, Ship Manifest and Connected Living Spaces.

- Anything else listed is optional but will improve your gameplay experience.

This information is clearly listed in the first post of the (not really a proper) release thread.

Edited April 27, 2015 by sumghai

[sumghai]

(Quickie) Progress Report, 30 April 2015

Number of days without a KSP-runnable laptop: 92

My priority right now is to get SDHI SMS updated for KSP 1.0, but I managed to push some fixes to FusTek tonight:

- KSP 1.0 now enforces stricter definitions for stack attachment node orientations, which is why you guys are hearing about add-on parts no longer being stackable in the VAB/SPH editor. Most of the FusTek parts were okay, but I dropped the ball on the IACBM and node covers - these have been fixed now.

- FusTek has migrated to using DDS textures, which should hopefully speed up loading times. Alt texture packers such as InsaneDruid and SippyFrog will update their packs at their own discretion.