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

[Moon Goddess]

Very good and timely idea, sumghai!

I also suggest you to make a ladder or even a single staple as separate primitive too.

I seriously doubt the ladder is causing any optimization issues, since it already uses the same texture space over and over. If it were different on each module then it would be logical to be a separate primitive, since the ladders are the same on every module then you reduce each primitive to the least amount of difference, ladders don't change, thus they aren't a difference, and remain on the module primitive.

It's that reduction of 83 pings to 1 that's gonna seriously improve loading times.

[NathanKell]

Hurrah! Love the plans.

[sumghai]

Wow, great job on the optimization. The footprint of this mod is going to be miniscule after this.

I hope so, too. I fear that when I start working on Internals, the footprint may increase again (unless I can use MODEL{} calls or equivalent there as well).

I also suggest you to make a ladder or even a single staple as separate primitive too.

I seriously doubt the ladder is causing any optimization issues, since it already uses the same texture space over and over. If it were different on each module then it would be logical to be a separate primitive, since the ladders are the same on every module then you reduce each primitive to the least amount of difference, ladders don't change, thus they aren't a difference, and remain on the module primitive.

Moon Goddess mostly has it right - there comes a point in optimization where you get diminishing returns for each additional effort you put into it. I could in theory chop my models up into even smaller primitives, but then I'd be inundated with twenty-odd MODEL{} calls to the point of inpracticality.

In the specific case of the ladders:

- The Karmony Mission Modules (Hab / Logistics / Sci / Util) and the MkIII Node share one common design which is actually already highly optimized (in Blender, I actually only modelled one of the "staples", and then used the Linear/Rotational Array modifier to repeat as many as I wanted dynamically, such that if I changed the original stape, all the other instances will automatically updated)

- The Kirs Docking Module, the Kupola and the Kuest Airlocks all have their own, unique and individual ladder layouts, so they need to be manually modeled

It's that reduction of 83 pings to 1 that's gonna seriously improve loading times.

Weeell....I wouldn't say it would end up as just *one* PNG - the "common" atlas would require at least *three* PNGs (texture, normal, emissive).

Stuff like the red/yellow hatches and the different module ID symbols will need to be separate thumbnail-sized PNGs, so that they can be "swapped" via MODEL{} node calls.

[NoMrBond]

You don't want to cut it up too fine either, too many MODEL{} calls for a part plays merry hell with the game (it doesn't cause crashes like overloading on textures, but you start getting serious lag).

[sumghai]

You don't want to cut it up too fine either, too many MODEL{} calls for a part plays merry hell with the game (it doesn't cause crashes like overloading on textures, but you start getting serious lag).

But of course

---

The recent 0.22.0 release has put a bit of a spanner in things, as I have to migrate over to the new version in order to take advantage of the faster scene transition times and tech tree for the station parts. Just off the top of my head:

- Tech tree integration won't happen until R0.04a - I suspect most of the FusTek parts would go under the "Composites" node.

- It will probably take a long time for me to fully understand the science / biome system in order to setup up something sensible for the Karmony Science Modules (as well as any associated experiment / payload racks)

[Helix935]

you could just have the science module perform the functions of the mystery goo container and science bay by having one large or two small vents open for mystery goo and a panel move to expose a mini science bay inside.

[HeadHunter67]

Take your time with updating the Science module - I know when it's done it will be a quality part. You've never failed to amaze us before.

[Captain Sierra]

Sumghai, Weren't you at one point thinking about doing KASPAR integration on the warehouse module? If not, you should certainly talk to the guy. Having that integrated with FuzTek would be insanely awesome. Optimizations are looking fantastic. That plus .22 equals unrivaled megastations.

[sumghai]

Sumghai, Weren't you at one point thinking about doing KASPAR integration on the warehouse module? If not, you should certainly talk to the guy. Having that integrated with FuzTek would be insanely awesome. Optimizations are looking fantastic. That plus .22 equals unrivaled megastations.

KASPAR integration has long been planned for R0.04a, and not *just* for the Parts Warehouse - I'm also thinking of doing dedicated science racks, as well as generic "payload" racks.

[sharpspoonful]

You said nothek (I cannot remember how to spell his handle, so please forgive me) was waiting for .22 update correct?

[sumghai]

You said nothek (I cannot remember how to spell his handle, so please forgive me) was waiting for .22 update correct?

My understanding was the nothke was waiting on two things:

- the (now-released) KAS 0.4.x, which comes with container/rack handling

- KSP 0.22, to see how the science experiments PartModules work

Needless to say, both are out now, although I gather that the latter requires a bit more time for add-on authors to wrap their heads around.

[NoMrBond]

