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

[Jimbodiah]

@tater

The best option for the new lander cans would be to remove the port or have the option to switch port size or even disable it. This would allow you to chose the size to match the CM you are using, or even use third party ports; I know José and some others are fans of the APAS ports and he has made portless versions in his expansion pack for every CM and LC. 

[tater]

Only the SRBS and fairing are shiny in this case.

 

[Shadowmage]

16 minutes ago, tater said:

I think he means they don't visually work together.

I know that the HUB parts are the only ones left with docking, is it possible not to have the ports switch on/off, but to have all the ports, but of either size, or do those need to be unique parts?

Swapping of port sizes/models is far more doable than the 'optional' ports.  Still not anywhere close to easy, but no huge technical problems that would prevent it.  Not really something I want to dig into in the near term either though; already have enough planned out.

However... I'm not sure I would be able to add that functionality to the existing HUB parts -- their geometry is setup specially for 1.25m ports (the HUB-COS doesn't even have a mesh behind the docking ports...there is nothing for a smaller port to sit on; it would be floating).  Nor does it solve the problems that would exist with the DOS parts -- what if you want a docking port at one end, but not the other?

Might be a thought for the future.  Certainly something to consider adding as an option where it might be supported (SC+LC pods?).  One possible solution to some of the geometry-incompatibilities with the small port might be to include a conic adapter on the back of the small port when it is used in the places.

[tater]

It's not like it's difficult to make a smaller port hub with a COS or other part, and as many docking ports as needed.

I mean for the player, if that wasn't clear!

Edited November 14, 2017 by tater

[Jimbodiah]

54 minutes ago, Shadowmage said:

Swapping of port sizes/models is far more doable than the 'optional' ports.  Still not anywhere close to easy, but no huge technical problems that would prevent it.  Not really something I want to dig into in the near term either though; already have enough planned out.

...

Might be a thought for the future.  Certainly something to consider adding as an option where it might be supported (SC+LC pods?).  One possible solution to some of the geometry-incompatibilities with the small port might be to include a conic adapter on the back of the small port when it is used in the places.

What you can do right now is use an MFT-A, surface attach it in symmetry mode, rotate the part to that is forms a truss sticking out and set it as structural. That way you can fit any port you want and not have it look weird.

Shown here on a BDB part, but you get the gist.

The integrated ports have no value to me as I often also use 3rd party ports and need to make my own hub anyway. Maybe the LC pods should just have no ports and just use the adapter you propose on the small port. Best of both worlds; and yeah one more part, but the flexability outweighs that and don't know how much time you need to spend to integrate it somehow. Maybe just a temporary solution to remove it before the big overhaul and see what happens?

 

 

And another shiny... This time a serious build (no kindergarten crayon colors) in the form of my end-game tourist lander.

Edited November 14, 2017 by Jimbodiah

[Temeter]

It's actually quite tricky to get exactly the right amount of metally reflection. I guess the constant, clear, blue sky in KSP (even SVE) makes everything look a lot more brighter than usual.

Well, it's also fun to make something over the top, like this gilded mun lander. This is one is btw real size, not an eeloo lander that somehow got lost and ended up on the mun.^^

As a sidenote, 2 of those 45 degree RCS packs are enough for 100% control. No need for quad-symmetry.

Edited November 14, 2017 by Temeter

[Shadowmage]

For the first time ever, I've ran out of 'likes' for the day....

(you all have impressed me with your designs and use of the new features; well done )

[Temeter]

See my signature

[Shadowmage]

1 hour ago, tater said:

It's not like it's difficult to make a smaller port hub with a COS or other part, and as many docking ports as needed.

I mean for the player, if that wasn't clear!

As I'm already intending on adding mesh-switch capability to the docking ports (well, the 1.25m)... it wouldn't be too much more effort to add in multiple back-plate mesh switch options, and also include them on the 0.625m ports.  Few other parts that could likely benefit from similar (e.g. the upcoming modular-rcs rework), though I'll leave those open for discussion/further concept development.

 

57 minutes ago, Jimbodiah said:

The integrated ports have no value to me as I often also use 3rd party ports and need to make my own hub anyway. Maybe the LC pods should just have no ports and just use the adapter you propose on the small port. Best of both worlds; and yeah one more part, but the flexability outweighs that and don't know how much time you need to spend to integrate it somehow.

