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

[tater]

I'll try and do more welding tests for you. I tested them a couple times, and haven't really pushed the use.

[RedParadize]

1 hour ago, tater said:

I'll try and do more welding tests for you. I tested them a couple times, and haven't really pushed the use.

Yeah same here. But so far so good. I have found some use for these.

Oh, and the update on the SSTUAirstreamShield work perfectly. Its now superior to stock in every aspect!

Edit:

I forgot to say, the handrails on ISS hab look good, the lower profile is perfect. The first draft on the texture looks promising. However the real stuff is saturated with small details, without them we will lose the sense of scale, (Think about the Star wars imperial stardestroyer, if it was slick it would look realy small, like some ship in SW 1-2-3). I believe that most of it could be done trough texturing, panel fixture, textile section, the black and white dots that they use for tracking, at least to a point where there is enough details to saturate our vision. That way we won't even see what these details truly are and if stuff is missing.

Edited September 12, 2016 by RedParadize

[tater]

I'm thinking we need a Be-4 engine...

Could use it for Vulcan... or other things:

[Shadowmage]

Bit more thought / work on the custom shader setup.

I'm trying to find a way to be able to load models directly into KSP with the custom shader.  The closest I've been able to come up with so far is to add a custom PartModule to the specific parts that need the shader, so that the shader can be swapped during prefab creation.  My next thought was to keep a list of parts that should have the shader replaced and use a generic KSPAddon to replace the shaders in just those parts after the database was loaded; this unfortunately requires keeping a config-list of parts.  My last idea was to export the parts with the custom shader (so it is read in the .mu file), and go through -every single model- after models are loaded and replace the bad shader references with a proper one;  quite hacky and likely would take a few seconds to go through all those models/transforms/renderers.

I noticed that GameDatabase has a list of shaders (the same way it keeps a list of models).  But.. as near as I can tell the stock mu-model loading code doesn't look there for shaders when it is constructing models.  I'm tempted to bug a dev to see if they can also search that shader list when compiling models from .mu files so that custom shaders might be supported through the .mu model format.  I suppose the question is should I just file a bug report, or bug a dev directly?  Never really sure when it comes to features only used by mods/API-quality-of-life improvements.

The other bit that really needs cleaned up is the KSP asset bundle loading.  I put the shader in the bundle, flag it for 'auto-load', and... nothing?  I ended up loading my bundle manually through the Unity generic AssetBundle loading methods.  Seems like it is an API feature that was never fully implemented.  Sadly, the AssetBundles are loaded after the models anyway, so this wouldn't fix the shader being available when models are compiled.  Would still need to manually load the shader and insert it into the GameDatabase shaders list sometime prior to models loading (all assuming the above fix was in place and that .mu models searched the shader list for shaders).

Other shader-related discoveries:

Using a second UV set is trivial.  It literally consists of changing one of your sampler definitions from 'uv_texName' to 'uv2_texName'.  Now I need to decide if I need support for secondary UV's, and what exactly I would use them for. 

There are -lots- of different options for texture sampling setups.  Not quite sure which route I'm going to go (what channels in each texture).  Will be one of the things I'll be figuring out this week.

 

On the testing note -- as mucking about with Unity shaders is entirely new to me, these things are going to need a bit of testing to make sure that they work on other platforms / GLs.

[tater]

BTW, seeing the Soyuz gets me thinking, as I have built rather a lot of them lately in SSTU.

The core and conical boosters are pretty straightforward, using the soyuz adapter on the Nose of the core (set to 1.25m). The engine diameter is larger than 1.25m, but smaller than 1.875, though, and looks flush on the real thing. Ditto the adapter, which is in between diameters. 

 

Edited September 12, 2016 by tater

[RedParadize]

I upscaled my SSTU soyuz to 1.875, I think it look better that way. The upper stage and fairing is 2.5 in my build. For 6.4x or bigger it is not thinkable to have some thing below that size and still manage to get +5 tons in space. I think I also moved the upper stage maximum diameter to a earlier tech, I don't remember, I did that quite a while ago.

[Theysen]

39 minutes ago, tater said:

BTW, seeing the Soyuz gets me thinking, as I have built rather a lot of them lately in SSTU.

The core and conical boosters are pretty straightforward, using the soyuz adapter on the Nose of the core (set to 1.25m). The engine diameter is larger than 1.25m, but smaller than 1.875, though, and looks flush on the real thing. Ditto the adapter, which is in between diameters. 

 

 

10 minutes ago, RedParadize said:

I upscaled my SSTU soyuz to 1.875, I think it look better that way. The upper stage and fairing is 2.5 in my build. For 6.4x or bigger it is not thinkable to have some thing below that size and still manage to get +5 tons in space. I think I also moved the upper stage maximum diameter to a earlier tech, I don't remember, I did that quite a while ago.

 

Hm, every other Soyuz mod for stock KSP is at the 1.875m diameter scale and coming very close to the 2.66m real life diameter times 0.64 factor. For SSTU it's the preset for 1.4735m for diameter and all engines are set to that as well.

So I don't really see where you think that is the issue @tater ? Might be on my end not understanding what you mean with flush, all SSTU parts are perfectly matching.

[tater]

The core stage (center, first stage) needs to be 1.25m, which makes the adapter at the top a little smaller than the 1.875m size that I have all the upper stages set to. This is clear in the image above where what is called the soyuz adapter in SSTU ups the size to the next stage.

Clearly all the upper stages are the same size as the orbital vehicle with side panels and LES on top, right? That's 1.875m. That then necks DOWN to the engines at the bottom of the core. In the real image I posted you can see that the core steps up in size to what would be 1.875 in KSP. Regardless the orange engine mount in SSTU (forgot the mount name, sorry) is neither 1.25 m, OR 1.875m.

The green tank above is 1.25m. In the real image of an R-7 above, you can see that the orange and green are basically flush. If the green tank is set to 1.875m, the orange/yellow engine part is much smaller than the tank, and the soyuz adapter on top is much larger than 1.875m.

The soyuz adapter on the top of my 1.25m tank:

You can see that the 1.875m decoupler is larger than the adapter. It is not 1.25m, however, it is only a little smaller than 1.875m. If you scale the tank to 1.875, the adapter on top is much bigger than the upper stages, which is also not right. All the upper stages need to be 1.875m, as they are all the same diameter on Soyuz. The core must be 1.25m, IMO, or you're building something else.

 

 

