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

[GLS]

The problem is that we need two sets of coordinates: One for STS-114 and one for STS-121 and subsequent flights. I'll explain why:


Prior to the launch of STS-114, the Orbiter Structures team at JSC re-ran some thermal analysis simulations and found that the clearances between the RMS End Effector electrical connector housing on the forward end on the OBSS and the very edge of the graphite/epoxy composite dish of the Ku band DA was around 1" nominally but when taking in the thermal expansion that both structures would experience on-orbit, those clearances would shrink to nothing and zero, preventing the Ku band DA from being deployed and activated as planned on FD1. So they had re-plan FD1 and FD2 to take in account the delayed Ku band DA deploy and activation activities which also delayed the downlink of critical post-launch data that had been recorded onboard (mainly high resolution Wing Leading Edge Impact Detection Subsystem sensor data and the photos from the new digital camera in the LOX ET umbilical well). Ku band deploy and activation was moved until after the crew had unberthed the OBSS for the first time, on FD2.


To avoid this on subsequent missions, they moved the OBSS and the MPMs a few inches further aft, to provide more clearance so that the Ku band DA could be deployed without having to power up the RMS, move it over and unberth of the OBSS.


All of this came to light very late, after the mission had been delayed from the May/June daylight launch period to the July/August daylight launch period when the orbiter was already on the pad having gone through the first tanking test.


As far as SSU is concerned, right now we have the MPMs in the original STS-114 positions which actually was based on the original plans to have a second RMS on the starboard side. The starboard RMS would have been a mirror version of the standard port RMS, so all the positions in the X/Z axes was identical. Since all orbiters were "scarred" for that RMS, they just decided to reuse the original mounting locations. Our MPM positions are accurate, it's just that the OBSS is just a tad bit too short.

Somehow I remember reading something about that. :blink:
Anyway, if the MPMs are in the correct "original" position, then it's fine with me (we don't have a thermal simulation so...), and we should correct the OBSS.

 

[DaveS]

Somehow I remember reading something about that. :blink:
Anyway, if the MPMs are in the correct "original" position, then it's fine with me (we don't have a thermal simulation so...), and we should correct the OBSS.

It has been corrected. An example of the very low clearance between the OBSS and the Ku band DA dish.

 

[GLS]

It has been corrected. An example of the very low clearance between the OBSS and the Ku band DA dish.

Thanks!
The clearance shouldn't be a problem as long as we don't implement thermal expansion.

One thing I noticed late last night while cleaning the Ku-band antenna, and it's visible in your image above, is the dish appears to have a lateral offset (down in the image) to its support.
If it is really offset, please wait until tonight to correct it, as I'm half way done and will commit sometime today.

 

[Wolf]

So after putting my HiRes textures to sleep for almost a year and hoping the current mesh will not be subject to any further change I started updating them. I am currently working on Columbia and I might have catched a glitch in the rudder mapping. There is a kind of a cut running from top to bottom in the mid section of the vertical stabilizer that generates a shift/displacement in the texture.

Here (red arrows) are the areas where you can notice it

 

[DaveS]

So after putting my HiRes textures to sleep for almost a year and hoping the current mesh will not be subject to any further change I started updating them. I am currently working on Columbia and I might have catched a glitch in the rudder mapping. There is a kind of a cut running from top to bottom in the mid section of the vertical stabilizer that generates a shift/displacement in the texture.

Here (red arrows) are the areas where you can notice it

View attachment 16534
View attachment 16535

I'll take a look at it once the mesh clean ups have been completed.

 

[Wolf]

I'll take a look at it once the mesh clean ups have been completed.

Weren’t the orbiter mesh done??
I guess I ll need to put myself on a hold again..

 

[GLS]

Ku-band antenna is up. One group would not save, so I had to run the clean up function and it deleted 3 isolated vertexes. :shrug:
If the dish is indeed misplaced, then some of the structure behind the dish could be deleted as it would be hidden behind the dish support.

 

[DaveS]

Weren’t the orbiter mesh done??
I guess I ll need to put myself on a hold again..

It is done. I was talking about this: https://sourceforge.net/p/shuttleultra/tickets/179/

---------- Post added at 11:55 PM ---------- Previous post was at 11:46 PM ----------

Ku-band antenna is up. One group would not save, so I had to run the clean up function and it deleted 3 isolated vertexes. :shrug:
If the dish is indeed misplaced, then some of the structure behind the dish could be deleted as it would be hidden behind the dish support.

I'll deal with as soon as I'm done with the Centaur stuff.

 

[GLS]

Updated OV ticket. Things are looking better and better, and the list is getting smaller. :thumbup:
The are some hidden triangles to delete, but they can wait until after the fine-tuning.

Tomorrow I'll continue to run the tickets as some can be closed (both visual and software), and hopefully sometime later this week I'll start work on the slidewire animation. The rad hose will be a total PITA to animate... :thumbsdown:

---------- Post added at 01:09 AM ---------- Previous post was at 01:00 AM ----------

Another thing, DaveS: did you got around to make the C2 panel? (you posted an image of a new F6 awhile back)
IMO this is not high-priority, but I'd like to get the keyboard keys to move when pressed, otherwise one has to constantly be moving the camera up to the MDU to check that the inputs are correct. If you didn't get that far ahead, I can make it myself as it is pretty much strait lines and stuff.

 

[DaveS]

---------- Post added at 01:09 AM ---------- Previous post was at 01:00 AM ----------

Another thing, DaveS: did you got around to make the C2 panel? (you posted an image of a new F6 awhile back)
IMO this is not high-priority, but I'd like to get the keyboard keys to move when pressed, otherwise one has to constantly be moving the camera up to the MDU to check that the inputs are correct. If you didn't get that far ahead, I can make it myself as it is pretty much strait lines and stuff.

I never finished anything related to that. It got pushed behind everything else. So there's nothing really, except a half-finished F6. Besides, I'm not sure how much rework will be required when we get the resized main VC base in as everything is fitted to the current incorrectly sized VC base mesh.

---------- Post added at 08:48 PM ---------- Previous post was at 02:24 AM ----------

For the orbiter issues, I don't understand this one:

- PLBD forward bulkhead latches don't "connect" to the door as the ones in the aft bulkhead do (or the aft ones connect too much?)

Right now there shouldn't be any connections between the doors and the bulkhead latches, as I don't have any good references on the activate halves that are on the doors themselves.

 

[GLS]

For the orbiter issues, I don't understand this one:

- PLBD forward bulkhead latches don't "connect" to the door as the ones in the aft bulkhead do (or the aft ones connect too much?)

Right now there shouldn't be any connections between the doors and the bulkhead latches, as I don't have any good references on the activate halves that are on the doors themselves.

They are at different distances, both comparing latches at one end, as well as comparing adjacent latches. But if there isn't enough info on them, then scratch that one off the list. One thing that should be addressed is some of them being in mid air.

I'm going to commit a fix to the lights for Orbiter Beta, that shouldn't impact Orbiter 2016, but if anyone running 2016 notices any change please let me know.

 

[DaveS]

They are at different distances, both comparing latches at one end, as well as comparing adjacent latches. But if there isn't enough info on them, then scratch that one off the list.

What we have now is correct. This is due to the general shape of the doors as well that the doors do not have a uniform width, that the left door is shorter than the right door, so that the centerline is shifted to the left. Due to the compound curvature of the forward fuselage, the forward bulkhead latches are pushed inboard when compared to the the aft bulkhead latches.

 

[GLS]

What we have now is correct. This is due to the general shape of the doors as well that the doors do not have a uniform width, that the left door is shorter than the right door, so that the centerline is shifted to the left. Due to the compound curvature of the forward fuselage, the forward bulkhead latches are pushed inboard when compared to the the aft bulkhead latches.

I was refering to the gap between the latches and the internal PLBD structure.

 

[DaveS]

I was refering to the gap between the latches and the internal PLBD structure.

Are you talking as seen from the side? You're talking about the length of the rollers on the bulkheads? Those are pure guesswork. I have never found any dimensional data on them, so they're made to look as close as I could get them.

 

[GLS]

