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

[Jimbodiah]

Well, Wildblue has some LCD panels in it's mod, we could use those and hook it up to VDS Hullcam :-D

btw: anyone else try the hullcam mod? It's great, let's you get those camera shots on the rocket like the spaceX launches 

 

Edited November 14, 2016 by Jimbodiah

[RedParadize]

1 hour ago, tater said:

It's dependent upon the rotation rate, I imagine. I suppose you could put a camera near the torus, and pipe in fixed video in real time to LCD "windows" pointing in the direction that the came is facing., as if you are standing on a fixed deck with star trek style artificial gravity. This could trick you into forgetting the rotation.

Meh, I was just trying to say in a polite manner that I don't care much about windows. What Shadowmage have is already awesome. The engineering argument still stand, the Von Brown design you posted also had its window on the hub, none on the torus.

 

[Jimbodiah]

No windows is just fine for me as well, on any of them.

[tater]

9 minutes ago, RedParadize said:

Meh, I was just trying to say in a polite manner that I don't care much about windows. What Shadowmage have is already awesome. The engineering argument still stand, the Von Brown design you posted also had its window on the hub, none on the torus.

I don't disagree. I was sort of thinking out loud.

[tater]

Check this out (sorta off topic):

http://www.coelux.com

That's not a skylight. It's an LED panel. I would imagine that interior light (both stations and bases) will be faked like this to look as natural as possible. They are working on one where the "sun" moves as well. In the case of our tori, I'd think that better than windows would be cameras and panels. It means any space can be an "outside wall," and the occupant could elect to pick any view they like. Earth, or external cameras. In the latter case, there can be cameras around the wheel, so you can get the view closest to your room, and have it spin if you like that, or from a non-rotating part of the station nearby, looking whichever direction you favor.

 

Edited November 14, 2016 by tater

[Shadowmage]

Got the 50m unwrapped last night.  Now I'm working on UV layout, esp. in regards to how to do the AO bake for the torus meshes without having to duplicate a lot of the UVs, all while eliminating visible seams as much as possible. 

Might have to split the interior and exterior portions of the torus into separate islands, and duplicate the interior islands where the AO would be different -- this just leaves me figuring out how to best hide the seams between the ext/int islands.  The seams between segments shouldn't be too noticeable as they will already be segmented on the texture (just have to mask out the noise/make the noise mirrored on the seams).

Here is the auto-layout UV mess that I get to clean up -- note the large # of unique islands I have to work with; every island is either unique geometry, or duplicate geometry that requires unique AO; most meshes have already been halved, quartered, or more.

 

Still a bit more island reduction that can be done by using sub-optimal UV sharing for some meshes where the AO would be 'close enough'.  Many of the smaller detail bits from each torus can likely be stacked, and I may be able to re-use the same texture space for each of the bracing lines.  The trusses are already sharing UVs wherever possible.  The largest use of UV space by far is the actual torus mesh segments which unfortunately cannot be stacked or re-used (or else the texture resolution would vary widely between each size of torus).

 

Hopefully the next images I post will be of the WIP textures, probably here in a day or two.

[RedParadize]

@Shadowmage Usually, filtering is only 1 or 2 pixel wide. You could get UVs a bit closer than that if you wished. I suspect you could optimize this by +15%.

Just saying. I will install SSTU before anything else regardless.

[Shadowmage]

9 minutes ago, RedParadize said:

@Shadowmage Usually, filtering is only 1 or 2 pixel wide. You could get UVs a bit closer than that if you wished. I suspect you could optimize this by +15%.

Just saying. I will install SSTU before anything else regardless.

You are correct for non-MIP-mapped textures.  However when MIP-maps are used you need to increase the padding quite substantially (by about 2px for every MIP-map level used on the texture).  Even at 16px padding on a 2048x texture I can still see seams on stuff in KSP when I zoom out.

I used to use 4px, then 8px, but still ran into seams on many models when zoomed out -- you can still see this on a few older parts; the SC-B and SC-C CM's for example, check the editor icon or zoom way out and there are visible black seams.  So now I use 16px for any 1024x or larger texture.  The padding can be reduced for smaller texture sizes as they have fewer MIP-map levels.

