[WIP][1.8.x] SSTULabs - Low Part Count Solutions (Orbiters, Landers, Lifters) - Dev Thread [11-18-18]

[RedParadize]

2 hours ago, Shadowmage said:

Yes, that plugin will work just fine for ground bases.  While it is called SSTUInflatable (for lack of a better name), all it really does is block of the playing of an animation until a certain number of resources are consumed.  As such it can work for... whatever

However it -cannot- disable a part entirely; your example part with the EPL launchpad would -still- have the launchpad capability while deflated/before construction.  Though it would have zero crew capacity.  In short -- that module controls an animation, and does not do any form of module-switching.

The only (stock compatible) way to do that would be to replace the part wholesale; rather than play an animation it would destroy the current part and create/insert the replacement part (where the replacement part has all the functional modules, the base pre-inflated part only has the inflatable module).  Would be hacky as hell, result in tons of extra parts in the editor and research tree...  not really anything I'm interested in implementing.

Thats more than good enough. When you say "that module controls an animation" I am asuming it will also handle model switching right? Because otherwise your big rigid centrifuge would need animation.

 

1 hour ago, Shadowmage said:

Made fairly significant progress on the UV unwrap and layout on the DOS parts over the last couple of days.

Have a -tiny- bit more texture space available that I can use for additional detail geometry, on the order of some ladder rungs/hand-holds, or other small geometry-based details.  Quite a bit of 'greeble' type details are going to be added through the textures (paneling lines, perhaps some wires or hoses and such); these are done at a reasonable-enough texture scale that I can get decent details in the normal and diffuse textures.

So -- last call on opinions/requests/desires for geometry based details on the DOS modules.  By Friday I expect that I'll have the models to a state where any additions will be prohibitive and will be very hesitant to make any geometry changes after that -- so if you have any requests, please put them forward now   (also please be specific/include examples, I'm really not very good at coming up with random greeble on my own... my mind merely doesn't work that way).

Current geometry with initial first-pass texturing (flat diffuse+AO only, very basic/unfinished normals on the radiators, no spec mask, no noise, and nothing finalized yet):
 

That looks realy nice! If you want critics the window are a tad big to my taste (they are bigger than the hatch!). The right one on the picture, does the blue thing on top are windows? I would advocate against such heresy, these are realy big for a spacecraft. If you realy want windows on these I would say 4 small circular window would look better and feel more realistic.  About the extra details, some external piping and random box/sphere/cylinder to simulate the russian messy design would be nice. specialy on the narrow section. Thats my presonal opinion, others might disagree.

Edited August 31, 2016 by RedParadize

[falken]

Yeah, I'd agree with Redparadize actually, the windows want to be smaller by at least half.

[tater]

2 hours ago, Shadowmage said:

LC stuff -- once again, I'm not touching any of those parts for a few months at least.  At which point it will be a complete re-do/reworking on all of those parts (pods, tanks, legs, accessories).

Yeah, sorry I mentioned it, but I was playing with the parts...

 

Quote

Texture swapping on other parts (CM/SM/Etc) -- possible, but would quickly result in a 500mb download.  Each extra texture set for those parts adds 3-5mb per part (they are not small textures); multiply that out by 3-4 parts per series, 4 series of parts, = 4*4*5 = 80mb per additional set of textures for the ShipCore parts.  If I added 3 texture options for each ShipCore part, you would have an additional ~250mb of textures.

I don't really have a problem with the download size... bandwidth is not as much of a problem as it was a decade ago.  Rather I'm worried about overall GPU memory use... it is a finite resource that must be shared with stock resources and all other mods.  I'm pretty sure KSP loads -all- textures into the GPU, and there is only limited GPU memory available.

