you can always accelerate simulator time and/or reposition your vehicle at run-time.

Only if your underlying trajectory simulation code is numerically stable enough to do that. Which JSBSim was never tested for if I remember Jon correctly.

An FDM simulating real orbital mechanics, which properly handles the three-body problem, is required for any moon adventures. Then the FlightGear time acceleration framework would be useful (the [a]/[A] buttons), and the maximum acceleration of x32 extended to higher values. But the orbital mechanics is currently missing. It needs to be implemented in JSBSim. Or in a new orbital/space FDM which can be hot switched to on the FG side. In any case, there is a lot of work ahead.

Yeah, that's just the catch with orbital mechanics. The multi-body orbital codes I've been writing really are sensitive to the timestep - if you increase it by a factor ten, you're getting more than a factor ten worse. So even if you have a code and can run it with 32x time acceleration, it's not a given that you can run it with 10.000x time acceleration.

Thorsten wrote in Fri Dec 18, 2015 7:38 am:Only if your underlying trajectory simulation code is numerically stable enough to do that. Which JSBSim was never tested for if I remember Jon correctly.

The easy way out of that problem is to still run JSBSim with the normal time step length, just more of them per real second - though that will only allow you to accelerate simulation time up to the capacity of your CPU core. For none too complex FDM configurations that should still easily be above 10x.However, IIRC that is not how FG does acceleration today.

(Timing a fixed duration script for an aircraft in an optimized JSBSim/standalone instance should give a hint of how far time could be accelerated with that aircraft.)

Maybe if internal perturbations are disabled when time is not normal, the full trajectory in space could be calculated once and the spacecraft made to follow that pre-determined trajectory. If the trajectory requires zero updates, then accelerated time should not be a major issue. This might be quite contrary to the current design of JSBSim though. Hence why I often mention a SpaceFDM instead. Though maybe JSBSim simply requires a 'mode change' that includes 'sleep states' where the trajectory is only recalculated if there is a perturbation. Anyway, such things should be discussed on the JSBSim development mailing list.

For reference, I can compute half an hour worth of trajectory with reasonable accuracy (I think no more 100 m off for a whole orbit) within approximately a second. So that's a compression factor of ~2000 which I can achieve by just doing lots of timesteps following each other (I think that's a 0.05 s interval). For anything more, you would have to jiggle with the timestep.

A free online version is at http://adsabs.harvard.edu/full/1991PASP..103.1033K. This might give a reasonable formula to go from moon phase to lux (which I can cheaply calculate in the simgear ephemeris code, and expose it in the property tree at "/ephemeris/moon/lux" in the flightgear ephemeris code). Then I'll probably log the lux value to get the scaling value for the GL lighting (placing it at "/ephemeris/moon/log_lux"). This should give the most realistic automatic moon lighting of the scene.

a unit of illumination (now little used) equal to that given by a source of one candela at a distance of one foot (equivalent to one lumen per square foot or 10.764 lux).

"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up.""Why not?" said Gurder."Dunno. It's frightened of heights, I guess."

Then I'll probably log the lux value to get the scaling value for the GL lighting (placing it at "/ephemeris/moon/log_lux"). This should give the most realistic automatic moon lighting of the scene.

Ah - good - you figured out the log thing yourself - I was about to confess that I hadn't included that when talking about the brightness function.

I *suspect* in this intensity regime the log is too simplistic - it is already in the region where intensity perception deviates from the log law - so we might have to fine-tune this somewhere. Also, with residual sunlight in the scene (which you get up to -15 deg sun altitude) and moonlight, the precise law may depend on how to combine correctly...

"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up.""Why not?" said Gurder."Dunno. It's frightened of heights, I guess."