Are you talking as seen from the side? You're talking about the length of the rollers on the bulkheads? Those are pure guesswork. I have never found any dimensional data on them, so they're made to look as close as I could get them.

Yes.
Then, IMO they just be attached to the bulkheads and not be hitting the PLBDs. :shrug:

---------- Post added at 10:16 PM ---------- Previous post was at 09:25 PM ----------

Running the SRB ticket issues again reminded me of asking: are the segments and fwd skirt all different, or do some exist only to load a different texture? If so, then we could specify the texture in the mission file and save space and editing time, and gain more flexibility in the textures. This saving probably would only work with the fwd skirt, but still we could use this logic to load other textures in the other segments.

 

[DaveS]

Yes.
Then, IMO they just be attached to the bulkheads and not be hitting the PLBDs. :shrug:

---------- Post added at 10:16 PM ---------- Previous post was at 09:25 PM ----------

Running the SRB ticket issues again reminded me of asking: are the segments and fwd skirt all different, or do some exist only to load a different texture? If so, then we could specify the texture in the mission file and save space and editing time, and gain more flexibility in the textures. This saving probably would only work with the fwd skirt, but still we could use this logic to load other textures in the other segments.

AFAIK, there's no differences, except for the aft segments (pre-STS-51L used 270° original design ET Attach Ring (ETAR) while the post-STS-51L used the 360° redesign). The FWCs are of course different.

---------- Post added at 11:45 PM ---------- Previous post was at 11:25 PM ----------

I'm going to commit a fix to the lights for Orbiter Beta, that shouldn't impact Orbiter 2016, but if anyone running 2016 notices any change please let me know.

I think it was better before as now the panels are completely washed out by the PLB lights. It seems to be a D3D9Client issue but who knows when they'll get around to releasing a fix.

 

[GLS]

AFAIK, there's no differences, except for the aft segments (pre-STS-51L used 270° original design ET Attach Ring (ETAR) while the post-STS-51L used the 360° redesign). The FWCs are of course different.

Hmm, then we could use a similar scheme to the tails in the OV. We could show/hide the attach ring as needed, and also the stiffener rings and foam. That way one aft segment could do original design, 2 stiffener rings with foam, 3 rings, and RSRM. The fwd skirt would also be able to look like anything needed.

So, we would end up with:
- 1 full set of meshes exclusively for FWC;
- 1 full set of meshes for SRM/RSRM (which we could call "SRB_xyz_segment"), with the aft segments having both ET attach ring designs in separate groups, and same for stiffener rings and foam;

Is it a plan?
If so, and so we don't develop tons more stuff and delay the release even further, I say no new textures. For now we'll live with what we have. The mesh work should be easy. (I could do it :shrug

---------- Post added at 10:55 PM ---------- Previous post was at 10:50 PM ----------

I think it was better before as now the panels are completely washed out by the PLB lights. It seems to be a D3D9Client issue but who knows when they'll get around to releasing a fix.

Well, I only set the property so they are visible both in the external and internal views (default seems to be external-only in MOGE, and all in D3D9). Are there any differences between internal and external views?
Anyway I'll post this in the D3D9 thread as something isn't correct behind the curtains.

---------- Post added at 10:55 PM ---------- Previous post was at 10:55 PM ----------

Oh, you did it already.:dry:

 

[Wolf]

I have another question on the vertical stabilizer. As I was adding some textures details I noticed another potential mismatching in the rudder "shaft" (the black metal part where it hinges to the stabilizer). Basically the shaft seems to have a conical shape where the bottom part is smaller than the top part. I thought the shaft was a cilinder (with the same section along its lenght) and went to check some Shuttle drawings where actually it looks conical but it is the other way around than the SSU mesh seems to be (bigger section at the bottom and thinner at the top).
So I am bit lost here and I don't know how to proceed with the texture..

These pics maybe show this better

 

[DaveS]

I think the below screenshot from the AC3D Texture Coordinate Editor will be of help as it shows the mapping of the vertical stabilizer/Rudder-Speedbrake panels.

 

[GLS]

Potentially silly question about the high-res mapping process: is the texture being edited to fit the uv coordinates, or is it the other way around?