SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[DaveS]

So the PLB_TCS group is useless?

No. PLB_TCS is the regular mylar MLI blankets that serves as a divider between the payload and the midbody. The liner is an optional flight kit that flew on all the HST missions and all the IUS missios as well as some of the Spacelab and Mir missions.
So it needs a mission file parameter to toggle it.

 

[Urwumpe]

No. PLB_TCS is the regular mylar MLI blankets that serves as a divider between the payload and the midbody. The liner is an optional flight kit that flew on all the HST missions and all the IUS missios as well as some of the Spacelab and Mir missions.



So it needs a mission file parameter to toggle it.

Can't we define it as payload and make a new mesh out of it?

 

[DaveS]

Can't we define it as payload and make a new mesh out of it?

Why complicate things? We already do this with the vertical stabilizer.

Edit:
Forgot to mention that Atlantis has the liner installed for her exhibit at the KSCVC: https://farm8.staticflickr.com/7563/16089044160_df0abf9dac_o.jpg

 

[Urwumpe]

Why complicate things? We already do this with the vertical stabilizer.

Because it is payload specific? And why complicate things by manipulating a meshgroups visibility for a few missions? (And can you look for a smaller image: Hell, this waste of megapixels needs a long time to download, just for showing something already visible at 3% the resolution)

Also, shouldn't we remove the parts hidden behind the blankets from rendering when they are installed and show them when the blanket is not installed? How many polygons and textures are we loading just for fun there?

 

[DaveS]

Because it is payload specific? And why complicate things by manipulating a meshgroups visibility for a few missions?

Isn't these kind of things that the mission files are supposed to handle? Mission specific items while the scenario files handles the dynamic stuff such systems statuses? We already "manipulate meshgroups visibility for a few missios" with the Ku band DA (remember, only the first six missions flew without it, STS-7 and the rest used it). Same with the SILTS pod for Columbia, her first six flights were without it, STS-61C and subs had it all the way to number 28 and last. Endeavour for example always had the drag cute, the rest were modified as they came offline afterwards and went to Palmdale for the OMDPs. And what about the EDO pallet? Columbia used it for all the Spacelab missions starting with STS-50 and Endeavour flew it on STS-67.

 

[Urwumpe]

Again: How many triangles and textures are we loading just for fun now, which are absolutely not visible during rendering?

That's what a blanket does: It covers something underneath it!

 

[GLS]

My opinion on this, and other things, is that if it is something supplied by the shuttle, we should provide it. Payload-specific stuff, it's up to the payload. If I understand this correctly, it is shuttle-supplied, so...

In this case here are the groups involved:

LABEL PLB_TCS
MATERIAL 1
TEXTURE 3
GEOM 171 166 ; PLB_TCS

LABEL PLB_TCS_LINER
MATERIAL 1
TEXTURE 2
GEOM 171 166 ; PLB_TCS_LINER

... and one texture loaded only for the PLB_TCS_LINER group. At first glance this doesn't seem "expensive", but I still haven't seen the differences between them, I only noticed there were faces behind faces and asked the question.

---------- Post added at 03:56 PM ---------- Previous post was at 03:52 PM ----------

Because it is payload specific? And why complicate things by manipulating a meshgroups visibility for a few missions? (And can you look for a smaller image: Hell, this waste of megapixels needs a long time to download, just for showing something already visible at 3% the resolution)

Also, shouldn't we remove the parts hidden behind the blankets from rendering when they are installed and show them when the blanket is not installed? How many polygons and textures are we loading just for fun there?

I've made changes awhile back to only load what is used (at least what was possible at the time). So, e.g., the External Airlock or the RMS are only loaded when they are needed. Tecnically we could do this for ALL optional things, by moving the groups in question to individual meshes, that then would only be loaded when needed.
Currently things like bridgerails and the 2 tails are hidden/shown as needed, as they are in the "main" Orbiter mesh file.

---------- Post added at 04:06 PM ---------- Previous post was at 03:56 PM ----------



It looks like the MPMs might have a small cut to allow deployment without touching the PLB edge... can't really see from that angle.

 

[DaveS]

Here's the official Space Shuttle Payload Bay Payload User's Guide: https://www.scribd.com/document/109049399/Space-Shuttle-Payload-Guide

The liner is mentioned on page 4-1, bottom paragraph. Photos of the PLB with and without the liner are provided on pages 4-2 and 4-3.

 

[Urwumpe]

My opinion on this, and other things, is that if it is something supplied by the shuttle, we should provide it.

Yes. But my argumentation is rather: What must be inside the main mesh and what is optional stuff.

The main mesh should ideally be just the most bloatfree baseline we can get. I know we have historic decisions that contradict this. But its worthy to try it, because its easily described in this example:

and one texture loaded only for the PLB_TCS_LINER group. At first glance this doesn't seem "expensive", but I still haven't seen the differences between them, I only noticed there were faces behind faces and asked the question.

