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

Status
Not open for further replies.

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
I don't know if you are working the OV DaveS, but here's an heads up anyway: I'm merging the TAA meshes, fixing the truss and repositioning the TAA in the PLB, and very likely I'll need to correct the position of the ExtAL (*prays to the Probe to be just that*), and the PLB hatch.
I've actually managed to complete a significant amount of work on the orbiter. I'm a little bit confused by this one though: FRCS nozzles not equal shape (some even are oval!) (should match aft shape) (should all be holes?)
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,878
Reaction score
2,870
Points
188
Website
github.com
*prays to the Probe to be just that*

Clearly I was using the wrong frequency, as my prayers we not answered: several parts are not were they should be... :facepalm::facepalm:

---------- Post added at 03:07 AM ---------- Previous post was at 12:14 AM ----------

I've actually managed to complete a significant amount of work on the orbiter. I'm a little bit confused by this one though: FRCS nozzles not equal shape (some even are oval!) (should match aft shape) (should all be holes?)

(totally missed this post :facepalm:)
Yes, that is a "composite" point.
AFAIK, the RCS nozzles should all have the same basic shape (of course, the PRCS onse are different from VRCS). Some (most?) have that basic shape cut to suit the OML of the vehicle. Like the ellipse section here:
1024px-Conic_Sections.svg.png

That's why the FRCS nozzles look ellipses, not because the nozzle shape is squeezed as we currently have.
Then there is the comparison between the FRCS and ARCS. The ARCS nozzles seem much shallower than the FRCS ones. Plus the fuselage is cut for the FRCS but not for the ARCS, which use those "transparency windows". I think only one solution would be much better. IMO the cuts on the fuselage are much better, but require things to be done well or corrections are a PITA.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
I've checked in an early WIP version of the orbiter mesh. As I had to move some of the mesh groups around, a rebuild is required. I also corrected the positions of the various MPS dump locations.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,878
Reaction score
2,870
Points
188
Website
github.com
I've checked in an early WIP version of the orbiter mesh. As I had to move some of the mesh groups around, a rebuild is required. I also corrected the positions of the various MPS dump locations.
I just took a quick look and I'm sorry to say but you are messing up the forward bulkhead. At least the bottom of the upper (tilted) portion is visually no longer in the same plane as the rest above it. I calculated the coordinates of every single vertex in there, and placed them all so it was planar... what a nice waste of time that was... :facepalm:

Also, both the PLBDs and the NLG doors need to be like this:
attachment.php

The blue vertices (all individual) determine the shape of the doors, and the offset seam must be cut at the correct location (the black lines), resulting in the green vertices, one for each door. Shifting the middle seam means the basic shape of the doors isn't respected, then things don't match, etc, etc, etc....
 

Attachments

  • shifted.png
    shifted.png
    3 KB · Views: 289

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,878
Reaction score
2,870
Points
188
Website
github.com
BTW, DaveS as you are working on the Orbiter.msh file already, the fwd bulkhead hatch should be at Zo357.9, or Y = -1.49644m in the mesh.
I +/- finished the TAA (except for correcting the current oval hatch to a circular one...), and will now work the ExtAL, in which the attach pins don't match anything... :facepalm:

---------- Post added at 08:22 PM ---------- Previous post was at 04:59 PM ----------

It seems the keel pin at the bottom of the ExtAL changed position depending on the position where the ExtAL was.... Not super hard to add another pin and change the code to show the appropriate one, but as it is not in plain sight it seems something good for SSU 5.1, so I'll just create a ticket and for now put the existing pin in the "most flown position".
I've shifted both the TAA and the ExtAL meshes so the hatchways are aligned with the axis, so it becomes much easier to align things vs having the axis in the middle of nowhere.
I didn't do the same to the ODS, as I'm not really in the mood to collect new reference points for the ring animation... another good 5.1 task.... unless Urwumpe, you want to revisit your creation? :p

---------- Post added at 08:42 PM ---------- Previous post was at 08:22 PM ----------

BTW: I didn't mention this before as I thought it was mapping WIP, but I have a white (no texture) PLB and rads in MOGE since the last rev (works in D3D9).
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
BTW: I didn't mention this before as I thought it was mapping WIP, but I have a white (no texture) PLB and rads in MOGE since the last rev (works in D3D9).
Checked in a fixed version. Turned out to be that Paint.NET is now using some unsupported format of DDS. Resaved it using the dxtex.exe utility. Reason number 4546 for the Doc to kill it.
 
