• Introduction and Disclaimer
• Advantages of using POV-Ray
• Generic Star Map Principles
• 3D Star Maps using POV-Ray
• Animation: illustratring distances and stellar
  motions

Introduction and disclaimer

Because of raytracing's ability to handle three dimensional images, a raytracing program is a good place to try making star charts. I used POV-Ray extensively to create various 3D star charts, showing star motions over time or the appearance of constellations from faraway places, in the 3D Universe section of this site.

Disclaimer 1: All my star charts have been done with version 3.1 of POV-Ray. Other 3.* versions will work fine. I'm not certain about 2.*.

Disclaimer 2: This page is aimed primarily at people who have had some experience with POV-Ray, or who have at least tinkered with it a bit. It's not an in-depth tutorial.

Advantages of using POV-Ray

One of the nice things about using a 3D rendering package is that it will automatically do most of the calculations for you. Specifically, using POV-Ray to make your star maps will free you from the following chores:

1. Calculating transformed target coordinates, as in the Armchair Astrometrist elsewhere on this site. With POV-Ray, all you'd need to do is give the reference star's coordinates as the camera coordinates. You don't have to write any special code beyond specifying the origin. POV-Ray will then render the new star map automatically.
2. Calculating transformed stellar brightnesses. Again, with the right choice of objects to represent stars, POV-Ray will handle this automatically.
3. Repeatedly calculating proper motion data for various times, to plot a star's "track" across the sky. POV-Ray can do this automatically (sense a trend here?)

Generic Star Map Principles

Star maps are actually an extremely simple thing to render with POV-Ray. All that you need to make a convincing star map is a collection of sphere objects, colored white, and sized to give a brightness appropriate for the star's magnitude. POV-Ray objects are placed with xyz coordinates, which is how we've been calculating stellar positions in general, so you don't have to do much fiddling to position stars in POV-Ray. Also, since stars are self-luminous, you don't even need to bother with a light source -- just set ambient 1 on each of the spheres to make them self-luminous, and you're basically done.

Thus, the guts of a POV-Ray star object will look something like this:

sphere { <0, 0, 0>, r, texture { pigment {color White} finish {ambient 1} } } translate <a, b, c>}

The only things you'll need to fill in are (a) the location of the center of the sphere (denoted a,b,c here) and the sphere's radius, denoted r. Everything else in this code fragment can be used verbatim.

Setting the sphere positions

POV-Ray uses xyz coordinates to place objects, so with one major caution you can simply use the Cartesian coordinates calculated by the appropriate methods. The major caution: POV-Ray uses a left-handed coordinate system, whereas the Cartesian coordinates described elsewhere in this site are right-handed. To handle this, simply switch the y and z coordinates on your star objects. In other words if you calculate for a star:

1. x = 21.52 pc
2. y = -12.53 pc
3. z = 3.56 pc

in POV-Ray you'd write:

translate <21.52, 3.56, -12.53>

The left-handed coordinate system will also cause some trouble when working with rotations. More on this later.

Setting the sphere sizes

A Simple Model

Advance warning -- this gets a bit techie in spots...