Thinking on it, there is probably a nice formula/equation that I could put together to calculate the correct padding for any given texture size....

[SpaceBadger007]

So I made this lunar station, using mostly sstu parts, and I thought I might as well show it off. This is just the start, more stuff will probably be added, but here is the core. And yes I did base it off a picture I saw that I thought was pretty cool.

http://imgur.com/a/Yarlt 

[Theysen]

42 minutes ago, SpaceBadger007 said:

So I made this lunar station, using mostly sstu parts, and I thought I might as well show it off. This is just the start, more stuff will probably be added, but here is the core. And yes I did base it off a picture I saw that I thought was pretty cool.

http://imgur.com/a/Yarlt 

SSTU aka SLS replica simulation mod

Nice work, I'm planning on something movie'ish but around Mars Duna with mainly SSTU stuff. It just looks too good. 

[tater]

1 hour ago, Theysen said:

Nice work, I'm planning on something movie'ish but around Mars Duna with mainly SSTU stuff. It just looks too good. 

A Duna Descent/Ascent Vehicle.

 

Before gear/legs got borked by Squad:

 

 

[Shadowmage]

The previous mess of UV auto-layout, after a few hours of hand-arrangement, turns into:

And with AO bake, allows the first-pass textured parts to look not bad at all (10m torus has some black rings on the texture as I was testing distortion/layout a bit):

And now comes the fun of figuring out the actual texturing of the parts. And re-rigging and re-animating everything...
(oh, how I wish blender would let you unwrap multiple animated objects into the same UV space, without breaking the animations / shapekeys; there are some things Blender is good at, UV unwrapping is not one of them )

If all goes well I should have these parts finished up for a release this weekend.  Need to finish textures, redo animations, and work on the config and balance end of them as well.

[Jimbodiah]

Wow, Mage!! That big one looks awesome!

[tater]

I was thinking about windows and "skylights" last night. This has no bearing on the SSTU parts, BTW, more of a "real life" sort of thing (or possibly for anyone reading skilled in IVAs), or something to envision when we imagine the interiors.

The light color we will likely see as a texture (because thermodynamics) is very much like the color of a frosted skylight...

It's entirely possible to have natural light in such an inflatable, by making areas of the structure only partially opaque. This would provide light, without the distraction of the world outside spinning. In short, no windows, but still lets light in---like a tent.

Spitballing here: It would be interesting if it was possible to do "cabin lights" such that when illuminated in daylight they are invisible, but in shadow/night they are there. Then do them as skylights (facing radially inwards). The idea is that at night, that's the ambient light in the rooms inside (cabin lights), and in the daylight, the lights look off, since the station is getting light from the sun. No idea if that is possible. Might look visually interesting, though. The "windows" would be much more subdued than usual KSP windows as it would be through layers of cloth/plastic, So I'm talking a very subtle set of lights, mostly visible only at night.

42 minutes ago, Jimbodiah said:

Wow, Mage!! That big one looks awesome!

They all look awesome.  

Edited November 15, 2016 by tater

[Akira_R]

@Shadowmage the torus models are looking awesome!!

I have a quick question regarding your engines!

In the cfgs for your tanks we have the ability to define the min. diameter and the min. interval for changing diameter, is there any way I can convince you to put the same functionality exposed in the cfgs for the engine mounts as well?

[Shadowmage]

1 minute ago, Akira_R said:

I have a quick question regarding your engines!

In the cfgs for your tanks we have the ability to define the min. diameter and the min. interval for changing diameter, is there any way I can convince you to put the same functionality exposed in the cfgs for the engine mounts as well?

It already exists, but is quite a bit more complicated because the engine cluster code does a bunch of calculation to determine the min+max mount sizes for any given layout.

