|On the pad, ready to go.|
|Pushing throught the first cloud layer.|
|It's nice up here!|
|Looking at the ET over Scotland.|
|Nightside of Earth.|
|Early dawn just after the high heat phase is over.|
|Sunrise during the late entry phase.|
|Scattered morning clouds during TAEM.|
|Light through the top windows playing across the pilot console.|
|Aimed for the Vandenberg runway with HUD de-cluttered early.|
|Safe touchdown in Vandenberg.|
|Sunlight filtering through the cockpit windows.|
|Night illumination based on panel backlighting only, casting a weak ambient light into the rest of the cockpit.|
|Left Commander (CDR) fluorescent panel light.|
|Middle CDR fluorescent panel light.|
|Middle Pilot (PLT) fluorescent panel light.|
|Right PLT fluorescent panel light.|
|Left CDR incandescent ceiling light.|
|Middle CDR incandescent ceiling light.|
|Middle PLT incandescent ceiling light.|
|Right PLT incandescent ceiling light.|
|All panel lights.|
|All lights on.|
As usual, care has to be taken that light intensity is added correctly in physical rather than perception space.
|Leaving the cape.|
|The northward course to a 51 deg inclination orbit goes roughly parallel to the US coast.|
|Passing Newfoundland after the ET has been disconnected.|
|A couple of minutes later we're already in Europe.|
|Crossing over England.|
|Handling the Spartan satellite high above California.|
|Spartan disconnected and floating off.|
|Canada from some 500 km altitude.|
Trying to display that much data all at once is testing new grounds for Flightgear - but the 3d cockpit is progressing well. The basic mesh is based on work by Chris Kuhn, adapted and vertex-reduced by Richard Harrison who also designed the HUD and MDU display structures and code, and animation work is done by Wayne Bragg.
The result is now quite compelling - all forward MDUs are functional and can be controlled via the keyboard units and edgekeys and are capable of displaying the available mixture of GNC (guidance, navigation and control) or SM (systems management) function and MEDS pages.
|The current state of the cockpit during the day.|
|A close-up on the central part of the panel with different DPS functions running on the MDUs.|
|At night, the cockpit instruments are backlit and their soft glow illuminates interior surfaces.|
|Atlantis operating at night with payload bay floodlights on.|
The main challenge of rendering light in the payload bay is that Atmospheric Light Scattering, the rendering scheme of Flightgear giving the best visuals in space, is a forward rendering scheme. This means that lighting is naturally only determined by the relative orientation of a surface to the sun, but objects do not cast shadows. In particular, the payload bay would be illuminated by the sun even with doors closed.
The solution chosen is a number of light and darkmap textures which darken or lighten surfaces controlled by external parameters. In that way, light for all objects in the payload bay can be conditional on the doors being open - while not fully correct, the visuals are nevertheless fairly convincing. The following sequence shows the light distribution when opening the payload bay doors with the sun right in the zenith:
|Doors are closed, payload bay is dark.||The first door openes a crack and lets sunlight in.||As the door opens further, the bay illuminates fully.|
The floodlights are implemented as a series of lightmaps on top of that which each take some time to reach full intensity. The following series show the visuals over the two minutes as the lights are gradually switched on from aft to forward lamp groups:
|Only aft floodlights ramping up intensity.||Aft lights at almost full instensity, mid lights ramping up.||All lights at full intensity.|
Attaching a payload then involves handing a static model of something in the payload bay over to a model that is dynamically translated and rotated based on the position of the arm. Releasing this model into space finally corresponds to a third handover to a model animation that is tied to the Space Shuttle in position and orientation to an equation of motion solver for an independently orbiting object - which nevertheless needs to inherit the same spatial orientation and position its ancestor had.
In reality, the RMS arm can be driven in a number of different modes, making it somewhat easier to attach it to an object. Right now in FG, only the single joint mode (i.e. only one joint angle at a time is driven) is implemented.
After some initial frustration, the system works very nicely however - here is a demo of the Shuttle releasing a stripped-down satellite into orbit while crossing Africa:
|The RMS arm is attached to the payload, ready to lift out.||Payload is lifted while retracting the arm a little to avoid hitting the vertical stabilizer.|
|Arm is almost fully extended.||Payload is released - of course it does not move but just orbits with the Shuttle.|
|Retracting the RMS arm again into cradle position.||Atlantis is ready to depart.|
|A short RCS burn to separate from the satellite...||... and Atlantis is ready to continue with the rest of the mission.|
As a result, the actual thrusters at the different stations almost all point slightly away from the orthonormal directions, the number of thrusters is not the same at every station (in particular, the yaw jets which are crucial for stability during atmospheric entry utilize four different thrusters for redundancy) and the table of thrust components along the body axes is rather messy:
Once this is done, a low-level flight control logic layer is needed which determines which actual thrusters are fired in response to a control input. Such logic also needs to address mode mixing, i.e. the fact that e.g. firing a yaw thruster also induces a roll motion since the thrust axis is not through the center of gravity and a translational motion.
Created by Thorsten Renk 2015 - see the disclaimer and contact information.