I've been putting a bit of thought into the parts with integrated docking ports, and have been coming to much the same conclusion.  The ~1 part that is saved is in some cases not worth the loss of configuration ability.

Might be something that gets changed on future pod/crewed parts (and slowly over time changed on existing parts) -- certainly it still makes sense to integrate the RCS, parachutes, and heat-shields, but the docking docking ports (and engines), are something that needs to be able to be swapped around for different uses (and/or omitted entirely for some uses).

When combined with the docking-port backplate mesh-switching, the two changes together should actually result in a net increase in use options for the parts that currently have integrated docking ports (though of course with a resultant trade-off of slightly increased part-count).

[Jimbodiah]

It's a compromise either way, but ever since x64 came out the few extra parts are no longer an issue IMO.

Integrated rcs, chutes, solar panels is great and I'd love to see them stay that way. The RCS is not really in the way of anything and you can disable them. The solar panels can be removed through the GUI in most cases and chutes just not deployed. The only part that gets in the way of 3rd party parts or just personal preference (other size or no port at all) are the docking ports.

 

NB: I am playing with the metallic and specular sliders and noticed if you enter the values manually you can go beyond 255 to get a really shiny effect with only the specular option while keeping the colors brighter outside the VAB. With a value of 300-500 it has a mirror like finish, not the same as the metallic option though. Above 500 nothing seems to change anymore (512 limit?). I can actually see the VAB reflected in the part at 400+ (metallic at 0, non-pbr).

LOL, nevermind. Optical illusion.

Edited November 14, 2017 by Jimbodiah

[Sudragon]

3 hours ago, Jimbodiah said:

@Sudragon  Are you sure they don't dock? In the past I have used the LC2 for my Saturn V replica and it worked just fine. Maybe something was changed in the last few patches; I've not tried it for a while to be honest.

just tried it. lots of RCS activity, no satisfying clunk-fshhhh. I remember one of @JoseEduardo's mod kits supplied a LC set without docking ports.

[tater]

I've not had a docking problem in ages. A LC2, and an Apollo?

 

[Jimbodiah]

I'll check on my install...  José uses the APAS ports (Cx Aerospace), so he did indeed make all the CMs and LCs without ports so as to fit the APAS ones.

 

 

Specular set to 200 for all parts. Metallic is 250/200/150/100/50 from left to right.

 

 

 

Specualr set to 250 which gives maximum reflections in the VAB but means they are darker in space (nothing to reflect). Metallic is 250/200/150/100/50 again from L to R.

 

Same stack as above but as seen in the VAB

 

Conclusion: What looks awesome in the VAB will look bad in space as there is nothing to reflect like in the VAB, plus the VAB has omni directional lighting while space has a point source. You can't have your cake and eat it too. :-D

 

Planet-shine could actually enhance this by offering light from a closer and larger source perhaps...

Edited November 14, 2017 by Jimbodiah

[Temeter]

Yeah, I had the same issue with metal colors, where stuff in the VAB looked quite different under the sky.

I wonder, does the VAB removal mod also work with reflections?

[tater]

Tested just now on laptop. Works fine.

LC2 pod and Apollo CSM.

16 minutes ago, Sudragon said:

just tried it. lots of RCS activity, no satisfying clunk-fshhhh. I remember one of @JoseEduardo's mod kits supplied a LC set without docking ports.

 

[Jimbodiah]

Re that LC2... I have reduced the reaction wheel force to half of the stock one to not have it wobble all the time (sas too powerful).

 

NB: I tried PlanetShine, but it doesn't help. You can see the earth reflected in the parts, but everything else is black (no color). What I am noticing is that the sun is not reflected at all, unlike the planets. Could that an issue, Mage?

Metallic is at 100 for all these parts... Specular set to 50/100/150/200/250 from L to R... As you can see the sun no longer reflects at 150 or 250.  ±200 seems to be a sweetspot for being able to see the sun glare. At specular 250 you can see the earth start to reflect, but the color gets darker in space (yet very reflective in the VAB).

On the capsule I have 220 specular and 100 metallic, which seems to be my compromise to have color and some reflections.

 