Its not just about the texture of the PLB_TCS_LINER group, but also about the textures of those parts, that are not visible at all, when the PLB_TCS_LINER group is visible and blocking the view. When we load both by having both options in the main mesh, it means the textures of both are subject to be managed by the rendering client and likely loaded into GPU memory.

Also, it increases the chances of Z-fighting and the chance that small issues in a rendering client turn into severe bugs because we are the least robust add-on around.

About the tools argumentation: Absolutely yes. What the shuttle provides to the payload users should be available in our add-on and included into the DLL already, if possible. There are exceptions, like the CISS of Centaur, which justify being separate vessels because they are too complex to be included.

Its also the key question about something like SpaceLab: Is it really payload or is it better part of the Space Shuttle?

 

[GLS]

Currently we only have these optional items inside the main mesh: bridgerails, 2 lights, some covers for the CISS and the tails (and now we add the liner).
Here's the code:

// hide tail which is not used on this flight
	GROUPEDITSPEC grpSpec;
	grpSpec.flags = GRPEDIT_SETUSERFLAG;
	grpSpec.UsrFlag = 0x00000002; // hide group
	if (pMission->HasDragChute())
		oapiEditMeshGroup(hDevOrbiterMesh, GRP_VERTICAL_STABILIZER_ORIG, &grpSpec);
	else
		oapiEditMeshGroup(hDevOrbiterMesh, GRP_VERTICAL_STABILIZER_CHUTE, &grpSpec);

	// hide bridgerails
	for (unsigned int i = 0; i < 13; i++) {
		if (!pMission->HasBridgerail(i)) oapiEditMeshGroup(hDevOrbiterMesh, GRP_BAY1_LONGERON + i, &grpSpec);
	}
	
	// hide bay 13 covers
	if (hasCISS) oapiEditMeshGroup( hDevOrbiterMesh, GRP_PLB_BAY13_COVERS, &grpSpec );

	if (!pMission->HasBulkheadFloodlights())
	{
		oapiEditMeshGroup( hDevOrbiterMesh, GRP_XO576_BULKHEAD_DOCKING_LIGHT, &grpSpec );
		oapiEditMeshGroup( hDevOrbiterMesh, GRP_XO576_BULKHEAD_LIGHT, &grpSpec );
	}

We could move all there groups out, but I think only the liner loads it's own texture.
IMO these are all small items, so I can live with the extra load they add by being loaded always.

 

[DaveS]

Currently we only have these optional items inside the main mesh: bridgerails, 2 lights, some covers for the CISS and the tails (and now we add the liner).
Here's the code:

// hide tail which is not used on this flight
    GROUPEDITSPEC grpSpec;
    grpSpec.flags = GRPEDIT_SETUSERFLAG;
    grpSpec.UsrFlag = 0x00000002; // hide group
    if (pMission->HasDragChute())
        oapiEditMeshGroup(hDevOrbiterMesh, GRP_VERTICAL_STABILIZER_ORIG, &grpSpec);
    else
        oapiEditMeshGroup(hDevOrbiterMesh, GRP_VERTICAL_STABILIZER_CHUTE, &grpSpec);

    // hide bridgerails
    for (unsigned int i = 0; i < 13; i++) {
        if (!pMission->HasBridgerail(i)) oapiEditMeshGroup(hDevOrbiterMesh, GRP_BAY1_LONGERON + i, &grpSpec);
    }
    
    // hide bay 13 covers
    if (hasCISS) oapiEditMeshGroup( hDevOrbiterMesh, GRP_PLB_BAY13_COVERS, &grpSpec );

    if (!pMission->HasBulkheadFloodlights())
    {
        oapiEditMeshGroup( hDevOrbiterMesh, GRP_XO576_BULKHEAD_DOCKING_LIGHT, &grpSpec );
        oapiEditMeshGroup( hDevOrbiterMesh, GRP_XO576_BULKHEAD_LIGHT, &grpSpec );
    }

We could move all there groups out, but I think only the liner loads it's own texture.
IMO these are all small items, so I can live with the extra load they add by being loaded always.

The bridgerails load their own texture (SSU_Bridgerail.dds, 2048x2048).

 

[GLS]

The bridgerails load their own texture (SSU_Bridgerail.dds, 2048x2048).

For them we can either separate all into individual meshes and load as needed, or put them all into one mesh and load when needed and hide what is not needed.

---------- Post added at 08:11 PM ---------- Previous post was at 06:01 PM ----------

Finishing the liner option and just to confirm, we either show one floor or another, right?
Just noticed the mapping is messed up at the top-most vertical surface on the PLB sill.

On the bridgerails, I think they're about 2000 vertices total, which we could say is a good candidate to have their own mesh. But then they were used on probably most (all?) missions, so... I vote to leave as is. :shrug:

 

