Board index FlightGear Development Effects and shaders

Implementing moonlight (or not)

An exciting "new" option in FlightGear, that includes reflections, lightmaps, the particle system etc.. A lot is yet to be discovered/implemented!

Re: Implementing moonlight (or not)

Postby bugman » Fri Dec 18, 2015 9:17 am

Thorsten wrote in Fri Dec 18, 2015 7:38 am:
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.

Regards,
Edward
bugman
Moderator
 
Posts: 1702
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby Thorsten » Fri Dec 18, 2015 11:00 am

and the maximum acceleration of x32 extended to higher values.


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
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Implementing moonlight (or not)

Postby AndersG » Fri Dec 18, 2015 4:23 pm

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.)
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2442
Joined: Wed Nov 29, 2006 9:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: Implementing moonlight (or not)

Postby bugman » Fri Dec 18, 2015 5:03 pm

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.

Regards,
Edward
bugman
Moderator
 
Posts: 1702
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby Thorsten » Fri Dec 18, 2015 5:42 pm

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.
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Implementing moonlight (or not)

Postby bugman » Fri Dec 18, 2015 10:29 pm

Thorsten wrote in Thu Dec 17, 2015 6:16 am:
I'm now looking at replacing all instances of "/environment/moonlight" with "/ephemeris/moon/phase" in the FGData effect


Don't do that directly - moonlight is a non-linear function of phase

Image

so it'd be good to have an intermediate function (even if you make it unity at the moment).


I found where this image was from: LunarLight Photography Technical Information - How Bright is Moonlight? The reference at the bottom looks very promising:

    Krisciunas K. and Schaefer B.E. (1991). A model of the brightness of moonlight, Publ. Astron. Soc. Pacif. 103(667), 1033-1039 (DOI: 10.1086/132921).

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.

Regards,
Edward
bugman
Moderator
 
Posts: 1702
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby MIG29pilot » Sat Dec 19, 2015 1:14 am

What is a foot-candle?
User avatar
MIG29pilot
 
Posts: 1454
Joined: Tue May 19, 2015 4:03 pm
Location: 6 feet under Snow
Callsign: MIG29pilot
Version: 3.7nightly
OS: Windows 10

Re: Implementing moonlight (or not)

Postby wkitty42 » Sat Dec 19, 2015 2:47 am

@mig: you are going to hate me for this but... ask uncle google!

https://www.google.com/search?q=What+is+a+foot-candle?
foot-can·dle
noun
noun: foot-candle; plural noun: foot-candles

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."
User avatar
wkitty42
 
Posts: 5644
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Implementing moonlight (or not)

Postby Thorsten » Sat Dec 19, 2015 6:29 am

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...
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Implementing moonlight (or not)

Postby MIG29pilot » Sat Dec 19, 2015 3:52 pm

wkitty42 wrote in Sat Dec 19, 2015 2:47 am:@mig: you are going to hate me for this but... ask uncle google!

https://www.google.com/search?q=What+is+a+foot-candle?
foot-can·dle
noun
noun: foot-candle; plural noun: foot-candles

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).

Ok I get it. It's sort of like the measurement for density (grams/cm cubed) used for light.
User avatar
MIG29pilot
 
Posts: 1454
Joined: Tue May 19, 2015 4:03 pm
Location: 6 feet under Snow
Callsign: MIG29pilot
Version: 3.7nightly
OS: Windows 10

Re: Implementing moonlight (or not)

Postby wkitty42 » Sat Dec 19, 2015 5:16 pm

yep! :)
"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."
User avatar
wkitty42
 
Posts: 5644
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Implementing moonlight (or not)

Postby bugman » Sat Dec 19, 2015 6:13 pm

I thought foot candles were the candles you make from the wax between your toes? :shock:
bugman
Moderator
 
Posts: 1702
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby MIG29pilot » Sat Dec 19, 2015 7:29 pm

Hopefully you don't have smelly feet
Image
User avatar
MIG29pilot
 
Posts: 1454
Joined: Tue May 19, 2015 4:03 pm
Location: 6 feet under Snow
Callsign: MIG29pilot
Version: 3.7nightly
OS: Windows 10

Re: Implementing moonlight (or not)

Postby bugman » Sat Dec 19, 2015 9:25 pm

More seriously, foot-candles are the US-only ancient British imperial unit, whereas everyone else uses lux (the SI unit).

Regards,
Edward

Edit: These are measures of illuminance.
bugman
Moderator
 
Posts: 1702
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby bugman » Tue Dec 22, 2015 9:04 pm

Image
Image

Hmmm, I'm wondering if the graph at "LunarLight Photography Technical Information - How Bright is Moonlight?" is correct (the 1st graph). The 2nd graph is equation 7, the illuminance of the moon inside the atmosphere, from the paper:

    Krisciunas K. and Schaefer B.E. (1991). A model of the brightness of moonlight, Publ. Astron. Soc. Pacif. 103(667), 1033-1039 (DOI: 10.1086/132921).

The prototyping code (in Python) is:

Code: Select all
from math import pi, sin
from numpy import array

# The zenith angles.
Z = array([0, 10, 20, 30, 40, 50, 60, 70, 80, 90]) / 360.0 * 2 * pi

# Number of phases to plot.
N = 101

# Extinction coefficient.
k = 0.172

# Output Grace file (https://en.wikipedia.org/wiki/Grace_%28plotting_tool%29).
file = open('lux_vs_phase.agr', 'w')

# Loop over the zenith angles.
for i in range(len(Z)):
    # A new graph.
    file.write("@target G0.S%s\n" % i)
    file.write("@type xy\n")

    # Loop over the different phases.
    for j in range(N):
        # The phase (from -180 to 180).
        phase = 180 * (j - (N-1)/2.0) / ((N-1)/2.0)

        # Illuminance of the moon outside the atmosphere.
        I_star = 10**(-0.4 * (3.84 + 0.026*abs(phase) + 4e-9*phase**4))

        # The optical pathlength to the moon (or air mass along the line of sight).
        Xm = (1.0 - 0.96*sin(Z[i])**2)**-0.5

        # Illuminance of the moon inside the atmosphere (equation 7).
        I = I_star * 10**(-0.4 * k * Xm)

        # Convert from foot-candles to lux.
        #I *= 10.7639

        # Write the point out to file.
        file.write("%s %s\n" % (phase, I))

    # Terminate the graph.
    file.write("&\n")


I've used the equations at the start of the discussion section (see http://adsabs.harvard.edu/full/1991PASP..103.1033K). So I guess the top graph has not used the recommended equation for the air mass along the line of sight.

Regards,
Edward
bugman
Moderator
 
Posts: 1702
Joined: Thu Mar 19, 2015 9:01 am
Version: next

PreviousNext

Return to Effects and shaders

Who is online

Users browsing this forum: BLEXBot [Bot] and 10 guests