Last edited:

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,878
Reaction score
2,870
Points
188
Website
github.com
Just found 2 very motivating things:
1) we have no good hatches (the TAA one is oval and the ExtAL one is mangled, and both have the wrong dimensions);
2) the TAA, which I thought was +/- done, actually has a too-small diameter, which would not be a major problem if it didn't have the cut for the top hatch (which is currently oval, but in the "wrong direction").
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
Checked in a fixed version. Turned out to be that Paint.NET is now using some unsupported format of DDS. Resaved it using the dxtex.exe utility. Reason number 4546 for the Doc to kill it.

During development of treeman, I noticed that MS tools manipulating DDS produce files that are not readable by Orbiter. Turned out that the only thing making problems is a flag in there. This is the function I used to fix this:
Code:
void fixorbiterdds(char *name)
{
    FILE *file=fopen(name, "r+b");
    fseek(file, 10, SEEK_SET);
    fputc(8, file);
    fclose(file);
}
Perhaps this information is helping in some way...
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,878
Reaction score
2,870
Points
188
Website
github.com
In the progress of finishing some standard parts: mating surface for airlock/tunnels/ whatever, hatch frame and (simple, but dimensionally correct) hatch.... except for the "thickness". :uhh:
These will then replace the existing parts. The hatch details (and the specific TAA details) can be added at a later date, without changing the outside shape.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
I just took a quick look and I'm sorry to say but you are messing up the forward bulkhead. At least the bottom of the upper (tilted) portion is visually no longer in the same plane as the rest above it. I calculated the coordinates of every single vertex in there, and placed them all so it was planar... what a nice waste of time that was...
The reason why I moved them was that they created a too long extension, protruding into Bay 1 and the Xo582 ring frame. According to the attached schematic from the Rockwell Intl. Media Resource Kit for STS-9, the lower section of the forward bulkhead is at Xo576. This of course agrees very nicely with the PLBD and Radiator Panel Familiarization Manual which has the doors starting at Xo576.3 and ending at Xo574.09. Even if I move the entire bulkhead mesh so that the bottom is at Xo576.3(Z=9.6086), the top is at Xo571.5(Z=9.7229). That is 2.59 inches or 0.065786 m off. So something has to change here, in my opinion it is the mesh.
 

Attachments

  • STS9_Rockwell_MRK_airlock_stations.jpg
    STS9_Rockwell_MRK_airlock_stations.jpg
    216.8 KB · Views: 184

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,878
Reaction score
2,870
Points
188
Website
github.com
The reason why I moved them was that they created a too long extension, protruding into Bay 1 and the Xo582 ring frame. According to the attached schematic from the Rockwell Intl. Media Resource Kit for STS-9, the lower section of the forward bulkhead is at Xo576. This of course agrees very nicely with the PLBD and Radiator Panel Familiarization Manual which has the doors starting at Xo576.3 and ending at Xo574.09. Even if I move the entire bulkhead mesh so that the bottom is at Xo576.3(Z=9.6086), the top is at Xo571.5(Z=9.7229). That is 2.59 inches or 0.065786 m off. So something has to change here, in my opinion it is the mesh.

Effectively, the "bulkhead" that we see is just blankets, except for the margin on the top half (part of the upper forward fuselage structure), which has the forward tilt. The crew module Xo576 wall is the only (metal) bulkhead there, and it being vertical means the gap between it and the "tilted margin" decreases as we move up, unlike that (simplified) diagram, and most others.

When I positioned the bulkhead (especially the bottom half), I chose not to "sink in" the lower end, because "how much should it go in?", and "how does that then meet the top half?". It creates some issues, the obvious ones are the forward-most PLB ring being half-buried, as well as the a tunnel/TAA attaching to the hatch opening, but there is really no good way of doing this without making a mesh group with a grid of points and fiddling with it until it has the shape of the blankets... maybe not a priority when big things don't fit each other, there visible gaps here and there, pad FPS performance isn't that great, etc... :shrug:
Long story short: the outside bulkhead shape at the top, and the fwd end of the PLBDs, should be good as I left it, the inside/middle area and bottom half are a bit aft as I didn't model the blankets, which sink forward, bridging the gap to the Xo576 bulkhead.

Also, I didn't make the corners of the PLBDs curved, as it was too much work for little gain. Otherwise, I think it was all squared away in terms of structure at the fwd end.

---------- Post added at 07:41 PM ---------- Previous post was at 07:27 PM ----------

