# SSU Development thread (4.0 to 5.0)

#### GLS

I've attached a schematic of the bipod struts from the SLWT SDH which shows a 5.5" offset between the tanked configuration and the unloaded configuration. The configuration we have now is for the unloaded configuration.
The shift I did was 0.1011m, or just under 4in, which equates to 3.8337856725669485283499520763165º forward rotation on the bipod struts. That makes the ET/SRB aft attachments horizontal, although they could be tilted forward/up. I'm sure not all tanks shrunk exactly the same, even of the same type, let alone when they were made of different metals. :shrug:

Anyway, the tanked ET is up! For now it is only the SWT, and that already has the ET half of the SRB aft attach struts. (and only the STS-1* SRBs have their end of the struts)

There is something wrong somewhere, as the fwd attachment ball is half inside the NLG wheel well. Went back and it was like that before, so it is not a result of this shift. The NLG door end is at the correct place, so that's not it. It not a huge thing so I can live with this for now.

*) sooner than later we'll need a new naming scheme for the SRBs/SRMs.

#### kuddel

##### Donator
Donator
I just noticed that the texture SSUbay_norm.dds has 48MB!!!! :blink: Is it compressed at all?
No it isn't

(can it be compressed?)
DTX1 Format should have been used, which is compressed.

That's not used by MOGE, but even D3D9 must be in pain with that one... :uhh:
It has to be decompressed in (video-)memory anyway, so the main benefit is disk-IO time (and space) reduction.
Find the DXT1 version attached.
As I don't think I have write access rights to the SSU repository, you can commit that.

By the way: Most of the XXX_norm.dds files seem to be "non-DXT1".
- Textures\SSU\AftSkirt_bottom_foam_norm.dds
- Textures\SSU\Centaur\Centaur_G_tex_norm.dds
- Textures\SSU\Centaur\CISS_bellows_norm.dds
- Textures\SSU\Centaur\CISS_tex_norm.dds
- Textures\SSU\Centaur\RL10_maintex_norm.dds
- Textures\SSU\CXO\Chandra_XO_goldfoil_norm.dds
- Textures\SSU\CXO\Chandra_XO_silverfoil_norm.dds
- Textures\SSU\DFI_pallet_boxtex_norm.dds
- Textures\SSU\Instafoam_norm.dds
- Textures\SSU\ku_norm.dds
- Textures\SSU\LWT_ETtex_norm.dds
- Textures\SSU\ODS_collar_norm.dds
- Textures\SSU\OFT_FWDSkirt_norm.dds
- Textures\SSU\PLB_LINER_norm.dds
- Textures\SSU\PORT_OMSpod_norm.dds
- Textures\SSU\Pre51L_L_SRB_FWD_skirt_norm.dds
- Textures\SSU\Pre51L_R_SRB_FWD_skirt_norm.dds
- Textures\SSU\RMS_norm.dds
- Textures\SSU\RSRM_LSRB_FWD_Skirt_Assy_norm.dds
- Textures\SSU\RSRM_RSRB_FWD_Skirt_Assy_norm.dds
- Textures\SSU\ShuttleOTS_tex_norm.dds
- Textures\SSU\slc6_hires_norm.dds
- Textures\SSU\SLWT_ETtex_norm.dds
- Textures\SSU\SRB_AftSkirt_norm.dds
- Textures\SSU\SSUbay_norm.dds (subject of this post)
- Textures\SSU\STBD_OMSpod_norm.dds
- Textures\SSU\SWT_FRL_ETtex_norm.dds

...actually none of them is

#### Attachments

• 685.2 KB Views: 34

#### GLS

No it isn't

DTX1 Format should have been used, which is compressed.

It has to be decompressed in (video-)memory anyway, so the main benefit is disk-IO time (and space) reduction.
Find the DXT1 version attached.
As I don't think I have write access rights to the SSU repository, you can commit that.

By the way: Most of the XXX_norm.dds files seem to be "non-DXT1".
- Textures\SSU\AftSkirt_bottom_foam_norm.dds
- Textures\SSU\Centaur\Centaur_G_tex_norm.dds
- Textures\SSU\Centaur\CISS_bellows_norm.dds
- Textures\SSU\Centaur\CISS_tex_norm.dds
- Textures\SSU\Centaur\RL10_maintex_norm.dds
- Textures\SSU\CXO\Chandra_XO_goldfoil_norm.dds
- Textures\SSU\CXO\Chandra_XO_silverfoil_norm.dds
- Textures\SSU\DFI_pallet_boxtex_norm.dds
- Textures\SSU\Instafoam_norm.dds
- Textures\SSU\ku_norm.dds
- Textures\SSU\LWT_ETtex_norm.dds
- Textures\SSU\ODS_collar_norm.dds
- Textures\SSU\OFT_FWDSkirt_norm.dds
- Textures\SSU\PLB_LINER_norm.dds
- Textures\SSU\PORT_OMSpod_norm.dds
- Textures\SSU\Pre51L_L_SRB_FWD_skirt_norm.dds
- Textures\SSU\Pre51L_R_SRB_FWD_skirt_norm.dds
- Textures\SSU\RMS_norm.dds
- Textures\SSU\RSRM_LSRB_FWD_Skirt_Assy_norm.dds
- Textures\SSU\RSRM_RSRB_FWD_Skirt_Assy_norm.dds
- Textures\SSU\ShuttleOTS_tex_norm.dds
- Textures\SSU\slc6_hires_norm.dds
- Textures\SSU\SLWT_ETtex_norm.dds
- Textures\SSU\SRB_AftSkirt_norm.dds
- Textures\SSU\SSUbay_norm.dds (subject of this post)
- Textures\SSU\STBD_OMSpod_norm.dds
- Textures\SSU\SWT_FRL_ETtex_norm.dds

...actually none of them is
You just created the work list for SSU 5.1. Thanks!

EDIT
Oh, you compressed them already... now I have to find something for SSU 5.1...:dry:
In following the new philosophy, I'll commit them in the graphics branch and they will make their way to the trunk with the SRB corrections, hopefully sometime this or next week. Thanks again!

---------- Post added at 02:03 PM ---------- Previous post was at 01:46 PM ----------

BTW kuddel, you can probably help a bit in tracking this issue: in MOGE some mesh groups go "half-transparent" when the camera is in a certain angle. This usually happens to the FSS, but I've seen this recently in the untextured SRB mesh groups. One of them actually displays the ET texture... :uhh:
Without me wanting you to invest much time into this, would you say it is a GPU, MOGE, GPC, mesh or texture?

Last edited:

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
As the one responsible for those normal map textures, I just followed the D3D9Client manual which states that uncompressed R8G8B8 yields the best quality and that compressed DXT-1 yields the worst quality.

#### Attachments

• 119.6 KB Views: 40

#### GLS

As the one responsible for those normal map textures, I just followed the D3D9Client manual which states that uncompressed R8G8B8 yields the best quality and that compressed DXT-1 yields the worst quality.
I don't know how/if the normal (or other "fancy") texture processing differs from the "regular" textures, but AFAIK texture compression is lossy, regardless of what the purpose of the texture is. So, if we are compressing the "regular" textures, then maybe there isn't much of a loss in it? :shrug:
Anyway, that can be checked with a pixel value subtraction between compressed and raw textures.

#### kuddel

##### Donator
Donator
@DaveS: Yes you're absolutely right, the DXT1 is "lossy", thanks for pointing that out!
Whether that's O.K. or to much (bad) might have to be decided for each _norm texture separately!

#### GLS

I think they're done!

Well, half of them anyway... I still have to rotate, mirrior or copy parts of the left SRB to make the right one, plus the changes to the textures... but I'm now well over the hump!

#### Attachments

• 163.7 KB Views: 237

#### GLS

Urwumpe, could I (and DaveS) get upgraded to "full boss" in Sourceforge? I'll also like to have access to the company's vacacion house... :rofl:

#### Wolf

##### Donator
Donator
Urwumpe, could I (and DaveS) get upgraded to "full boss" in Sourceforge? I'll also like to have access to the company's vacacion house... :rofl:

:lol::lol::lol:

#### Urwumpe

##### Not funny anymore
Donator
Urwumpe, could I (and DaveS) get upgraded to "full boss" in Sourceforge? I'll also like to have access to the company's vacacion house... :rofl:

Sorry, but if you want the keys for our projects Palazzo in the Tuscany (Crowdfunding is great! Please also support my Patreon so I can buy another solid-gold Tesla X.), you'll have to defeat me in a fair duel. Tomorrow on sunrise, in the castle garden. Bring your own sword.

Or you at least demote me to "Developer" as your first task as "Admin", so we are not having an overly large admin team. You and DaveS should be enough to do the job.

#### GLS

Sorry, but if you want the keys for our projects Palazzo in the Tuscany (Crowdfunding is great! Please also support my Patreon so I can buy another solid-gold Tesla X.), you'll have to defeat me in a fair duel. Tomorrow on sunrise, in the castle garden. Bring your own sword.
Deal! Let's just hope my buttler wakes me up on time... :lol:

Or you at least demote me to "Developer" as your first task as "Admin", so we are not having an overly large admin team. You and DaveS should be enough to do the job.
I don't really see the need for that... :shrug:

#### Urwumpe

##### Not funny anymore
Donator
I don't really see the need for that... :shrug:

Well, I do, that should be enough in that special case. :thumbup:

Should something happen to me eventually, you might have my admin account being abused, if I have more rights than really necessary.

#### GLS

Well, I do, that should be enough in that special case. :thumbup:

Should something happen to me eventually, you might have my admin account being abused, if I have more rights than really necessary.

#### GLS

I think I finally finished the SRB meshes!
I'll dump the remaining issues/improvements in the SRB ticket for future work. Still to do now is the correction of the SRB vessel c.g. and thruster plumes, but I'll probably jump to the IUS ASE first as I'm a little tired of looking at SRBs, and that should be quick anyway.

I haven't looked at the Orbiter recently, but (some of) the handrails were colliding with other parts, so they are not in the correct place. I think some of the sill structures are also not in the correct place. With the ExtAL pins now in the correct place, the PLBD drive collides with them, so they are also not in the right place.
If there is no position data for these items, then IMO we need to look at photos and use both the known positions of the pins of payloads and the PLB ring frames, to bound the positions of those items. That way, any future problems will be of a smaller magnitude.

One other thing I noticed while I was looking at the SRB corrections in the stack is gaps between the wing chines (the top of them) and the bottom part of the vehicle.
Dealt with these in the latest commit. Everything looks alright now.
That was fast....
...way too fast... the gaps in the chines still exist, and the "middeck wall" is sticking out of the bottom (more on this below). There is also a hole in the SILTS pod. The PLB handrails still have the same issues as before (and they now collide with the slidewire mechanism), and the Ku-Band antenna collides with the forward-most RH PLBD drive mechanism. BTW, checking the coordinates of the antenna drives might be a good idea as the dish isn't pointing up in the way it should.
Radiators and PLBD door sections don't line up (they probably should), and radiator chevrons are out of place.

On a "middeck" to show behind the side hatch window (which btw is still oval), IMO this is all we need:
Code:
GEOM 8 10
1.95 -2.21245 13.2803 -0.577349 0.577349 -0.577349 0 0
1.95 -0.212448 13.2803 -0.577349 -0.577349 -0.577349 0 0
1.95 -2.21245 9.90941 -0.577349 0.577349 0.577349 0 0
1.95 -0.212448 9.90941 -0.577349 -0.577349 0.577349 0 0
-1.95 -2.21245 13.2803 -0 0.707083 -0.707083 0 0
-1.95 -0.212448 13.2803 -0 -0.707083 -0.707083 0 0
-1.95 -2.21245 9.90941 -0 0.707083 0.707083 0 0
-1.95 -0.212448 9.90941 -0 -0.707083 0.707083 0 0
1 2 0
3 6 2
5 0 4
6 0 2
3 5 7
1 3 2
3 7 6
5 1 0
6 4 0
3 1 5
A simple and un-textured 5-sided box. :shrug:

#### GLS

Finished the work on the IUS ASE (and IUS)!!!

Didn't find any data on the tilt table dimensions, so I kept that we had and just removed the extra vertices in it. Trunnion pins, tilt table rotation axis and IUS/PL interface* should be at their correct positions. Also corrected the materials and re-ordered the mesh groups to reduce texture and material switching.
Then I did a "quick tour" of the IUS itself, and corrected the materials as well and added the missing EEC part. Had to correct the dimensions of all 3 parts, with not enough data, so common sense was used to fill the gaps. Here is an image of the finished product:

Also added a second set of struts to deploy the second cone, but I found a photo that shows only one set... given that I have no idea how it actually deployed, I think we should stick with a second set of struts. :shrug:

Now, the last item on my list of graphics work: back to the SRBs to finish the vessel coordinates.

*) later while working on the IUS 2º stage I noticed that the IUS/PL interface apparently isn't the top-most part of the IUS, but the bottom of the top ring... :uhh:

#### Attachments

• 156.9 KB Views: 373

#### GLS

DaveS, I just saw your question on NSF regarding the CISS plumbing. Please, look at diagram 19.1-1 (on the "diagram book") that has an overview of the aft bulkhead. At the bottom there are 6 (but only 4 are labeled) "blank panels" that were know as "Payload Oxidizer Panel" (starboard side) and "Payload Fuel Panel" (port side).
A quick search on google shows that the inboard pair was for electrical connectors, and the 4 outboard panels were for fluids:

Page 138 here shows precise locations for the panels (disregard the relocation suggestions).
So the CISS should have used the 2 starboard outboard panels.

#### Urwumpe

##### Not funny anymore
Donator
Also added a second set of struts to deploy the second cone, but I found a photo that shows only one set... given that I have no idea how it actually deployed, I think we should stick with a second set of struts. :shrug:

I think one set is correct, the RL-10 also needs only one set of struts, the second nozzle segment is kept in place by tension. Also see this photograph:

#### GLS

I think one set is correct, the RL-10 also needs only one set of struts, the second nozzle segment is kept in place by tension. Also see this photograph:

Yes, but how is the middle cone held before deployment and how does it deploy?

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Yes, but how is the middle cone held before deployment and how does it deploy?
I'm thinking that there's a lip or capture ring on the base nozzle that engages the first extendable nozzle while the the second extendable nozzle keeps on going until it reaches the end of travel where it locks into place. So the larger second nozzle extension has some sort of capture feature that holds the smaller first nozzle extension until it engages the capture feature on the base of the base nozzle. This way you would only need one set of extension struts.

#### GLS

I'm thinking that there's a lip or capture ring on the base nozzle that engages the first extendable nozzle while the the second extendable nozzle keeps on going until it reaches the end of travel where it locks into place. So the larger second nozzle extension has some sort of capture feature that holds the smaller first nozzle extension until it engages the capture feature on the base of the base nozzle. This way you would only need one set of extension struts.
Yeah, there might be a "capture feature" where the 2 EECs meet, and the inner EEC (middle cone overall) is just tied at the top to the base of the mechanism. As the outer EEC deploys it eventually "collects" the inner EEC and whatever is holding it up is released/breaks and it then goes down with the outer EEC.
Starting to look plausible to me. :shrug:

---------- Post added at 07:18 PM ---------- Previous post was at 06:46 PM ----------

Currently tracking a wierd issue: the RH SRB shifts a bit away from the OV when at separation. The LH stays rock solid where it should, i.e., the only motion is the normal separation, but the RH has an immediate shift, and then does the normal motions.
Everything looked good now, so decided to get in the DeLorean and go back to see when this first issue appeared. From r3144 onwards it has this issue, so it isn't related to my recent work in the SRB area, as I was hoping it would.
Can anyone check if this also happens, before I go further back?

---------- Post added 12-02-19 at 12:44 AM ---------- Previous post was 12-01-19 at 07:18 PM ----------

Went back to before the latest big change in the SRB vessels (before the big merge with the aero stuff) and nothing changed. Played around with the code and it seems that it the first attachment to be released gets shifted: I swaped the order of the detachments and the LH SRB did the shift while the RH was correct.
I'm begining to thing this is related to the (latest) Orbiter beta version, as I recently updated to r90. Tomorrow I'll go back in those revs to see if anything changes.

---------- Post added at 03:25 PM ---------- Previous post was at 12:44 AM ----------

Went back to the Orbiter 2016 revision and still have the bug. :facepalm:
It probably wouldn't help, but did a CRT memory leak check, and it looks clean on SSU's side of the wall (just had the new DPS bus manager not being released), but... that only checks malloc calls, so I had to replace the new calls with a macro to get the offending file and line info, and I only did that in Atlantis.cpp, so it's totally possible that some of the other 20000 indications I got were from our side.

I'm currently out of ideas to track down this SRB shift... if push comes to shove, we could probably "force" the position of the SRB vessels after separation, but even if that works, it's just sweeping a bug under the rug... :shrug:

---------- Post added 12-03-19 at 02:14 PM ---------- Previous post was 12-02-19 at 03:25 PM ----------

It appears I'm finally done with the SRBs! Corrected the locations of plumes and thrusters so it all worked again, as some meshes and the SRB vessel center shifted a bit.
But more than that, the BSMs had some directions that I don't really know where they came from. I recalculated them, using the data from the NASA TM X-64967 (which Urwumpe "introduced" here some years ago) and, surprise surprise, it now looks much more realistic: they fall away while mostly pitching, instead of pitching almost in place before falling back. The only flaw in the new numbers is that they are averages of the 4 BSMs in each end, so it doesn't have the small roll induced by the more isolated aft BSM. I think there is enough data to calculate individual positions, but there are other things to do and this thing is far from bad as it is now, so these "small" details will have to wait.

Didn't spend much time working the smoke "explosion" at launch, so no solution on that yet.

Also, fixed a "logic hole" in the SSME and SRB lights: their positions were not being updated during launch, so the c.g. shifted and the lights got out of place.

I'll now (re)work the EEC deployment on the IUS, and that should close out the graphics branch for now. I'll wait maybe until the weekend before merging it back to the trunk, so "independent" checks of the changes to the SRBs and to the IUS (and its ASE) can be done.