Re: Planetshine
Posted: 01.04.2008, 22:53
Cross-posted from the developers list
Here's a rather large patch against the current SVN version of Celestia that implements secondary illumination:
http://www.celestiaproject.net/~claurel/celest ... hine.patch
Problems have been reported with the patch file; you may want to use this zip archive with all the changed files instead:
http://www.celestiaproject.net/~claurel/celest ... tshine.zip
For testing purposes only, planetshine can be toggled on and off with Ctrl+X (antialias lines.) This toggle will be removed before the code is committed to SVN.
The patch includes a significant cleanup and streamlining of
Celestia's lighting code; it simply wasn't practical to implement
secondary illumination /without/ this cleanup. The performance
benefits from this cleanup should more than compensate for the extra
computation required for secondary lighting.
I've worked hard to make Celestia's implementation of secondary
illumination both fast and general. Secondary illumination can come
from objects that aren't in the same 'system'. Thus the Cassini
spacecraft can be lit by light reflected from Earth, Venus, Jupiter,
Saturn, or any of Saturn's moons even though its orbit is defined
relative to the Sun. This is different how eclipse shadows work:
they're currently only computed for objects in the same system, and so
Cassini will never be eclipsed by Saturn (at least, not until a
subsequent patch addresses the limitation.)
Both reflector phase and reflector-to-receiver distance are accounted
for in the calculation of secondary illumination. There are two ways
in which distance affects the amount of light reaching the receiver:
obviously, the received energy falls off with 1/distance^2. But, the
distance also affects what part of the reflecting object is visible to
the receiver. An object in low Earth orbit like ISS sees only a small
fraction of the Earth's surface at one time, thus using something like
a simple (1+cos(phase))/2 correction to the amount of reflected light
will produce noticeably wrong lighting. The code in the patch uses a
more sophisticated approach that is still an approximation but gives
correct looking results in all cases.
Some limitations:
- All reflecting objects are treated as spheres
- Spacecraft, components, and surface features don't reflect light;
this was done in order to avoid terrible slowdowns with add-ons like
Selden's Hale telescope that have complex assemblies of small models.
And with a mass of irregular objects, the lighting wouldn't be correct
anyway.
- Only the brightest secondary illuminator is considered. This is easy
to fix, but at the expense of performance. It's probably not
worthwhile until HDR support lets us see the effects of very faint
light sources.
- You'll note that Earthshine isn't visible on the Moon; there's an
adjustable 'gamma' setting that would make it visible. Right now, it's
set so that secondary illumination will be visible when it is at least
10^-4 times as bright as the primary illumination. Earthshine on the
Moon is just barely under the cutoff. This gamma value can be
modified, but at the expense of underemphasizing light intensity
differences between more similar light sources. My feeling is that we
should wait for HDR rendering to be more developed before playing with
this value too much.
The best places to see planetshine are spacecraft in low orbits or
doing low-altitude fly-bys. The Martian satellites and inner moons of
the giant planets also show off the effect nicely.
One other thing that this patch addresses is orbit visibility for
barycenters. People often complain that the orbit of Pluto is no
longer visible now that it's defined as relative to the Pluto-Charon
barycenter rather than the Sun. In the process of implementing
secondary lighting, I had to introduce an 'object type' mask for frame
tree nodes. The mask contains the types of all objects that are
children of the node. With a small change to the orbit code, the mask
is used to render the orbit of a barycenter when planets or moons
orbit it.
Here's a rather large patch against the current SVN version of Celestia that implements secondary illumination:
http://www.celestiaproject.net/~claurel/celest ... hine.patch
Problems have been reported with the patch file; you may want to use this zip archive with all the changed files instead:
http://www.celestiaproject.net/~claurel/celest ... tshine.zip
For testing purposes only, planetshine can be toggled on and off with Ctrl+X (antialias lines.) This toggle will be removed before the code is committed to SVN.
The patch includes a significant cleanup and streamlining of
Celestia's lighting code; it simply wasn't practical to implement
secondary illumination /without/ this cleanup. The performance
benefits from this cleanup should more than compensate for the extra
computation required for secondary lighting.
I've worked hard to make Celestia's implementation of secondary
illumination both fast and general. Secondary illumination can come
from objects that aren't in the same 'system'. Thus the Cassini
spacecraft can be lit by light reflected from Earth, Venus, Jupiter,
Saturn, or any of Saturn's moons even though its orbit is defined
relative to the Sun. This is different how eclipse shadows work:
they're currently only computed for objects in the same system, and so
Cassini will never be eclipsed by Saturn (at least, not until a
subsequent patch addresses the limitation.)
Both reflector phase and reflector-to-receiver distance are accounted
for in the calculation of secondary illumination. There are two ways
in which distance affects the amount of light reaching the receiver:
obviously, the received energy falls off with 1/distance^2. But, the
distance also affects what part of the reflecting object is visible to
the receiver. An object in low Earth orbit like ISS sees only a small
fraction of the Earth's surface at one time, thus using something like
a simple (1+cos(phase))/2 correction to the amount of reflected light
will produce noticeably wrong lighting. The code in the patch uses a
more sophisticated approach that is still an approximation but gives
correct looking results in all cases.
Some limitations:
- All reflecting objects are treated as spheres
- Spacecraft, components, and surface features don't reflect light;
this was done in order to avoid terrible slowdowns with add-ons like
Selden's Hale telescope that have complex assemblies of small models.
And with a mass of irregular objects, the lighting wouldn't be correct
anyway.
- Only the brightest secondary illuminator is considered. This is easy
to fix, but at the expense of performance. It's probably not
worthwhile until HDR support lets us see the effects of very faint
light sources.
- You'll note that Earthshine isn't visible on the Moon; there's an
adjustable 'gamma' setting that would make it visible. Right now, it's
set so that secondary illumination will be visible when it is at least
10^-4 times as bright as the primary illumination. Earthshine on the
Moon is just barely under the cutoff. This gamma value can be
modified, but at the expense of underemphasizing light intensity
differences between more similar light sources. My feeling is that we
should wait for HDR rendering to be more developed before playing with
this value too much.
The best places to see planetshine are spacecraft in low orbits or
doing low-altitude fly-bys. The Martian satellites and inner moons of
the giant planets also show off the effect nicely.
One other thing that this patch addresses is orbit visibility for
barycenters. People often complain that the orbit of Pluto is no
longer visible now that it's defined as relative to the Pluto-Charon
barycenter rather than the Sun. In the process of implementing
secondary lighting, I had to introduce an 'object type' mask for frame
tree nodes. The mask contains the types of all objects that are
children of the node. With a small change to the orbit code, the mask
is used to render the orbit of a barycenter when planets or moons
orbit it.
(I tried mimas, and then Enceladus), and Hubble works now, too.