Space Shuttle Ultra 1.25 Revision B development

[DaveS]

Can you get some more data on the operations?

And for something else: Can you produce a KSC worker mesh? with a small radio comm in his hand? So we can visualize the observers

1: Will try. I'll see if I can get in touch with someone in the Transporter group at KSC.
2: Maybe Donamy could do that? My human modeling skills are currently non-existent.

Now over to the latest workings on the VAB. I think I finally have nailed down the basic design of the xfer aisle crane. Still have to do the thing that gives me the most trouble, the hoist trolley.

Now over to a question on the crane: Anyone know the real color of the xfer aisle crane? Most photos show it as a bright yellow color, while some other photos show it as having some kind of variation of Safety Orange(http://en.wikipedia.org/wiki/Safety_orange).

 

[DaveS]

I was just thinking, if any one of you would like to get the SSU code ready for assembly ops, I could check in a VAB that has dummy cranes but mostly completed structure.

The visual accuracy would be low, but it would be enough to get the ball rolling in teh right direction.

Here's a nice document that deals with the last major assembly op, S0004(Orbiter/ET mate): http://edgd.asee.org/conferences/proceedings/GaryGodfrey.pdf

 

[Urwumpe]

Well, could even be done maybe without HUGE modifications to the code: if my brain is not completely wrecked, the best approach would be making an "STSStack" vessel, which is just the ET and the SRBs in the various assembly stages. The Orbiter would then assimilate the STSStack vessel when it is mated, switches its configuration to zero (or below) and attach itself to the MLP instead.

So, the reset would be the critical part, but the early assembly stages would be done with a separate vessel, which would maximal use SSU classes in the software.

 

[DaveS]

Well, could even be done maybe without HUGE modifications to the code: if my brain is not completely wrecked, the best approach would be making an "STSStack" vessel, which is just the ET and the SRBs in the various assembly stages. The Orbiter would then assimilate the STSStack vessel when it is mated, switches its configuration to zero (or below) and attach itself to the MLP instead.

So, the reset would be the critical part, but the early assembly stages would be done with a separate vessel, which would maximal use SSU classes in the software.

OK. I'll begin to make the SRBs stackable by making each segment a separate mesh.

---------- Post added at 02:16 PM ---------- Previous post was at 11:00 AM ----------

OK, left SRB have been segmented up(aft, aft center, forward center, forward, forward skirt assembly). Now how do you want them? Do you want each segment to be sitting at 0,0,0? Currently they're at the points where the real segments are in the completed SRB.

For the moment, they're of the STS-1 SRBs.

 

[Urwumpe]

OK, left SRB have been segmented up(aft, aft center, forward center, forward, forward skirt assembly). Now how do you want them? Do you want each segment to be sitting at 0,0,0? Currently they're at the points where the real segments are in the completed SRB.

For the moment, they're of the STS-1 SRBs.

Better centered at 0,0,0. I think we also want to transport the SRB segments one day.

 

[DaveS]

Better centered at 0,0,0. I think we also want to transport the SRB segments one day.

Already on it, I'm creating the SRM segment lifting sling now. Should have it done pretty soon.

---------- Post added at 03:39 PM ---------- Previous post was at 03:29 PM ----------

If you want you can get the VAB vessel ready as the High Bay doors are ready to be animated. It's just the dummy cranes that are missing. Once the SRM lifting sling is done I'll check in the individual segments+sling.

 

[Urwumpe]

If you want you can get the VAB vessel ready as the High Bay doors are ready to be animated. It's just the dummy cranes that are missing. Once the SRM lifting sling is done I'll check in the individual segments+sling.

Ok. Would also have to look how the performance of such a big mesh is, maybe I can optimize some things.

 

[DaveS]

Ok. Would also have to look how the performance of such a big mesh is, maybe I can optimize some things.

Currently the VAB has 59371 surfaces and 66478 vertices.

There's no getting around the fact that the VAB has alot of surfaces. Most of them is the actual interior structure, the X, vertical and horizontal beams.

 

[Urwumpe]

Currently the VAB has 59371 surfaces and 66478 vertices.

There's no getting around the fact that the VAB has alot of surfaces. Most of them is the actual interior structure, the X, vertical and horizontal beams.

Yes, but practically speaking, not all are visible at any state of the VAB doors, at any camera position or any distance. Especially at some distance away, like on the launch pad, it makes little sense rendering all.

 

[DaveS]

Yes, but practically speaking, not all are visible at any state of the VAB doors, at any camera position or any distance. Especially at some distance away, like on the launch pad, it makes little sense rendering all.

How do you propose we deal with this problem? For Project Apollo, this was half-solved by making the interior a vessel along with the doors and cranes, while the exterior was a static object, like it is now.

Just do some facts: One of the square X sections are 11.57 mX11.57X0.65m, so they're pretty big like everything else in it! There's not many small items in that building.

 

[Urwumpe]

How do you propose we deal with this problem? For Project Apollo, this was half-solved by making the interior a vessel along with the doors and cranes, while the exterior was a static object, like it is now.

For example like that.

Just do some facts: One of the square X sections are 11.57 mX11.57X0.65m, so they're pretty big like everything else in it! There's not many small items in that building.

Still, they could be easily replaced by a vacuum, if you are so far away that the bars of the X section become less thick than a half-pixel at current FOV and 1080 pixel screen height.

If they are 0.65m thick for example, they are only 40 pixel high at 10° FOV and 100m distance. At 8000m distance at this field of view already, they would be practically "invisible". At 40° FOV, the distance would be just 2000m.

 

[DaveS]

For example like that.




Still, they could be easily replaced by a vacuum, if you are so far away that the bars of the X section become less thick than a half-pixel at current FOV and 1080 pixel screen height.

If they are 0.65m thick for example, they are only 40 pixel high at 10° FOV and 100m distance. At 8000m distance at this field of view already, they would be practically "invisible". At 40° FOV, the distance would be just 2000m.

True. If we go with the interior only as a vessel solution, it would be the optimal solution as then it would only be loaded for scenarios that require it(rollovers, matings, rollouts and rollbacks).

 

[Urwumpe]

True. If we go with the interior only as a vessel solution, it would be the optimal solution as then it would only be loaded for scenarios that require it(rollovers, matings, rollouts and rollbacks).

yes, and if we have it, we can still use simple logic to reduce the number of visible triangles, for example by not showing all or showing lower resolution meshes. I am sure, at some distance away, we could replace the VAB interior by a hemicylindrical depression along the VAB doors, with suitable texturing.

EDIT: I just do some work on the IMUs and MDMs, maybe I can finally commit something again today. The current release of the SCOM finally has the missing pages of the IMU chapter...

I fear we might need some code improvements for doing a complete post-mission turn around with the Orbiter, there could be some CTD sources when adding a new ET/SRB. The sooner we can get away from the hard coded data inputs (eg, ET propellant mass) to abstracted sensors, the better for this.

 

[DaveS]

yes, and if we have it, we can still use simple logic to reduce the number of visible triangles, for example by not showing all or showing lower resolution meshes. I am sure, at some distance away, we could replace the VAB interior by a hemicylindrical depression along the VAB doors, with suitable texturing.

I don't think it will be necessary, the exterior elements alone only comes at 927 surfaces and 1731 vertices.

 

[Kyle]

Bit of a question. When Rev. B comes out, what major changes are we to expect whenever it comes out?

Thanks.

 

[DaveS]

STS-1 left aft SRM segment with the nearly completed lifting sling:

 

[Urwumpe]

Bit of a question. When Rev. B comes out, what major changes are we to expect whenever it comes out?

Nothing big, expect mostly under the hood changes. The VAB is the biggest visual change you can likely expect. As far as I see it, a large part of the work will go into organizational stuff and fixing the various bugs of 1.25

 

[Donamy]

Hopefully we'll see the SSME's able to stow and the KU gimbal. :shifty:

 

[DaveS]

Both STS-1 SRBs have been checked in, ready for stacking. As well as the SRM segment sling. Now back to the VAB and after that, the STS-1 ET.

Edit:
Speaking of STS-1, could we have a toggle for the Ku antenna? It wasn't flown on missions 1 through 7. Although Challenger was delivered to KSC with her Ku antenna installed, it was removed during the STS-6 OPF flow. And Columbia didn't fly with it until STS-9.

 

[Urwumpe]

Yes, would be possible to add in the mission file, can be addressed with the rest of the configuration change stuff.