Maybe the PBR version will offer improvements when recoloring becomes available?

 

 

 

And a parting shot as I go play the game for a change      I'll rework my personal color settings for those interested, if I can find the new presets file

Edited November 14, 2017 by Jimbodiah

[Temeter]

[Jimbodiah]

Chrome airplanes are pretty viable now 

[Shadowmage]

Hmm... since I'm working on converting the ISS / BKT solar panels this week (to use a back-lit PBR shader setup)...

Should I also convert the DOS panels to have a back-lit function on them as well?

The new PBR back-lit shader is working already (both a metallic and specular version of it for testing).  Will require some adjustments to the textures, and there is simply no way for me to get the exact same visuals as the legacy shaders (black panels w/ colored reflections), but the new setup should likely be even more authentic looking.

Other plans for this week are to finish up the new stand-alone ModularHeatShield geometry (and textures), and finish up the implementation of the reworked model-switch (for LC-POD optional fuel tanks, upcoming docking-port backplates).  Eventually this stand-alone heat shield model will be used in place of the meshes on the SC pods -- recolorable and/or high-res heat shields all around (eventually).  If I run into extra time this week I'm going to start laying out the geometry for the static-modeled decouplers and probe cores (non-procedural models, but with model/texture switching, and basic scaling support). 

In the slightly more long-term plans, @tater posted up some documents on an aero-shell-based Mars descent vehicle that I think would be quite adaptable to being turned into a part-series (the Horizontal Lander series).  Solves the 'aeroshell problem' because the parts -are- the aeroshell (rather it is not discarded).  This means that I can make an engine section with proper openings for the nozzles, and not have to worry about procedural meshes or stock aero weirdness.  (this might be one of two horizontal lander part series designs; the other would be more intended for vacuum use).  From my 'official' plans, the Horizontal Landers are up next, so probably about time to start laying out the concept work on them.  Alternatively, depending on feedback/desires, I might be willing to place the LC-POD and LC-LEG reworks ahead of the horizontal lander parts -- as these are already (mostly) planned out stuff, it would be far less concept work, and more just modeling/texturing work (and depending on how they are done, might tie in very well with the horizontal landers).

 

Over the last few days I learned some tricks in Substance Painter that let me use it to author the recoloring masks and noise textures.  Good stuff, as it means an even more unified workflow, and faster texture creation (put together the recoloring textures for the MFT-LV tanks in mere minutes; as opposed to an hour or two when using GIMP and manually making the masks from the UV maps).  Less time spent on the basic recoloring versions, and more time to spend on making better models and on the high-res PBR textures.

The upcoming ModularHeatShield part will be my first attempt at using the SP workflow from start to finish, including lots of use of baking from a high-poly model.  So far it has all gone fairly well; some oddities with NRM baking, but I understand the technical 'why' of it, and height-map/displacement baking still works well.  Between the two, I'm sure I can find a working setup to bake out the details form a high-poly model.  Even just being able to bake positional data for detailing work can make the job so much easier (e.g. the RCS ports on the SC-B-CM were baked from proxy meshes placed over the existing model; gave very precise results).

What this all means is that the modeling and texturing process has become quite a bit easier and smoother (and continuing to become moreso as I learn and adapt).  Which means more models, more detailed models, and certainly more detailed textures (esp. the high-res PBR ones).

 

I've also pretty much settled on a 'low-res recolorable + high-res PBR' setup for future parts.  What will likely happen is the parts are modeled and given the low-res recolorable setup initially, with the high-res PBR textures coming a few days/weeks later (good textures still take a lot of time).  This should likely result in a decrease in the base distribution size (as most of the recoloring diff/spec textures can be reduced in resolution; 1/2 the size = 1/4 the memory) with minimal loss in visual quality (the recoloring textures only add the noise/gradients that can be seen, and most would not notice being reduced to half resolution).  NRM maps might be the exception, and some of those might actually see an increase in resolution, even for the base recoloring texture sets.

Many parts will -only- have the recoloring textures.  Compare, for example, on the new MFT-LV tanks -- the PBR-recoloring 'gold' foil texture is for most purposes, just as good looking as the high-res PBR gold foil texture (the notable differences are on the painted areas where there is edge wear on the high-res version).  So for most basic parts they will have re-colorable texture sets only.  The regular-res (and high-res-PBR) textures will be saved for more detailed parts -- crewed parts, engines mostly.

 