[DaveS]

Finishing the liner option and just to confirm, we either show one floor or another, right?

All we need to is either hide or show the meshgroup PLB_LINER. There's no option for both. Either you fly with the liner or you fly without it which leaves only the regular MLI.

On the bridgerails, I think they're about 2000 vertices total, which we could say is a good candidate to have their own mesh. But then they were used on probably most (all?) missions, so... I vote to leave as is. :shrug:

The bridgerails are what the PRLAs attach to so they were always flown. So what we have now is correct.

 

[GLS]

All we need to is either hide or show the meshgroup PLB_LINER. There's no option for both. Either you fly with the liner or you fly without it which leaves only the regular MLI.

But if the liner covers the MLI, why not hide the MLI when using the liner?

The bridgerails are what the PRLAs attach to so they were always flown. So what we have now is correct.

When I say bridgerails I mean the BayX_longeron groups, that are controlled via the Bridgerails parameter.

 

[Wolf]

New OMS pod, are these any better than the old ones?

https://www.dropbox.com/s/0gyx1l4xodvibbg/SSU_NEW_OMS_POD.jpg?dl=0
https://www.dropbox.com/s/seyzyffr5jpu9bt/SSU_NEW_OMS_POD2.jpg?dl=0

I am already working on a new version which will improve the front side of the OMS PODs (HRSI tiles) on Columbia and Challenger. Once done, if the outcome will be satisfactory I will transfer that onto the other orbiters, this will also result in the correct number of black tiles shown (as it is wrong in both the original and the current hi-res textures)

 

[GLS]

Were the Centaur missions supposed to use the liner, as did the IUS ones? I haven't found anything one way or another, but I'd think it would not be used (1) for weight and (2) because the gap between the MLI and the liner would probably not get the best ventilation and liquid air could form.... but this is only my opinion, so... :shrug:

 

[DaveS]

Were the Centaur missions supposed to use the liner, as did the IUS ones? I haven't found anything one way or another, but I'd think it would not be used (1) for weight and (2) because the gap between the MLI and the liner would probably not get the best ventilation and liquid air could form.... but this is only my opinion, so... :shrug:

Here I am not sure. I'm not sure how thick the liner is so it's hard calculate a general mass estimate without a thickness. Anyone know how much 1 square foot of Teflon coated Beta Cloth ½ inch thick might weigh?

 

[GLS]

Here I am not sure. I'm not sure how thick the liner is so it's hard calculate a general mass estimate without a thickness. Anyone know how much 1 square foot of Teflon coated Beta Cloth ½ inch thick might weigh?

How would you then decide "this is too heavy" or "this is light enough"? :shrug:

BTW: what was the idea behind the liner? I haven't seen that explained anywhere...

 

[DaveS]

How would you then decide "this is too heavy" or "this is light enough"? :shrug:

I can't imagine that it was too heavy as it's the same material that the post-Apollo 1 pressure suits were made of. Since it appears to have the consistency of ordinary fabric, I'd say maybe 200 g at the worst for one square foot of the liner. So for entire installation we have 300 kg.

BTW: what was the idea behind the liner? I haven't seen that explained anywhere...

Yes, I have never seen this being explained anywhere either. I think it might be that the beta cloth is smoother and uniform so it provides a more benign thermal environment in the payload bay. The ordinary TCS blankets are very rough so the thermal environment isn't as good and even that is it is with the liner installed.

---------- Post added at 04:46 PM ---------- Previous post was at 01:29 PM ----------

I can't imagine that it was too heavy as it's the same material that the post-Apollo 1 pressure suits were made of. Since it appears to have the consistency of ordinary fabric, I'd say maybe 200 g at the worst for one square foot of the liner. So for entire installation we have 300 kg.



Yes, I have never seen this being explained anywhere either. I think it might be that the beta cloth is smoother and uniform so it provides a more benign thermal environment in the payload bay. The ordinary TCS blankets are very rough so the thermal environment isn't as good and even that is it is with the liner installed.

Got a discussion going with a former shuttle engineer on the NASASpaceflight.com Shuttle/Centaur thread about the liner: https://forum.nasaspaceflight.com/index.php?topic=2398.msg1829486#msg1829486

 

[GLS]

So it's to keep the PLB clean (hence the teflon coating )... I think that makes sense with the IUS, as it has to vent the SRMs and some dust might come out...(?) For the Centaur, I don't think dust would be an issue, but moisture might...

Looking at some pictures of the satellites launched, most seem to use the liner, so payload venting might actualy be the issue, and the upper stage might not have much/anything to do. For the HST mission, they carried big boxes with tools and the new stuff, so venting was an issue. The ISS modules didn't vent so that's why it wasn't used recently.

So, if it's up to the payloads, then probably the Centaur missions would use the liner as the payloads would vent... don't know if moisture would be an issue, one way or another. :shrug: