News The Space Shuttle for Flightgear 3.6

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
I can't resist showing those. Wayne has made it is personal quest to implement the lighting of the Shuttle cockpit as it really works (and even extended the GLSL shader to support more light sources to get it done).

Now every single button and rotary knob adjusts light as it should be - all dim switches are working, it's possible to change instrument lighting as well as back-lighting of the labels, operate the fluorescents and the incandescents independently... it's pretty much a work of art (I dare say it's the most sophisticated light concept for any cockpit in Flightgear).

Glareshield light on and panel backlights off CDR side, panel backlights on PLT side:

shuttle_lightmap_full01.jpg


We could do some work on the lamp objects themselves, right now there's just the emissivity dialed up, but I know the GLSL magic to make lights look like lights - the illuminated console PLT side:

shuttle_lightmap_full02.jpg


Details with shadows from two different light sources criss-crossing (MDUs are also dimmed compared with the previous shots):

shuttle_lightmap_full03.jpg
 

Donamy

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Oct 16, 2007
Messages
6,924
Reaction score
232
Points
138
Location
Cape
Are the shadows baked on the texture, or are they actually from the light source ?
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
They're multi-channel lightmaps generated by a ray tracer run over the cockpit 3d mesh - in my view the technique that will give the best possible visuals.

Edit: In case the tech word 'multi-channel lightmap' isn't clear to everyone - the shadows appear, disappear and dim along with the lights - although the light scattering through the flightdeck (shadows, diffuse reflection,...) is computed offline and then tabulated, light intensity, addition and application to the surface are done runtime. So switching a ceiling light on in the above scene would weaken the existing shadows where the light reaches them and potentially create new ones.
 
Last edited:

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
This might be an odd request, but does anyone know of a 3d model of a spacesuit helmet from the inside that would have a GPL-usable license?
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
Been busy with the nuts and bolts of the thermal simulation of the hydraulics system. The basic idea is that hydraulic fluid can get sticky and freeze, so it needs to be circulated now and then, otherwise no joy in using airfoils during entry...

The system how to keep it warm is actually quite neat, hydraulic fluid passes a heat exchanger with the hot part of the freon loop.

The simulated model is fairly crude, but it does get plausible distributions (and illustrates the need for putting the heat exchanger in...)

DISP 87 is used to monitor it all:

Shuttle_avionics_DISP87.jpg


(and no temperature or pressure is fake - they all show the real state of the simulation - the display would also show blown tires and the friction coefficient of a blown tire would be different from a rolling one on the runway, leading to a yawing moment during rollout).

For the test in the screenshot, I've not circulated hydraulic fluid in sys1 for several hours, hence the readings are in thermal equilibrium with the orbiter fuselage - the sun-exposed parts are fairly warm, the shadowed parts are chilly (i.e. you can read off simulated orbiter attitude with respect to the sun from the display). Now circulation pump 1 is struggling to get it all back into shape....

I have to say, it's quite instructive to learn why all the systems aboard the Shuttle work the way they do.
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,231
Reaction score
618
Points
128
For the test in the screenshot, I've not circulated hydraulic fluid in sys1 for several hours, hence the readings are in thermal equilibrium with the orbiter fuselage - the sun-exposed parts are fairly warm, the shadowed parts are chilly (i.e. you can read off simulated orbiter attitude with respect to the sun from the display).

How accurate is the radiative heating simulation? Is that part of any library for FlightGear or did you have to develop that yourself with the position of the sun etc.?
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
How accurate is the radiative heating simulation? Is that part of any library for FlightGear or did you have to develop that yourself with the position of the sun etc.?

It's a radiative balance of various elements each characterized by an orientation and a visible albedo. They're characterized by a mass and heat capacity which gives them thermal inertia, and they're connected by couplings which allow heat to diffuse from the hot to the cold element. Some of them (the avionics bays in particular) have internal heat sources dumping additional heat at a given rate, whereas for instance the evaporators are internal heat sinks.

The physics is fairly sound - the parameters used of course are guesstimates and the model of the Shuttle is fairly crude since I have no real data on what the numerical values of the thermal couplings are.

So the accuracy is limited by the input data rather than the computation.

And, to be fair, hydraulic line temps aren't computed directly in the radiative balance model - they're determined from it by assuming we have a local degree of equilibration of the hydraulic fluid with the surrounding material dependent on how much circulation and mixing has been going on.

And I wrote the code myself - at one part I inquired whether others were interested to re-factor it as a common library, but that didn't materialize - thermal management isn't such an issue for most airplanes...) - the structure is fairly generic though.
 
Last edited:

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,231
Reaction score
618
Points
128
Impressive, that is even more advanced than what NASSP does with the Command/Service Module. Only radiative heating is simulated there, not conductive heat transfer between different parts of the spacecraft. So you do have to perform Passive Thermal Control (aka barbecue mode), so that certain systems are not overheating or freezing. The CM RCS helium tanks actually depend on conductive heat from the CM interior, so there are fake heaters simulated to keep the temperature within the allowable range.

There usually is logic implemented so that subsystems don't work if their fluids are below freezing temperature, but even that seems more advanced in the Flightgear Space Shuttle. So I guess I'll have to take a look at your source code some time. :lol:
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
So I guess I'll have to take a look at your source code some time.

Feel free to ask for pointers.

Just keep in mind it's really not the equivalent of a dll or so (aka, a more or less self-containted piece of C++ code). FG has the concept of the property tree to which all sorts of things get access, so the systems simulation is shared across

* 3d model definitions taking care of button animations etc.
* JSBSim tags doing the low-level systems simulation
* scripted subsystems handling high-level stuff

and they don't have any explicitly declared connections, because they're all allowed to read and write properties

Needs some time getting used to understanding how it ties together, but it's actually pretty neat - for instance in the AP codes, JSBSim tags do the fast, low level attitude control etc, whereas scripted systems do high level decisionmaking (what phase of the abort are we in actually), and while the low-level stuff runs 120 times per second, the decisionmaking logic runs a lot slower.

The radiative balance is largely a scripted subsystem, but the systems it talks to (valves, fans, coolant pumps, radiator,... are not scripted but JSBSim tags.
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
This is basically a silly thing... to do a post-MECO propellant dump manually, you have control over propellant fill/drain valves.

So... what would happen if you're dumb enough to open both inboard and outboard valve on the pad, ready for launch, is presumably this:

shuttle_drain.jpg


You'd drain the ET.

It all raises the question how much off-nominal handling the simulation should accomodate - because since there are so many things crazy you could really do, accounting for all of them is quite expensive.

And the more complex you make a simulation, the more prone to silly things it gets (think of trying to disconnect SRBs three seconds after liftoff, of trying to lower gear in the upper atmosphere, of trying to close payload bay with the Ku-antenna out, trying to open payload bay doors after max. heating, opening the cabin vent valves till all air is gone... possibilities are endless...)

On the other hand, one of my first experiences in FG was that I managed to memorize the engine startup sequence for the A-10, taxied to the runway, took off, switched to external view to take a nice screenshot - and saw that I had the canopy still open! I always felt I shouldn't have been able to do that.

So I usually try to catch a modest amount of the more likely silliness - also just because people never read the manual, and I don't want them to get away with skipping checklists easily.
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
Happened to see this during a late evening launch from the Cape and thought it looked really cool

morning_launch.jpg


(it's during second stage ascent, the ET is attached but in darkness...)
 

C3PO

Addon Developer
Addon Developer
Donator
Joined
Feb 11, 2008
Messages
2,605
Reaction score
17
Points
53
It all raises the question how much off-nominal handling the simulation should accomodate - because since there are so many things crazy you could really do, accounting for all of them is quite expensive.

How about a giant fireball in external view, and the inside of a black box in internal view in case of an off-nominal switch combo and then delete the vessel? You don't have to model every possible scenario. You only need enough to convince the user that it will be quicker to RTFM than to push random switches.
Take two or three switches that never should be On (or Off) simultaneously in normal operation and have the switch combo trigger the event. A few sets of "triggers" should be enough to... ehrm... guide the user to the correct path.
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
From reading through some of the contingency abort training sessions, there's usually a reason why there are buttons to do off-nominal things. So it's a bit of a fine line to walk - whether some manuever is a good idea or not may depend on whether it happens to remain within structural limits or not.

For instance, deploying gear early is a viable substitute for a stuck speedbrake. The SRB sep button is there in case there''s an actual problem with a booster (that leaves you alive, that is).

I actually have a couple of 'you're really screwed' visualizations by now - the big fireball, breakup into a debris shower during entry, wing ripped off and tumbling through the atmosphere, all avionics and lights gone,...

As for guiding users though...

- 'Hey, my Shuttle always explodes on ascent, something must be wrong.'
- 'Did you follow the checklist?'
- 'What checklist????'
- 'The in-sim checklist mentioned by the on-screen message at startup of the simulation.'
- 'Ah no. But why can't this just work?'
- 'Because it's supposed to be a realistic simulation.'
(...)
- 'Okay, now it explodes later'
- 'Did you continue to follow the checklist?'
- 'You mean I really have to do all of it???'
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
I have a long-standing fascination for the interaction of light with the atmosphere and how to approximate it sufficiently well to get it into a real-time renderer. In particular, sunrises and their colors are a challenge.

Here are some new visuals of sunrises under various conditions (time, aerosol content of the atmosphere,...) seen from space in my Earthview renderer after tinkering a bit with the algorithms (still has a few quirks to be ironed out, but it's going where I want it to...)

(Magnify the images for best effect, by nature they're rather dark and the contrast against the bright forum background isn't terrific).

space_sunrise01.jpg


space_sunrise02.jpg


space_sunrise03.jpg


space_sunrise04.jpg


space_sunrise05.jpg



... and a hint of aurora visible just before sunrise:

space_sunrise06.jpg


In case I never mentioned it -GLSL is way cool.
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
Flight testing the devel version in preparation of a stable milestone - some impressions.

shuttle_1001_nights.jpg


shuttle_ch.jpg
 

Donamy

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Oct 16, 2007
Messages
6,924
Reaction score
232
Points
138
Location
Cape
Needs more glow on the belly tiles and and RCC. IMOH
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
Yeah, it does. Right now it's fiddling with the emissive channel, which doesn't give compelling output for a near-black texture, so it's scheduled for some GLSL trickery to produce an actual blackbody spectrum glow.
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
A major update of the project page in preparation of the official stable milestone-7 rollout with the next FG 'Zurich' release.

Some promotional shots to enjoy:

shuttle_feature28.jpg


shuttle_feature29.jpg


shuttle_feature24.jpg


shuttle_feature25.jpg


shuttle_feature34.jpg


shuttle_feature30.jpg


shuttle_feature19.jpg


shuttle_feature21.jpg


shuttle_feature22.jpg


shuttle_feature27.jpg


shuttle_feature35.jpg
 
Top