On my end: ended up remaking the TAA structure, at there was no way to correct the oval hatch opening to the correct round shape. :facepalm:
The "standard parts": basic hatch, hatch frame and the ring to connect the tunnels/AL/TAA/whatever are pretty much done, and I'm now copying the hatch-mouted parts, from the only round hatch we have to the new hatch, as those parts are usable.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Effectively, the "bulkhead" that we see is just blankets, except for the margin on the top half (part of the upper forward fuselage structure), which has the forward tilt. The crew module Xo576 wall is the only (metal) bulkhead there, and it being vertical means the gap between it and the "tilted margin" decreases as we move up, unlike that (simplified) diagram, and most others.
The MLI blankets covering the bulkhead isn't that thick, not even an inch. From what I can tell, they're at most maybe quarter-inch thick.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,878
Reaction score
2,870
Points
188
Website
github.com
The MLI blankets covering the bulkhead isn't that thick, not even an inch. From what I can tell, they're at most maybe quarter-inch thick.

The blankets aren't flush against the surface. If you look at a photo without the blankets, you will notice that the handrails have very long "legs", but with the blankets they actually look "normal".
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
The blankets aren't flush against the surface. If you look at a photo without the blankets, you will notice that the handrails have very long "legs", but with the blankets they actually look "normal".
This is true but as we have flat surfaces (we're not modelling the wrinkles in each blanket) we have to average things out. A good point is the forward bulkhead latch rollers, they're attached directly to the frame. The white section isn't a blanket, but rather some kind thermal protective shield that is very thin. And also looking closely at photo of Endeavour's Xo576 bulkhead from when she had her internal airlock converted into the external airlock with the blankets removed, it looks like the part of the lower frame that the handrails and other hardware is attached to, is actually inset from the rest. That explains why the schematics that focuses on the area around the airlock interface list things as Xo576 while the PLBD And Radiator Panel Familiarization Manual lists the doors as starting at Xo579.3 at the hinge line.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,878
Reaction score
2,870
Points
188
Website
github.com
This is true but as we have flat surfaces (we're not modelling the wrinkles in each blanket) we have to average things out. A good point is the forward bulkhead latch rollers, they're attached directly to the frame. The white section isn't a blanket, but rather some kind thermal protective shield that is very thin. And also looking closely at photo of Endeavour's Xo576 bulkhead from when she had her internal airlock converted into the external airlock with the blankets removed, it looks like the part of the lower frame that the handrails and other hardware is attached to, is actually inset from the rest. That explains why the schematics that focuses on the area around the airlock interface list things as Xo576 while the PLBD And Radiator Panel Familiarization Manual lists the doors as starting at Xo579.3 at the hinge line.

So you fix an error, or modeling deficiency, by making another error (shifting the fwd bulkhead forward)? Then the PLBDs, forward fuselage will be wrong, and the forward bulkhead still won't be correct... I guess this policy worked well in the past, as we now see. :shrug:
The way I left it, only the fwd bulkhead needed future work, all the rest was in the right place, but if you want to zig-zag from problem to problem instead of moving forward, you are free to do it.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
So you fix an error, or modeling deficiency, by making another error (shifting the fwd bulkhead forward)? Then the PLBDs, forward fuselage will be wrong, and the forward bulkhead still won't be correct... I guess this policy worked well in the past, as we now see. :shrug:
The way I left it, only the fwd bulkhead needed future work, all the rest was in the right place, but if you want to zig-zag from problem to problem instead of moving forward, you are free to do it.
In my mind, there's got to be a compromise somewhere. And I think that compromise is to put the mesh so that the bottom frame connects with the forward edge of the Xo582 ring frame. And it just so happens to be at Xo579.04. That's 0.26" off but we'll chuck that up to MLI blanket thickness uncertainty. Another change I'll make on my end is using your bulkhead mesh, just moved to this new position. I won't change the upper frame at all.

Edit:
This solution will make things agree with photos which shows that the even with the MLI blankets, the bulkhead doesn't protrude beyond the forward edge of the Xo582 ring frame. In the future when it comes to things like this, I'd like to establish the ground rule that photos have the final superior say.
 
Last edited:

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,878
Reaction score
2,870
Points
188
Website
github.com
In my mind, there's got to be a compromise somewhere. And I think that compromise is to put the mesh so that the bottom frame connects with the forward edge of the Xo582 ring frame. And it just so happens to be at Xo579.04. That's 0.26" off but we'll chuck that up to MLI blanket thickness uncertainty. Another change I'll make on my end is using your bulkhead mesh, just moved to this new position. I won't change the upper frame at all.
The way I see it, or we keep things as they are, and accept that half of the forward ring, a bit of the TAA, and maybe some parts of the fwd bulkhead equipment (but not the rollers, as they are on the "margin", which is correct) will be partially buried in the bulkhead, until we come up with a bulkhead model that sinks forward in the top middle and bottom, OR, we do it now. Moving the bottom at all, will mean it doesn't meet with the top at the "bend", so we'll either have a step there or will also have to move the top as well, and that means moving the PLBDs and forward fuselage (IMO not acceptable).
I vote leave as is, as we have bigger fish to fry right now, but do what you want.

Edit:
This solution will make things agree with photos which shows that the even with the MLI blankets, the bulkhead doesn't protrude beyond the forward edge of the Xo582 ring frame. In the future when it comes to things like this, I'd like to establish the ground rule that photos have the final superior say.
Yes, and diagrams with numbers don't matter. :facepalm: That's why I spent the day remaking the TAA...
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
The way I see it, or we keep things as they are, and accept that half of the forward ring, a bit of the TAA, and maybe some parts of the fwd bulkhead equipment (but not the rollers, as they are on the "margin", which is correct) will be partially buried in the bulkhead, until we come up with a bulkhead model that sinks forward in the top middle and bottom, OR, we do it now. Moving the bottom at all, will mean it doesn't meet with the top at the "bend", so we'll either have a step there or will also have to move the top as well, and that means moving the PLBDs and forward fuselage (IMO not acceptable).
I vote leave as is, as we have bigger fish to fry right now, but do what you want..
I've attached a photo of Columbia during final assembly with just the two forward fuselage halves joined with the midbody. The area I'm talking about is the one I've circled. So without the blankets, the inset is fully visible, but with the blankets installed it forms a flat (if you have average the wrinkles out) surface which hides the inset. The doors doesn't see this, they only see the outer section where the rollers are. So the inset is only inboard of the PLB sills, at Yo94 at the widest point.
 

Attachments

  • OV102_Xo576_blkhd_inset_area.jpg
    OV102_Xo576_blkhd_inset_area.jpg
    155.9 KB · Views: 152

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
I didn't do the same to the ODS, as I'm not really in the mood to collect new reference points for the ring animation... another good 5.1 task.... unless Urwumpe, you want to revisit your creation? :p
As I wrote in my reply to ticket#120, BrianJ has created exactly what we need for his Scientific Airlock (SAL) add-on. Maybe it would be a good idea to contact him to see if he would be interested in sharing the code for it?
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,878
Reaction score
2,870
Points
188
Website
github.com
As I wrote in my reply to ticket#120, BrianJ has created exactly what we need for his Scientific Airlock (SAL) add-on. Maybe it would be a good idea to contact him to see if he would be interested in sharing the code for it?
From what I saw, it was done with shifting the meshes... not sure it would work for us with all the animations we have, plus payloads... :shrug:

---------- Post added at 08:40 PM ---------- Previous post was at 02:36 PM ----------

Is there a Zo number for the ODS structural ring (the large flat on with the hooks, where we define the docking position)? I have a Zo462.72 but it's for the retracted position of the capture ring, which is a bit lower than the mate ring... I'll use it if nothing else shows up, as the ODS position error already came down quite a bit in the last few days.
Currently all hatchways and trunnion pins are lined up, except for the vertical position of the ExtAL top hatch, the vertical position of the ODS (didn't toch that mesh), and longitudinal position of the ExtAL hatchways (didn't change them). Didn't correct the ExtAL body as it will take tons of time and now with the docking port and trunnion pins in the correct positions, the problems are pretty much "internal".
The way I'm planning to correct the ODS structural ring position is by shifting the top position of the ExtAL to meet the new position of the ODS, and because I have no data on the ODS segment height, I'll assume it is OK for now. Shifting the top of the ExtAL about 4cms doesn't hurt anything, and actually makes it look better as the end of the connical section should be +/- at the top of the truss, so it will still be wrong, but "less wrong". It's the best I can do short of fixing the whole thing and burning a week or 2 in the process. :shrug:
Anyway, with the ODS in the correct place, using the RMS for things on the ISS shouldn't have a large error in the joint angles displayed vs the checklists.
 
Status
Not open for further replies.
Top