If someone can provide verifiable proof that Unity is smart enough to dynamically upload textures to the GPU on a per-scene/as-needed basis (and thus the memory limit is per-scene, and not global), I would be much more willing to support further-reaching texture-swapping capabilities for other parts (still don't have time to make the textures... but at least I would be willing to if/when the time is found).

Yeah, that makes total sense. I didn't realize the crew part textures were so large. I don't really think the US parts need it at all, to be honest (unless mirror finished is an option  ). Maybe just a white option for the Soviet parts? In that way, mixing and matching when that happens would not look so busy.

Regarding the small Apollo SM... I guess I don't really see the need, as someone can easily make any SM from a functionality standpoint (not "replica" clearly) in SSTU. Use one of the upper stage tanks that includes RCS/APU, and there you go. Perhaps add a new mount type that provides a different appearance? The RCS requires a mount, I suppose. You could make a new mount that has no mount, and that moves the RCS up onto the tank?

The current plain tank (MFT-A) has a large jump from A-0-5 to A-1-0... adding a step in between that would cover the stubby SM. Another issue is the external pipe on those. Perhaps could one or another of the MFT tanks simply not have that external pipe detail? Then, if looks demand not using it, you use the other tank, even if it is a little less optimized (which doesn't matter much in stock, frankly).

The only thing missing would be the solar panels (you already added the antenna).

Pretty darn close, uses 10 parts... I'd lean towards fewer "unitasker" parts. If you wanted to make a generic SM part that could stretch, perhaps with an older style RCS block mounted on the tank vs the mounting ring setup on the existing upper stages that would make sense to me. If such a tank had a couple solar panels, that would be awesome (in the same 45 degree offset from the RCS). That would mean our replica would take 4 parts with a high gain (and would allow engine/propellant options).

 

Latest renders and greeble: Looking nice. I have to say I tend towards minimalism, because it makes the parts more generic in terms of non-replica use.

 

Edited August 31, 2016 by tater

[tater]

57 minutes ago, falken said:

On the subject of the stubby eyes turned skywards Apollo CSM, if you're reluctant to make a single use part that uses a texture like that, how about as a compromise another semi-procedural tank that doesn't have the piping on the side?

 

This popped up as I was typing... I agree completely.

[falken]

Of course, I realised now that there is infact tanks without the piping. The upper stage tanks.

[tater]

1 minute ago, falken said:

Of course, I realised now that there is infact tanks without the piping. The upper stage tanks.

They don't get as small, and they have the RCS, etc built in at the base.

You know what would be a really cool additional tank, actually? Something like MFT-D as a regular tank. Has the radial decoupling built in, but is just a plain cylinder with various nose/mount options that work for that part.

[Shadowmage]

16 minutes ago, tater said:

This popped up as I was typing... I agree completely.

As was discussed a couple days ago ( 

-- it would be a bad idea to implement those at this time.  The AO for the piping is baked into the texture; so for a set of tanks without piping it would require a completely new set of textures, which at this point is something like 130mb worth of textures.

I do want a no-piping tank (for a pure cryo-tank at least), however it is going to have to wait until at least KSP 1.2 to see if they include PBR support (so that I can use the AO as a separate overlay texture).  If PBR is not included with 1.2 I'll likely end up writing a custom shader/set of shaders to allow for separate AO maps.

What this will allow me to do is decouple the AO bakes from the diffuse textures, which should allow for more consistent texturing across tanks and adapters (as they can all use the same texture sheets) as well as an overall reduction in textures for many of the adapters and semi-procedural parts.

[tater]

11 minutes ago, Shadowmage said:

As was discussed a couple days ago ( 

-- it would be a bad idea to implement those at this time.  The AO for the piping is baked into the texture; so for a set of tanks without piping it would require a completely new set of textures, which at this point is something like 130mb worth of textures.

I do want a no-piping tank (for a pure cryo-tank at least), however it is going to have to wait until at least KSP 1.2 to see if they include PBR support (so that I can use the AO as a separate overlay texture).  If PBR is not included with 1.2 I'll likely end up writing a custom shader/set of shaders to allow for separate AO maps.

What this will allow me to do is decouple the AO bakes from the diffuse textures, which should allow for more consistent texturing across tanks and adapters (as they can all use the same texture sheets) as well as an overall reduction in textures for many of the adapters and semi-procedural parts.

I was thinking for an upper stage tank. Sorry if I was not clear (I might have switched gears, mid thought, my bad). Those already don't have the piping---of course the regular tank A-0-5 size tank doesn't have the piping anyway, it starts with the next size up. You can double the tank count and simply use 2 of those, and no pipes for an Apollo-like SM. Easy Peasy (SSTU is so incredibly flexible!)

Ie: MUS-CB, but with a "no mount" mount option, and the RCS blocks on the tank:

So a third upper stage tank, where the RCS is below where the fairing starts, and the bottom RCS is gone (and a non-beveled mount option).

 

Of course an Apollo replica is moot, anyway, as we have the real thing! I was more thinking for the Block V, but as I showed, that is entirely doable with SSTU as is, IMO.

[JoseEduardo]

2 hours ago, CobaltWolf said:

can you provide a source for that? I thought it was supposed to be an LMAE.

to be fair I don't even know what engine it is, I got the LM engine from your thread, I just forgot if it was the Ascent or Descent, I picked Descent because that made more sense since it's a bit more powerful than the AJ10-190 

truth be told, I never actually found a reference to their engine in their database, so I always assumed it was the AJ10-190 since it was the Shuttle OMS...

[CobaltWolf]

12 minutes ago, JoseEduardo said:

to be fair I don't even know what engine it is, I got the LM engine from your thread, I just forgot if it was the Ascent or Descent, I picked Descent because that made more sense since it's a bit more powerful than the AJ10-190 

truth be told, I never actually found a reference to their engine in their database, so I always assumed it was the AJ10-190 since it was the Shuttle OMS...

neither of the LEM engines were AJ10s. One was made by Bell, the ascent stage. The other was made by TRW, the descent stage.

For an OMS engine, the ascent stage is more than enough power, and is far simpler. The descent engine was fairly complex. I know they studied using the Ascent engine IRL - the Descent was actually used as the Delta P upper stage for two decades. They weren't looking for big power - another proposal simply added 4 more inline RCS thrusters to the bottom and only using RCS fuel, which gave a TWR closer to Gemini.

[Shadowmage]

2 hours ago, falken said:

[...]

On the subject of the stubby eyes turned skywards Apollo CSM, if you're reluctant to make a single use part that uses a texture like that, how about as a compromise another semi-procedural tank that doesn't have the piping on the side?

[...]

See the note below regarding 'Service Module Tank'.

 

1 hour ago, RedParadize said:

Thats more than good enough. When you say "that module controls an animation" I am asuming it will also handle model switching right? Because otherwise your big rigid centrifuge would need animation.

 

That looks realy nice! If you want critics the window are a tad big to my taste (they are bigger than the hatch!). The right one on the picture, does the blue thing on top are windows? I would advocate against such heresy, these are realy big for a spacecraft. If you realy want windows on these I would say 4 small circular window would look better and feel more realistic.  About the extra details, some external piping and random box/sphere/cylinder to simulate the russian messy design would be nice. specialy on the narrow section. Thats my presonal opinion, others might disagree.

Inflatable/construction module -- I believe it is possible to enable/disable specific meshes in a model through an animation; so no model-switching would be needed.  If this turns out to be not possible then I will add some sort of optional model switching to it (e.g. use the animation -or- model switching).

Windows -- see below.

 

1 hour ago, falken said:

Yeah, I'd agree with Redparadize actually, the windows want to be smaller by at least half.

Noted; will do some re-sizing on them and post some updated renders.  It was a bit of a nod to the cartoony kerbal style, but I've no problem making them a bit smaller/more realistic.

 

 

2 hours ago, tater said:

Latest renders and greeble: Looking nice. I have to say I tend towards minimalism, because it makes the parts more generic in terms of non-replica use.

I too would tend towards a bit more 'simple' model.  They are not, after all, intended as replicas.  Merely inspired by / designed in the fashion-of the real-world parts.

And... this is KSP.  If people really want a bunch of bits-n-bobs on the outside, they can easily add them in the editor

I'll try out a couple things though;  a few of those parts do have some rather large bare spots on them that could use -something-... I'm just not sure what that something should be.

 

32 minutes ago, tater said:

I was thinking for an upper stage tank. Sorry if I was not clear (I might have switched gears, mid thought, my bad). Those already don't have the piping---of course the regular tank A-0-5 size tank doesn't have the piping anyway, it starts with the next size up. You can double the tank count and simply use 2 of those, and no pipes for an Apollo-like SM. Easy Peasy (SSTU is so incredibly flexible!)

Ie: MUS-CB, but with a "no mount" mount option, and the RCS blocks on the tank:

 

So a third upper stage tank, where the RCS is below where the fairing starts, and the bottom RCS is gone (and a non-beveled mount option).

 

Of course an Apollo replica is moot, anyway, as we have the real thing! I was more thinking for the Block V, but as I showed, that is entirely doable with SSTU as is, IMO.

Service Module tank -- perhaps.  Would require some modifications to the MUS module code (or another new module) as currently the RCS models are positioned by the data in the mount definition.  For use as a service module you would need at least an adjustable vertical position for the RCS, as well as decoupling the positions/orientations from the mounts.

-IF- I do it, I would likely make two variants.  The first would include solar panels (maybe switchable/selectable, probably rescale with tank diameter), while the second variant would lack solar panels but come equipped with a fuel-cell.  Both would feature integrated RCS, configurable tank diameter and length, selectable mounts (top/bottom), configurable tank contents (VolumeContainer resource handling), and integrated lower fairings (basically the existing MFT tank functionality, using MUS textures/geometry, with integrated RCS, and possibly solar panels or fuel cell).  Would -not- feature integrated engines, as those only make sense on fixed-function parts (and engine-swapping isn't an option/extremely difficult for technical reasons).

Either way I won't be even looking at further this until KSP 1.2 (more specifically the PBR shader or custom shader) is available -and- all of the station-core parts are completed.  I've already got my hands plenty full with what I'm in the middle of.

 

On the note of 'MFT-0-5 is too short, MFT-1-0 is too long' -- you realize that there is a vertical scale slider that allows you to fine-tune the height of the tanks?  It was implemented to solve that exact problem.  I know it isn't as ideal as a specific tank-length model, but it should allow you to get the length you desire.

 

On the subject of tanks with integrated radial decouplers -- would be pretty easy to add those to the existing MFT tanks with a simple MM patch or config edit.  Nothing special is needed on the plugin end (it already handles repositioning the node).

 

[RedParadize]

I think there is several tank variant that could be implemented. Personally, I would like to see a variant that of the upper stage that have bottom mount and RCS on top as well. A customizable SM would be awesome too. But if I had to chose, I would rather have you continue with what you are doing right now. All these nice idea can be done with current stuff, it just require more part...

[tater]

Duh. I think I forgot about the vertical length slider. It's sort of like only learning you can click on orbital nodes and they stay highlighted---after playing for more than a year or two, lol. (should I admit that?)

@RedParadize is right, I didn't mean to spam requests. The part counts are so absurdly low once you stop using regular parts that Adding parts here or there is really no big deal. Heck, KSP has trained me so badly in terms of parts usage that I forget that I can simply connect the capsule than use SM decoupling...

Edited August 31, 2016 by tater

[RedParadize]

 

2 minutes ago, tater said:

@RedParadize is right, I didn't mean to spam requests.

I am guilty of that more than anyone else. Note that I still manage to sneak a request on my last post!

[tater]

Regarding feature requests... this thread is a little like hanging out in Santa's workshop, it's hard not to  .

BTW, if I had a realistic solar panels mod installed, that Apollo Block V I made would have looked pretty spot-on, I think (I loaded up my "pure SSTU" testing copy that I have with no other mods installed).

 

[tater]

Anyone joining this thread who hasn't tried SSTU... go up and look at the Apollo Block V image of what its supposed to look like.

Here's the stock version (13 parts):

SSTU (10 parts):

 

The two, together:

 

Any questions?

That's literally the first thing I've built with stock parts since a little after 1.1.3 came out. Wow, they are ugly.

Edited December 19, 2017 by tater

[falken]

Yeah, this is the first time I've not even bothered to install Ven's stock revamp. I just have no reason to use anything other than SSTU..

[Shadowmage]

Left = 50% scaled window

Center = 100% scale / as shown earlier

Right = 75% scaled window

50% is probably a bit more 'realistic', but I wouldn't really mind the 75% either.  Much smaller than 50% and I might as well not even put windows on it as they would be too small to see from reasonable distances, and would be difficult to see out/use of in an IVA.

Will probably go with the 50%, and will work on updating all of the models a bit later this evening with whatever is chosen.  Will also try out a few other greeble-y bits and see how they look / post some updated renders of potential geometry.

Edit:  After measuring the windows, 50% is 0.3m (~1ft), 75% is 0.45m (~1.5ft), and 100% is 0.6m (~2ft).  For current/historic spacecraft a 0.3m/1ft window is... still pretty big; for reference a scaled-down ISS-Cupola would have a main window size of 0.5m/20in.  I think the other points still stand (too small to see, hard to use in IVA), but from size alone I would consider going down to perhaps ~30% / 0.2m / 8in in size; still a decent sized window. 

Edited August 31, 2016 by Shadowmage

[tater]

Yeah, ven was a must have before... I just love the fact that the huge mass of parts I have to pick from is now all "good stuff" and not 4 versions of each tank diameter, all of which are ugly  . 

Regarding windows... I sorta like the 75% I suppose, but it doesn't matter much which size, and you're right on no smaller than 50%. IVAs only need huge windows because we are stuck viewing them from a seat, instead of getting closer to the window. 

I can't remember if it was mentioned up the thread, but will the general bodies of station core have texture choices? They clearly don't need many choices, even if the Russians tend towards more colorful spacecraft.

[Shadowmage]

20 minutes ago, tater said:

Yeah, ven was a must have before... I just love the fact that the huge mass of parts I have to pick from is now all "good stuff" and not 4 versions of each tank diameter, all of which are ugly  . 

Regarding windows... I sorta like the 75% I suppose, but it doesn't matter much which size, and you're right on no smaller than 50%. IVAs only need huge windows because we are stuck viewing them from a seat, instead of getting closer to the window. 

I can't remember if it was mentioned up the thread, but will the general bodies of station core have texture choices? They clearly don't need many choices, even if the Russians tend towards more colorful spacecraft.

See the edit above regarding the actual measured sizes.  50% probably is still the best compromise though for gameplay and usability concerns, and is what I will update the models to for the next release (as well as adding a very basic placeholder/shell IVA to see how that will work out).  We'll see how it looks from there, I can still do another model-update pass if needed.

 

Textures -- Yep.  Texture swapping is already built into the plugin for all main model bits (top, core, bottom), as can be seen with the top/bottom adapters.  The 'core texture' buttons merely don't show up as they don't have any textures yet

Initially I'll have (at least) two variants - a beige/cream colored cloth look in the vein of the Mir modules, and a grey/silver metallic texture closer to Tantares/Kosmos textures.  I kind of want to do a dark/black set as well, similar to a few of the Salyut renderings (perhaps black/green, or black/dk-gray).  A green/white set (cloth or metal) might also look decent, but I'm not set on it yet.  It is (currently) a 2048x texture which is quite large, so I would like to keep the number of sets to reasonable levels. 

That is a 2048x for all 6 parts at ~170px/meter, most of which is due to AO baking/shading requirements and unique UV mapping.  Still works out to less than 1024x per part while allowing for different detailing on most parts and for sharing UV areas everywhere possible.  If I were to do them individually they would still need at least a 1024x texture each in order to hit my texture-scale preferences (128px/m min, up to 256px/m preferred for crewed parts), and would actually end up with lower px/m from inability to do UV sharing.

Thankfully I think many of the other station parts will be a lot easier to keep smaller while still maintaining decent detail levels.  The COS parts will be very easy to share textures as they are simple cylinders and can all be mapped to shared spaces.  The HAB parts will mostly consist of repeating segments, with the occasional 'odd' segment (hab windows, torus arms), all of which can use UV sharing to various extents (okay, so the 50m torus will probably still need a big texture... but its a -very- big part).

[StickyScissors]

Space Station Vucari, my latest attempt at building something using a majority of SSTU parts that at least slightly resembles a space dock in...space. Big fuel storage tank in the middle filled with nearly 78k units of LF for the refueling of my Alkaid Reusable Nuclear Shuttle.

So far, its turning out OK, but there are still some things that SSTU just can't do yet, and that is these big hexagonal truss assemblies, like the ones around EJ_SA's ships:

Another thing that would be convenient is small 1.25m crew tubes with swapable docking ports on either end, which can help people not need to pretend that empty structural fuel tanks are crew usable.

-

Below, there is another shot of Vucari's business end. This is where , when i get my serious save started and the station built, fuel probes launched from kerbin from time to time will ddock and dump fuel into the station.

Later on, when i get a mining setup going, i'll be using the RNS's to bring back fuel mined from the Mun or Minmus. They can haul a lot more fuel than they use, so i don't have to worry about breaking even or not making a "profit" from it

-

And now, for part count stats, with and without the RNS's and crew vehicles.

Firstly, all up: 108 parts. Each RNS is 35 parts, each crew vehicle 10, and the station makes up for the last 18 parts (a new record low for my stations).

This already really low part station on it's own could be brought down to...counting intensifies...4 parts if a few things are able to be done/shadow want to bother (not including docked ships and the like, just the bare station):

-Allow the solar panels to be either welded to an existing truss segment, or come with swapable ones. This would bring each set of 3-part solar trusses on this station down to 2: the solar panel and truss as one part, and the docking part as another.

-The 1.25 crew tube with swapable ports on either end is made, which could also potentially save parts by having one of those colorful multi-ports swapable on the ends (which, IIRC, is''nt possible?)

-Each one of the colorful multi-ports already on the station could be welded to each other (which seems way too complicated/impossible). For example: Dock something to the red port, weld them together, dock something else to the green port, weld that together, etc.

-Modular fuel tanks have the option of having integrated/swapable docking ports at either end of them. This would bring 3 parts down to one n this situation.

To get to 4 parts, assuming all the things i listed are cable of co-existing peacefully, all the crew tubes/parts/pods(including a new 1.25m crew tube), and by extension the docking ports that attach the panels are welded into one big part, fuel tanks gets integrated docking ports, and the solar panels and trusses get welded to each other/integrated like mentioned,

This may be very far reaching or downright impossible from the get-go, but i can't halt my rampant imagination and armchair coding/engineering. i feel like i have some sort of condition or something O_o This also may well be gibberish or hard to understand. I will clarify if need to the best of my abilities

Edited September 1, 2016 by StickyScissors

[tater]

The colored docking ports... Obviously they could be a normal docking port texture, but with a color on part of each one to ID them. Would colored lights be possible as port ID? Just trying to think of something visually distinct, that's not too jarring.

[Pappystein]

9 hours ago, Shadowmage said:

Thanks for the info;  I took a look at the logs and did not see any null-refs that would have caused any problems, or anything else worrisome.

I'll take some time a bit later this week to do more testing on the docking ports.

One thing that would help would be craft files that are known to have the problem.  Do you have any stock+SSTU craft that exhibit the issue?  (mostly asking as my previous attempts to duplicate this issue with self-built craft did not exhibit any problems.)

 

 

I will have to sub in a different Separator instead of the SpaceY one I am using to launch the Pyrios boosters away and I have one CFG from my personal DB I can send you (Sea Level rated J-2s for the Saturn II.)  But yea, every other part is either stock or SSTU (I think.)

 

I will send the above tonight or tomorrow night (lots of overtime this week.)   But before you dive further into testing let me do a Clean install of KSP with the current mods and see if I still have the issue (72 hours or less I HOPE.)  It will give some indication if the issue is in a mod or was a file krakken like happened all the time in .23.

 

[RedParadize]

Windowes: 50% and 75% looks fine for me. can we go for 66% ? If you are already past that point ignore this message.

Colors: White would be nice too. Since we can't have a true metalic shader for now it would be a decent alternative. 

I am curious to see your big centrifuge design. I think I made it clear already but I think that for the biggest and most advanced centrifuge, it would be great to diverge slightly into the sy-fy relm. It kinda make sence since nothing of that size ever have been designed outside of sy-fy...

[tater]

I like the "near future" SF aspect of the centrifuges. I think the large ones should still look near future though, not Star Trek.