Examine the RS-68 and RD-107/108 engines for examples.  Specifically:

	LAYOUT
	{
		name = Single
		defaultMount = Mount-Delta-IV
		MOUNT
		{
			name = Mount-Delta-IV
			size = 3.75
			minSize = 3.75
			maxSize = 3.75
		}
	}

 You can add similar code to any other engine, specifying which mounts to adjust the min/max size on.  If specified in the config it will overwrite any auto-calculated values.  You need to first specify what LAYOUT the adjusted mount belongs in, and then specify the adjusted parameters for that mount.  If adjusting multiple mounts for the same layout they can be added into the same LAYOUT node.  If you attempt to adjust a mount that is not already in the layout, it will be added as a new mount (as can be seen in the example above; that definition -adds- the delta-iv mount to the RS-68).  You can also remove specific mounts from specific layouts by adding a 'remove = true' key to the MOUNT node (it should contain only 'name = XXX' and 'remove = true' key-value pairs).

Diameter increment is already available in the engine cluster module configs ( 'diameterIncrement' ).

The way it all works is that each engine is flagged to include either upper stage and/or lower stage mounts (in the engine-cluster module config).  Each mount definition contains a flag as to whether it should be used as an upper stage or lower stage mount (or both).  From there the initialization code pulls all of the available layouts for an engine; for each layout it pulls all available mount options for the given upper/lower stage setup.  Each mount then has its size auto-calculated based on the given 'mounting area' and the 'mounting diameter' of the engine.  If overrides are specified in the part config it will skip the auto-calc and use the manually provided values;  you cannot override just the min or max, you must specify both if you are overriding the auto-sizing.

 

Oh, and you are on your own if/when it all breaks   (I wrote the auto-sizing code for a good reason, trying to hack around it is asking for trouble...)

I have to ask though -- what are you trying to accomplish?  (Knowing that might help me give better instructions/examples)

[Akira_R]

7 minutes ago, Shadowmage said:

It already exists, but is quite a bit more complicated because the engine cluster code does a bunch of calculation to determine the min+max mount sizes for any given layout.

*SNIP*

Oh, and you are on your own if/when it all breaks   (I wrote the auto-sizing code for a good reason, trying to hack around it is asking for trouble...)

I have to ask though -- what are you trying to accomplish?  (Knowing that might help me give better instructions/examples)

Awesome! Thank you for the quick reply and all the info, I think I can probably figure it out, I will do more poking around tonight after work and class, I may have stayed up far too late last night poking around cfgs and been mildly delirious as well as inebriated when i was trying to figure it out lol, I do remember seeing the min and max size things in the layout but didn't want to poke them until I found a way to change the diameter interval.

I am very aware that any problems caused by my poking are my own to deal with, I may stop by with the occasional "is this broken or did I break it" question though 

As for what I am trying to do:

I am building out a career install that is utilizing a 3.2x rescale and is set up with minor realism in mind, so the early tech stuff up to about the 90+ science level is all small sounding rockets and airplanes. I have set the fuel tanks and solid boosters to start out at a min diameter of 0.3125m and increment by 0.3125m.  I have some very early liquid fueled sub-orbital sounding rocket upper-stages with a 0.9375m tank diameter, one of the very early upper stage engines (can't remember name, I'm at work atm) fits to the tank perfectly when no mount is selected. However the auto shroud for the engine is tied to engine mount size (or at least it appears to be) which only goes down to 1.25m so I'm kind of assuming that if I can set the engine mount diameter lower then the engine shroud that is generated will match that lol. 