Suppose you're looking at a sphere of diameter d at a distance r. Its diameter appears to span a certain angle, which we'll call a. If you back away from the sphere, to a distance 2r, the sphere (provided it's small enough for small-angle trig approximations to hold) now appears to span an angle a/2. Since the angular area of the sphere is proportional to a², there is a simple inverse-square relationship between apparent sphere size and distance.

For luminous sources, like stars, there is also an exact
inverse-square relationship between apparent brightness and distance. This suggests a simple model for handling the brightness of stars in POV-Ray:

1. Use the apparent size of the sphere as its "brightness" (bigger = brighter), and
2. Make the sphere size directly proportional to the star's
   absolute luminosity.

With this simple model, apparent magnitudes -- the brightness of the star as seen from any given vantage point -- are automatically correct no matter where you move your viewpoint in the POV-Ray scene. The apparent size of a sphere automatically varies in an inverse-square manner with distance, just as a true star's apparent brightness does.

Thus, to set the size of a sphere, you will use a formula that looks something like the following:

• Sphere radius = k * sqrt(L/L₀)

where L is the star's true luminosity and L₀ is some reference value for that luminosity -- for example, L₀ might be the luminosity of the Sun, so L would then be in multiples of solar luminosity.

Since it's the sphere's radius, not area, that the POV-Ray
sphere object expects to see, we need the square root of the whole thing. Doubling the luminosity doubles the star's apparent area. The constant k will adjust the ratio L/L₀ into an appropriate value for POV-Ray; we can figure it out later while doing some test traces.

If you're pulling data straight from a star catalog, you're
probably either extracting or calculating the absolute
magnitude instead of a luminosity. They're closely related, however. The relationship between luminosity L and absolute magnitude M_V is given by:

• M_V = M_V0 + 2.5 log (L / L₀)

where L₀ and M_V0 are the reference values (i.e. star with luminosity L₀ has absolute magnitude M_V0).

This means we can rewrite the sphere radius formula as:

• Sphere radius = k * sqrt(10^{(0.4 * [M_V - M_V0]}))

To simplify things, we can choose the reference magnitude,
M_V0, to equal 0. Then:

• Sphere radius = k * sqrt(10^{(0.4 * M_V)})

Problems with the simple model

This simple model is good in many respects, but it has one big flaw: it is very difficult to get realistic star images over a wide range of magnitudes. In particular, stars that are very bright as seen from Earth, such as Sirius, tend to look like big disks, whereas dim stars tend to fade out altogether.

A simple fix

One solution to this is to "compress" the symbol range according to the apparent magnitude of the stars. This results in a formula for sphere size that looks like the following:

• Sphere radius = k * sqrt(10^{(0.4 * M_V)}) * (B/B₀)ⁿ

where B is the apparent brightness of a star, B₀ some reference brightness, and n is a number between 0 and -1. The value n effectively decreases the sphere size for stars with large B, and increases it for stars of small B. The brightness ratio can be determined from apparent magnitudes much as the luminosity ratio could be determined from absolute magnitudes:

• V = V₀ + 2.5 log (B / B₀)
• B / B₀ = 10^{(0.4 * [V - V₀])}

Thus you could set a reference magnitude roughly in the middle of the naked-eye range, such as +3, and a value of n around -0.5 or so, to uniformly shrink the largest stars and enlarge the smallest ones.

Problems with the simple fix

Although this approach makes the starfield more aesthetically pleasing, it totally destroys the nice scaling with distance you get with the simple model. Specifically, it couples the star's size to its apparent magnitude as seen from the Earth or some other fixed point as well as its absolute magnitude. Thus this method is not a good one to use if your star map involves starting at one place and then moving to another place very distant (so that star brightnesses change dramatically). In particular,
this fix is a poor choice in the following cases:

1. illustrating proper motions (through animations)
2. animated "travels" through a starfield

On the other hand, it's fine if you're making a single map for stars whose apparent magnitudes are well known. Thus, for star maps calculated for a remote location (e.g., those in 3D Universe), there is a way to use this fix effectively. Specifically, you must calculate each star's apparent magnitude from the remote location, rather than that from Earth, and then incorporate that information into the POV-Ray sphere size formula. If you're using a computer program to generate POV-Ray star objects, this is not particularly involved; if you're doing it by hand, it's a pain.

Labeling the chart

You may wish to label the stars; you can do that with text objects positioned near the star. This is mostly applicable to single charts, instead of animations, since it's hard to keep the labels a constant size if you're moving around the star field.

One fairly simple way to do this is to create a text object that looks good 1 POV-Ray unit from the camera and then adjust its size and position appropriately. A text object is created along the +x-axis, starting at the origin. To get the text object properly positioned takes a few steps.

1. Create your text.
2. translate the text one unit along +z. Run a test render to ensure the text is reasonably sized at a typical camera angle (say, 30 - 60 degrees). Adjust the size as needed.
3. Once the text looks OK at a distance of 1 unit, scale the translated text object by an amount equal to the star's distance -- this will simultaneously move it far enough out and enlarge it correspondingly, so it will appear to have the same size regardless of distance.
4. rotate it to a position close to the star. To preserve the text orientation, rotate around x first (equivalent to rotating in declination), then around y (equivalent to rotating in right ascension). I've often had the text right-offset slightly, so rotate around y very slightly less (or more, depending on how you do the rotation) than the star's right ascension. If you do these steps backwards, the text will probably end up rotated so it's no longer vertical as seen from the origin.

You can reverse the rotation and the scaling if you want -- just be sure that the text object is 1 unit from the origin before you scale or rotate.

This is fairly complex and you will probably want to have a computer program prepare the text object declarations for you.

Rendering issues

Star Object Management

I prefer to union all the star objects together and stick them in an include file. This is definitely preferred if you have more than a few dozen stars to place.

POV-Ray Rendering Options

There is one, and only one, thing you really must remember: always, always, always turn anti-aliasing ON, and preferably to an extremely aggressive level. Setting the anti-aliasing threshold all the way down to 0 is often a very good idea. If you do not anti-alias very aggressively, you will intermittently lose faint stars -- irritating in stills, and absolutely devastating in animations.

Everything else is pretty much up to you.