The URM tank stuff which was being assembled via MODEL{} calls inthe KOSMOS pack and was working fine in 0.21 now randomly falls apart (engines fall off, tanks fall away from launch clamps, radial decouplers fall off etc etc), so umm, yeah, no idea why that's happening now but just something you may want to test (if possible)

[MOARdV]

The URM tank stuff which was being assembled via MODEL{} calls inthe KOSMOS pack and was working fine in 0.21 now randomly falls apart (engines fall off, tanks fall away from launch clamps, radial decouplers fall off etc etc), so umm, yeah, no idea why that's happening now but just something you may want to test (if possible)

I reported the tank / launch clamp problem with KOSMOS last night. For whatever reason, KSP has a "Ground Contact! Error" that happens when you transition to flight mode on the launch pad (look in the debug log). In 0.21, the error was 0.006m. In 0.22, the error is now 0.141m. The physics engine is active, so that adjustment causes some phantom forces to apply to the ship. In 0.22, it seems to exceed the ability of the launch clamp's breakingForce or breakingTorque. I adjusted both of those values (by editing clamp's part.cfg) to 1500 (from the default 150), and I haven't had a ship fall out of the clamps since then. They still wobble, and sometimes one clamp shifts a bit on the fuel tank, but the ships aren't falling out any more.

[sumghai]

Progress Report, 20 October 2013

Now that I've acquainted myself with 0.22.0, I can get back to doing what I do best:

Fig 38 - (WIP) FusTek Station Parts - Optimization for R0.04a (2)

With practically all of my models re-imported and cut down into primitives, I can start texturing them together all at once:

- Each imported model was (temporarily) put inside an Blender empty axes object, to serve as the local part origin for when I split them back into separate files. Also makes it easier to keep stuff organized.

- One consequence of the prior point is that shifted origins does funny things to part animations in Blender (i.e. the Kupola shutters). Redoing all the animations at the end shouldn't be too hard, though.

- Although I originally intended to only make one hatch mesh, and use MODEL{} node / texture calls to generate both normal and EVA hatch variants, I ended up making duplicates for reasons which would become clear in a moment.

- I did some minor tweaks to the mesh geometries on some models, mainly to make UV mapping easier. Don't expect any performance gains from such trivial endeavors, though.

The following, by the way, is what my revised "common" texture atlas currently looks like:

Fig 39 - (WIP) FusTek Station Parts - Optimization for R0.04a (3)

This is the reason I've going through the trouble of temporarily putting all my models in the same Blender file - it allows me to quickly see which regions in each models can be reused in others, thereby helping me consolidate the original 80+ PNGs down to ten or so textures/normals/emissives. Notice how the signature FusTek panelling has been whittled down to a handful of common sizes that are then reused liberally throughout most (if not all) of the modules.

You'll also notice that the texture atlas is 2048 x 1024 px, whereas most textures in KSP are squares - originally, I was going to split this atlas up into two 1024 x 1024 px images. However, while discussing alternative texture packs with nothke, I had a number of ideas / thoughts:

- The Firespitter plugin has the ability to swap textures on-the-fly in-game, I'd like to repackage said feature into my own plugin so that users can change the textures on their FusTek parts between a number of third-party created styles on-the-fly.

- Said plugin PartModule can handle multiple instances of texture-swapping, but I decided that it would be better for users to minimize the number of mouse clicks required to do so, hence the large and somewhat ungainly atlas.

- SQUAD does sometimes have non-square textures in their stock parts (such as the parachutes and docking ports), but my understanding is that as long as the dimensions are in powers of 2 (i.e. 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048 px), the game should be able to handle it okay - something to do with inefficient memory usage if Unity has to pad additional pixels onto textures with non-powers-of-two dimensions prior to mipmap generation.

[NathanKell]

Yup. I _know_ Unity doesn't support NPOT textures (they're bumped to nearest (higher) power of 2), not sure if it also bumps non-square to square.

EDIT...after googling: unsure. Appear that maybe Unity seems to scale non-square to square too. So you might as well just use a 2048x2048. But it's not really clear.

Eagerly awaiting this!

Edited October 20, 2013 by NathanKell

[SkyHook]

I love the fact that you provide progress reports with regular frequency. It builds anticipation and keeps everyone in the loop. I have been following this thread for a while and love every update! Keep up to good work!

[lipatden]

Sumghai

I have a station with IACBMs all over that light up nicely, but my poor EVA Kerbal has no reference light for the airlock door... Any chance of an emissive there? A porch light adds the little dash of cosy...

While on that matter... I don't know if this is possible without a plugin, but any way to alter that to indicate whether there's space in the airlock for a Kerbal's ingress? e.g.:

- Green light; come on in (Airlock empty)