On the solar panels... I had not commented on textures, as they were all unfinished parts, but the white between the black panels looks odd on my computer. It might just be me, and the setting I have it set to, though I tried at full res textures and everything else maxed out, and it still looks jarring to me. Up close, they look awesome, but at a more "usual" viewing range... it's hard to describe, it has a jarring optical illusion sort of look. They look fine on the white background as Shadowmage posted them up the thread, bit in orbit, lit in game... they look weird at certain distances. The same of the cross pattern on the station parts. I'll take a screenshot tonight and post what I mean (and again, maybe it's just my meh graphics).

You can see in the upper stage image (real) that the entire thing needs to be 1.875m in kip (spot on in SSTU). The Soyuz adapter then must be set at the nose of a 1.25m tank. The engine mount is slightly larger than 1.25m, and the soyuz adapter on a 1.25m tank is slightly smaller than 1.875m. Seems like the engine mount (yellow/orange color) needs to be closer to 1.25m, and the adapter on a 1.25m tank need to be slightly larger...

Unless I am doing something grossly wrong.

Edited September 12, 2016 by tater

[JoseEduardo]

16 minutes ago, tater said:

Unless I am doing something grossly wrong.

yep:

41 minutes ago, Theysen said:

Hm, every other Soyuz mod for stock KSP is at the 1.875m diameter scale and coming very close to the 2.66m real life diameter times 0.64 factor. For SSTU it's the preset for 1.4735m for diameter and all engines are set to that as well.

except that IIRC that value is only for the core tank, at that diameter the top of the core should have a 1.875m diameter if you're using the soyuz nose cap

I don't remember if that is true for the boosters though... they could possibly be at 1.875m already

[tater]

But there is no 1.4735m tank, is there? The rest of the Soyuz upper stage parts are 1.875m... my white/green 1.875m tank on the next stage engines shown is perfectly flush with the SSTU soyuz orbiter parts and LES.

Edited September 12, 2016 by tater

[Theysen]

@tater,

 

Okay then I think we have different mods?

When you set the tank adapter to Soyuz and the diameter to 1.4375 everything is set to  correct scale. I cannot follow your reproduction steps unfortunately and thus cannot see why the engine mount needs to be 1.25m.

 

Assemble it like this and everything is fine, Soyuz is oddly shaped in real life.

http://imgur.com/a/qtNGq

 

2 minutes ago, tater said:

But there is no 1.4735m tank, is there?

 

It's a mouse click inside of the diameter field, but it snaps to 1.4375m.

 

 

 

 

Edited September 12, 2016 by Theysen

[tater]

I'm not using another mod.

MFT-A tank. How can you possibly get it to a diameter of neither 1.25m or 1.875m?

OMG, you can click inside the field...

 

 

[Theysen]

3 minutes ago, tater said:

I'm not using another mod.

MFT-A tank. How can you possibly get it to a diameter of neither 1.25m or 1.875m?

 

As I said, click inside the Diameter field, not on the arrows. At about 1/4 of the bar when you're on diameter of 1.25 it snaps to 1.4375m.

Edited September 12, 2016 by Theysen

[Shadowmage]

3 minutes ago, tater said:

The core stage (center, first stage) needs to be 1.25m, which makes the adapter at the top a little smaller than the 1.875m size that I have all the upper stages set to. This is clear in the image above where what is called the soyuz adapter in SSTU ups the size to the next stage.

Clearly all the upper stages are the same size as the orbital vehicle with side panels and LES on top, right? That's 1.875m. That then necks DOWN to the engines at the bottom of the core. In the real image I posted you can see that the core steps up in size to what would be 1.875 in KSP. Regardless the orange engine mount in SSTU (forgot the mount name, sorry) is neither 1.25 m, OR 1.875m.

The green tank above is 1.25m. In the real image of an R-7 above, you can see that the orange and green are basically flush. If the green tank is set to 1.875m, the orange/yellow engine part is much smaller than the tank, and the soyuz adapter on top is much larger than 1.875m.

 

The soyuz adapter on the top of my 1.25m tank:

 

You can see that the 1.875m decoupler is larger than the adapter. It is not 1.25m, however, it is only a little smaller than 1.875m. If you scale the tank to 1.875, the adapter on top is much bigger than the upper stages, which is also not right. All the upper stages need to be 1.875m, as they are all the same diameter on Soyuz. The core must be 1.25m, IMO, or you're building something else.

 

 

On the solar panels... I had not commented on textures, as they were all unfinished parts, but the white between the black panels looks odd on my computer. It might just be me, and the setting I have it set to, though I tried at full res textures and everything else maxed out, and it still looks jarring to me. Up close, they look awesome, but at a more "usual" viewing range... it's hard to describe, it has a jarring optical illusion sort of look. They look fine on the white background as Shadowmage posted them up the thread, bit in orbit, lit in game... they look weird at certain distances. The same of the cross pattern on the station parts. I'll take a screenshot tonight and post what I mean (and again, maybe it's just my meh graphics).

 

"You are doing it wrong" (tm).

The Soyuz CORE stage fuel tank should be 1.4375m diameter, the same as the RD-108 engine mount; at that size the tank is flush with the mount.  Then, with the soyuz adapter on top, it makes the top diameter of the tank end up at 1.875m and it lines up perfectly with the spacecraft/1.875m upper stage.  The radial boosters should be 1.875m as well.

There is a reason I put in all of those diameter adjustment sliders   Yes, I realize that 1.4375 is a bit of an odd size... but blame the Russians.  It was either 1.4375m core + 1.875m boosters and pod, or 1.875m core w/ 2.5m boosters and pod; I chose the smaller/odd sized one as it was much closer to the proper scale and still capable of being done with the diameter-adjustment sliders.

 

Solar panels -- yep, that is aliasing caused by the relatively small details on the panels (mostly the normals I think?).  Not much I can do about it if I want to retain the details.  Going to be upping the texture resolution on them already (from 512x to 1024x), which will help with some of the aliasing, but won't alleviate the aliasing between the high-contrast areas (the black panels vs. white structure).  May also see if removing the normal map entirely cleans up the aliasing.

I would agree -- they look great up close, but from further off they... well.. don't.  We'll see if the texture-size update fixes any of those problems.  Who knows, I may have to remove the normals from the panels.  Wouldn't look nearly as nice up close, but should help with the aliasing at distances.

 

 

3 hours ago, RedParadize said:

Yeah same here. But so far so good. I have found some use for these.

Oh, and the update on the SSTUAirstreamShield work perfectly. Its now superior to stock in every aspect!

Edit:

I forgot to say, the handrails on ISS hab look good, the lower profile is perfect. The first draft on the texture looks promising. However the real stuff is saturated with small details, without them we will lose the sense of scale, (Think about the Star wars imperial stardestroyer, if it was slick it would look realy small, like some ship in SW 1-2-3). I believe that most of it could be done trough texturing, panel fixture, textile section, the black and white dots that they use for tracking, at least to a point where there is enough details to saturate our vision. That way we won't even see what these details truly are and if stuff is missing.

Glad that fix for the shielding module is working out for you.

On the COS parts -- sadly I cannot really add any such detail due to how the textures are mapped.  Those parts are all mapped onto a single 512x texture with a TON of shared UVs (of which only half is used by the COS parts, the other half is used by the HUB-COS);  any details added to the texture would repeat themselves all over the part and look rather bad and tacky.  Nor am I really trying to make replicas.  I honestly think they look just fine as-is, and they conform to the level of detail to which I've done the rest of my parts.  In order to have textures capable of that level of detailing I would need a 2048x at least for those parts in order to use unique UV layout without mirroring/UV sharing.

[tater]

@Shadowmage, the UI there is not ideal, IMHO. The << >> arrows imply jumping to the next "official" size (1.25, 2.5, 3.75, 5, etc). The < and > imply jumping to the next available size, IMO. It never even occurred to me to click inside the field.

Cool feature, but I missed that it was even there.

The "tank" length doesn't use this same paradigm, for example, it has the explicit V.Scale thing. I assumed the diameters were the same, and since there was no D.Scale, they were fixed to limited jumps.

I feel like an idiot, lol.  

[RedParadize]

25 minutes ago, Shadowmage said:

On the COS parts -- sadly I cannot really add any such detail due to how the textures are mapped.  Those parts are all mapped onto a single 512x texture with a TON of shared UVs (of which only half is used by the COS parts, the other half is used by the HUB-COS);  any details added to the texture would repeat themselves all over the part and look rather bad and tacky.  Nor am I really trying to make replicas.  I honestly think they look just fine as-is, and they conform to the level of detail to which I've done the rest of my parts.  In order to have textures capable of that level of detailing I would need a 2048x at least for those parts in order to use unique UV layout without mirroring/UV sharing.

Ah ok. A agree that it doesn't need to be a replica. So the 512x texture cover something like a panel or two? Small bolting and panel details will do then. On the other end, the black dot on white sheet thing could be done in the same way flags and decal are done. A plane with a small texture and alpha. These target can be found all over ISS and I am sure that the same technique could be used for other details as well.

Its just a personal suggestion. Either way I like these part.

[Shadowmage]

31 minutes ago, RedParadize said:

Ah ok. A agree that it doesn't need to be a replica. So the 512x texture cover something like a panel or two? Small bolting and panel details will do then. On the other end, the black dot on white sheet thing could be done in the same way flags and decal are done. A plane with a small texture and alpha. These target can be found all over ISS and I am sure that the same technique could be used for other details as well.

Its just a personal suggestion. Either way I like these part.

On the COS texture, it is divided into 4 horizontal-spanning sections.  Each of those sections covers 4 'panels' going around the tank, mirrored and repeated 4 times around the tank to make the 16 panels going around the diameter.  Would need a 2048x texture in order to get the full diameter of the tank.  Even at that size the texture would only cover less than 1/2 of the length of the 'long' parts -- still not good enough coverage for the type of detailing you are looking for.

The upper strip of panels contains the AO bake for the top/bottom strip of handrails.  It is only used for the upper and bottom row of panels on each part.

The second strip of panels contains the AO bake for -all other sections- of the COS parts, and is repeated 2-8 times depending on the part.  This is the bit that would end up

The third and fourth strip of panels contain the AO bake for the HUB, HUB-extensions, and a bit is used for the handrail AO and coloring.

 

Decals -- yea, it could be done that way, but is 1.) Painful and slow as a workflow, requiring multiple materials and separate mesh objects.  2.) Looks terrible as the rendering setup is not intended for decal use; you need actual decal shaders for those, which KSP does not support (note how the decals on the HUB parts look... not so hot...but an unfortunate necessity for those parts).  As such I would prefer to only use decals where they are truly needed, such as the HUB parts for the port labeling (where -not- having labeling would be unacceptable).