[Jimbodiah]

Just now, Shadowmage said:

Should I also convert the DOS panels to have a back-lit function on them as well?

Do you even need to ask? 

[Shadowmage]

1 hour ago, Jimbodiah said:

Conclusion: What looks awesome in the VAB will look bad in space as there is nothing to reflect like in the VAB, plus the VAB has omni directional lighting while space has a point source. You can't have your cake and eat it too. :-D

 

Planet-shine could actually enhance this by offering light from a closer and larger source perhaps...

Pretty much spot on -- there is not much to reflect in space (being mostly empty), so metals will almost always look darker than non-metals.  While this can give quite stunning visuals under certain uses (e.g. the Apollo CM in orbit of the Moon), they will be far less stunning in other situations (the same CM will appear very dark/black when on the dark-side of an orbit).

Planet-shine -- not sure how it would be able to improve things -- the parts are already picking up colored lighting/reflections from the environment (even light-sources).  Does it increase the light from the sun and/or add light-emitters to the actual planets?

4 minutes ago, Jimbodiah said:

Chrome airplanes are pretty viable now

Hmm... with my new SP workflow... I wonder how long it would take to rip all of the stock spaceplane related models and create recolorable texture sets for them?  (probably longer than I want to spend given the plain-ness of most of the stock models)  The stock spaceplane parts might actually be good candidates for the 'stock-conversion' shader given their better-than-normal-stock texturing.  Add in a proper MET / GLOSS map, and they could probably look very nice.

But recolorable Mk2 fuselages?  Could be yummy...  (hint:  I'm more than willing to help someone else out with the project if they wanted to work on it)

 

[Shadowmage]

One more... question... while I'm on the subject of PBR/textures/heat-shields.

I have the opportunity to make the Heat Shields far more... realistic?... than they currently are (and restoring some of the 'features' that the stock HS has rough implementations of).

• Emissive-texture based glow effect, rather than whole-mesh glow.  Could represent that some parts of the HS get hotter (edges in paneling, some 'cells' get hotter, etc).  Could possibly even tie this in with some sort of orientation/geometry inputs so that the more forward facing side appears to heat up more than the leeward side.
• Secondary material / wear effect as ablator is depleted (or heat-absorbed for heat-soak thermal tiles, e.g. shuttle).  A HS that has gone through the entry will look vastly different than a brand-new one.  This could be done by texture blending and/or material layering.

None of this needs to be done immediately as it wouldn't really influence how the base textures or model are setup, but is certainly something that I'm going to consider for long-term heat-shield related plans.

1 hour ago, Jimbodiah said:

Maybe the PBR version will offer improvements when recoloring becomes available?

You are using the PBR recoloring setup already.  That is what makes the metallic stuff available and allows for the reflections to work at all.  It is not really going to improve beyond what is already there.

Mostly I think its just going to take some adjustment for our eyes (and brains) to get used to the more realistic lighting, and the fact that not everything is fully lit when in the blackness of space.  (I personally enjoy it already)

[RedParadize]

@Shadowmage That sound fantastic!

 

[Shadowmage]

1 hour ago, Jimbodiah said:

What I am noticing is that the sun is not reflected at all, unlike the planets.

It is reflected just as it exists in scaled space (which is a small yellow sphere).  What is not present in the reflections is the sun-flare / corona.  However most of that is accomodated for by the actual light produced by the sun.

Edit:  Although, thinking on it, this lack of corona/sunflare rendering would be quite visible on highly reflective surfaces (specular=>240), and might make them appear darker than they should when reflecting the sun (it wouldn't help the unlit portions though).

Edited November 14, 2017 by Shadowmage

[Jimbodiah]

What's the difference with the PBR setting on the apollo CM vs the metallic (behind the scenes)?

You can actually use the mft-a as the fuselage. I wasn't suggesting you make the parts, Mage. Imagine this effect on the OPT space plane parts @K.Yeon

 

Check the last comparisson I added; it shows the sun reflection is optimal around 200 on the specular and disappears below and above that.

Edited November 14, 2017 by Jimbodiah