- Red light; Jeb's just in the shower getting the Mun dust off. Please stand by, your EVA is important to us...

[sumghai]

I have a station with IACBMs all over that light up nicely, but my poor EVA Kerbal has no reference light for the airlock door... Any chance of an emissive there? A porch light adds the little dash of cosy...

I have mixed feeling about this.

Personally, I would love to add some lights, which shouldn't be too difficult. But I'm also thinking the the space might be used by a ladder/porch attachment for a surface outpost. I'm not sure at this stage, really.

I suppose for now, we could just borrow the lights from the B9 Aerospace pack.

While on that matter... I don't know if this is possible without a plugin, but any way to alter that to indicate whether there's space in the airlock for a Kerbal's ingress? e.g.:

- Green light; come on in (Airlock empty)

- Red light; Jeb's just in the shower getting the Mun dust off. Please stand by, your EVA is important to us...

Actually, that'd be pretty neat. Definitely requires a plugin, though.

[sharpspoonful]

Couldn't it be as simple as if occupied=true then the red lights toggle? If false, then green lights toggle.

[sumghai]

Couldn't it be as simple as if occupied=true then the red lights toggle? If false, then green lights toggle.

I'm not sure if the KSP Plugins API has such a function - I'll probably look into it for R0.05a.

---

(A somewhat minor setback to) Progress Report, 22 October 2013

Practically all of the models have been retextured, with the exception of the Kupola shutters (which shouldn't take long anyway).

I'm currently in the middle of migrating from PartTools 0.18 to 0.20, and while there is a upgrade tool for that purpose, I've decided to recreate my Unity project / scenes from scratch - this is because when I first started modding for KSP, my assets were all haphazardly dumped in one big folder. It was until I realized I really enjoyed making and maintaining add-ons for the game that I found that my current setup wasn't efficient, especially when managing two or more different add-on projects.

So yeah, a bit of a delay, but it's better for me to deal with it carefully and properly now, than to leave it until I get involved in even more add-on projects.

[lipatden]

I have mixed feeling about this.

Personally, I would love to add some lights, which shouldn't be too difficult. But I'm also thinking the the space might be used by a ladder/porch attachment for a surface outpost.

There is an up axis to the airlock door, the light would likely go above the door to avoid collision prospects with a porch/ladder. The only thing the space above may be used for is an awning, which really only makes sense once tornados sprout on Minmus and the base turns into a genuine trailer park. At that point I'm off to a better neghourhood...

I suppose for now, we could just borrow the lights from the B9 Aerospace pack.

Appreciated this is always an option (though I don't have B9 installed and I doubt you'd want to duplicate B9 parts in your pack). I was hoping for a part-count-minimising solution, but in the grand scheme of things this is not a biggie.

[DerekL1963]

(A somewhat minor setback to) Progress Report, 22 October 2013

So yeah, a bit of a delay, but it's better for me to deal with it carefully and properly now, than to leave it until I get involved in even more add-on projects.

Better planning and organization is (IMO) not a setback.

[sharpspoonful]

I'm not sure if the KSP Plugins API has such a function - I'll probably look into it for R0.05a.

Neither do I but it seems like a simple andor statement.

[Bobhendly]

Man, I love how sumghai plots out his progress reports, they are EXTREMELY Neat!

When I start modding one day, I will plot my progress exactly like that!

[nothke]

The following, by the way, is what my revised "common" texture atlas currently looks like:

oh, I thought optimizing would be just merging all the parts' textures into a few common ones. But now as far as I can see, you actually made your plating plates modular in texture and mapping as well? And this actually makes adding new textures having to adjust to the dimensions of the plating that you made? Meaning that making something that needs variety like this would look very repeatable, in other words, impossible to make look good:

Also the other skin I made, the Kombobulus, relies on having screws positioned in different places on each plate, which your optimization would prevent from happening.

I agree that other stuff like doors and windows can be merged. But the actual "skin" (plating) should IMO be cylindrical warped cause it just gives so much possibilities for completely changing the looks of the modules, including allowing to paint something completely different (like maybe.. a coca cola can module =P)

- SQUAD does sometimes have non-square textures in their stock parts (such as the parachutes and docking ports), but my understanding is that as long as the dimensions are in powers of 2 (i.e. 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048 px), the game should be able to handle it okay - something to do with inefficient memory usage if Unity has to pad additional pixels onto textures with non-powers-of-two dimensions prior to mipmap generation.

I didn't notice that Unity stretched my 512x1024 textures to square in game (the pixel ratio still looks normal). But also in Unity, there is an option if you open the texture inspector, and make the texture type "advanced" and then "none" in "non power of 2". Now if that actually saves the memory I don't know.