If/when the Unity 5 Standard Shader is ever supported I can start using the new detail-texture workflow, which will allow for what you are suggesting without looking terrible (as decals are rendered as part of the albedo texture, at the same z-depth, so there is no z-fighting or false-shadows caused by them).

[RedParadize]

Can we just port KSP into unreal engine and forget about all these limitation?

Half serious here...

[Shadowmage]

While I'm making new cylindrical fuel tanks.... (the MFT-C models have been built and exported, working on configs now)...

Any interest in a pre-framed tank (all a single model)?  This would be a visual geometry change only, and wouldn't add any additional functionality, but is a bit more in-line with what NF/USI have modeled their cryo tanks after.  (Still doing a straight cylinder, no-piping tank (MFT-C); this would be a fourth cylinder-tank variant (MFT-CF))

Using the MCB-A geometry for testing (and may use it for the actual thing if I do it, with some modifications such as making it wrap around the other side).

[StickyScissors]

@Shadowmage Would it be easy to add a toggleable cylinder to the bottom of docking ports, to remove the need of using structural fuselages to move them away from tanks?

Radially mounting them now creates the problem of having them sunk in too far to look good an be usable, or they are far enough out to be usable, but the majority of it isn't touching the tank.

-

Edit: Also, here's a random screenshot from a test mission to Duna

 