Now that I think about it I have another question lol, is it possible to add engine shrouds to one of the SRBs via cfg? I have a fuzzy memory of your engines having a MODULE for the shroud... could be misremembering though. One (or maybe all I'm not sure) of the SRBs has a bottom attach node but no shroud and I don't think I saw an option to turn shrouds on in the VAB.

[Shadowmage]

46 minutes ago, Akira_R said:

Awesome! Thank you for the quick reply and all the info, I think I can probably figure it out, I will do more poking around tonight after work and class, I may have stayed up far too late last night poking around cfgs and been mildly delirious as well as inebriated when i was trying to figure it out lol, I do remember seeing the min and max size things in the layout but didn't want to poke them until I found a way to change the diameter interval.

I am very aware that any problems caused by my poking are my own to deal with, I may stop by with the occasional "is this broken or did I break it" question though 

As for what I am trying to do:

I am building out a career install that is utilizing a 3.2x rescale and is set up with minor realism in mind, so the early tech stuff up to about the 90+ science level is all small sounding rockets and airplanes. I have set the fuel tanks and solid boosters to start out at a min diameter of 0.3125m and increment by 0.3125m.  I have some very early liquid fueled sub-orbital sounding rocket upper-stages with a 0.9375m tank diameter, one of the very early upper stage engines (can't remember name, I'm at work atm) fits to the tank perfectly when no mount is selected. However the auto shroud for the engine is tied to engine mount size (or at least it appears to be) which only goes down to 1.25m so I'm kind of assuming that if I can set the engine mount diameter lower then the engine shroud that is generated will match that lol. 

Now that I think about it I have another question lol, is it possible to add engine shrouds to one of the SRBs via cfg? I have a fuzzy memory of your engines having a MODULE for the shroud... could be misremembering though. One (or maybe all I'm not sure) of the SRBs has a bottom attach node but no shroud and I don't think I saw an option to turn shrouds on in the VAB.

I -think- your problem might be solved by simply setting the 'diameterIncrement' in the engines to 0.3125m.  The smallest any mount can go is 1 x 'diameterIncrement'.  So even if you were to modify the mount/layouts to allow for the smaller mount size, it probably won't work properly unless the increment is adjusted as well.

If you want to use the engine without mount, while still allowing for greater range of fairing size selection, you can adjust the 'minSize' and 'maxSize' of the 'Mount-None' mount option for the given layout.  If you want smaller than the default 'diameterIncrement' (0.625m), make sure to set that up properly as well.

Alternatively, you could use the ISDC as a stand-alone engine shroud (click the 'toggle interstage node' on the engine to enable the upper attach node).  Not sure what the 'minDiameter' for it is off the top of my head, but you can likely config patch it to allow for 0.3125m as well.

 

SRBs -- they do not support fairings, nor will I be adding fairing support.  You can add the module to the part configs, but it won't work properly as it would need a metric buttload of interaction code added to the MSRB module, as well as additional information added to the model definitions for each SRB piece.  And really, the SRB geometry is not conductive to having fairings; most have strange tapers at the bottom, or nozzles that are as big/bigger than the body diameter.

[tater]

What will the rotation rates be set to? 

[tater]

What we need is an "observatory" part. Not astronomical, but recreational. With an IVA. COS-like part, with loads of windows (like a cupola) Basically no props inside, other than the interior being slightly lower volume (i.e.: the walls and window frames have thickness), it's a zero g space. Maybe some hand-hold loops of webbing here and there to make it look less sterile. Place "seats" (locations, but no seat model) randomly around---meaning random in 3d, so the kerbals look like they are floating around. One of those near the hub would give an awesome view of a torus station.

[Shadowmage]

29 minutes ago, tater said:

What will the rotation rates be set to? 

Adjustable.  Recently added GUI slider controls for rotation speed; you can even set it to zero speed to come to a full stop.

Defaults will be in the range from 2-6 rpm, with most probably set at a default of ~3rpm -- the 50m torus, at 6rpm, just -barely- gives 1g.

[RedParadize]

@Shadowmage Just wanted to say that torus look awesome. Great work!

[tater]

Since tori are the current topic, here's something I posted way up the thread. The habitats are from @cxg2827's awesome mod to give a sense of scale.:

The large torus is clearly capable of having 2 decks.

Hey, it's also useful for guesstimating "fit out" masses. It's literally got the room of more than 50 of those station elements, so the fitting out mass would be substantial.

Where the large crew capability could actually be useful would be something like EPL, if time were to matter. Ie; the more crew you have at a station, the faster work gets done.

[RedParadize]

probably more like 3/4 deck. If I followed correctly Shadowmage wanted torus to be more about comfort than capacity, so they might be more open space than anything else.

[tater]

In KSP as it stands, there is no reason for large numbers of crew, anyway. If there was a construction paradigm that took long periods (many months or more) to build things in orbit, then perhaps that time could be mitigated by large numbers of workers. Then you make big stations (with reasonable crew capacity), and the "dry dock" part uses the total crew to build things much faster.

It would take something like the way the labs or ISRU works once you "launch" a new craft, then XX days later, it becomes available.