Edited September 13, 2016 by StickyScissors

[RedParadize]

@StickyScissors Thats look like something I always wanted to create: A tank with RCS and docking port that also act like decoupler. I would realy like to be eable to assemble lateral booster in spaaaaace!

[Pappystein]

44 minutes ago, Shadowmage said:

 

Any interest in a pre-framed tank

Using the MCB-A geometry for testing (and may use it for the actual thing if I do it, with some modifications such as making it wrap around the other side).

I can see launching that inside a fairing to dock with a space station or Tinker Toy ship.

looks good!

[tater]

I like the look of "deep space" tanks.

 

[tater]

I was messing with a CSM to build a station, and decided to take it home after a while, though I left the crew in the station (I had a couple CSMs docked at that point, and needed the docking port). So I separated the SM. The empty CM was doing fine, and since it was sandbox, and I didn't care, I switched to the SM to watch it blow up. A very small 2.5m MFT A tank, and I used 2 of the new SM solar panels on it (like those Apollo Block V images up the thread, but with your cool new panels). Anyway, the panels were extended, and they survived reentry.

 

EDIT: OK, I welded a few things. So far, so good, they stuck together.

I made a ship that was a centrifuge welded to a medium lab that was attached to an Orion OM. So, Bridge->Lab->Habitat. I left a docking port at the back, because it was an experiment, and had an Apollo as a tug docked on the back. The Orion had a couple crew as well. Before docking, all was normal. After docking, everything was fine, except there was no way to IVA the Orion crew. (EDIT: the Orion CMX has no IVA, at all).

 

Edited September 13, 2016 by tater

[tater]

The Orion orbital module has no IVA set.

To reproduce: Launch SC-C-OMX with crew. No IVA.

Edited September 13, 2016 by tater