- The spacing between the grid lines is fixed; as you zoom in, the grid becomes useless because it's likely that no grid lines are in view.
- The subdivision of the grid lines is too coarse; unsightly angles between are visible because the arcs of the grid are approximated with too few line segments.
- It can be difficult to find the right ascension and declination labels. Even with a wide field of view, it is often necessary to move the viewpoint to find the grid labels indicating where in the sky you are looking.
I've produced a new patch that addresses all of these issues. The patch may be found here:
http://www.celestiaproject.net/~claurel/celest ... ptivegrid/
If you are building Celestia from SVN, you can try out the patch by replacing your versions of render.h and render.cpp with patched versions.
I'm open to changing most aspects of the grid and label display. Here is my rationale for the implementation so far:
1. Grid lines are spaced so that they lie at integer multiples of degrees (or hourse), minutes, and seconds.
2. As you zoom in, grid lines only disappear when they leave the field of view. Mathematically speaking, the spacing of lines at a particular zoom level is always an integer multiple of the all wider zoom levels.
The result of these two choices is that grid blocks can become very elongated. Since 5 is a prime factor of 60 (the number of minutes per degree), there is necessarily a point where the grid line density jumps by a factor of 5. Perhaps it's just better to violate constraint #2? If so, there are tables in the code that can easily be modified for different behavior. The current settings are:
Code: Select all
int hourMinSecSteps[] = { 2*HR, 1*HR, 30*MIN, 10*MIN, 5*MIN,
1*MIN, 30*SEC, 10*SEC, 5*SEC, 1*SEC,
500*MSEC, 100*MSEC
};
int degMinSecSteps[] = { 30*DEG, 10*DEG, 5*DEG, 1*DEG, 30*MIN,
10*MIN, 5*MIN, 1*MIN, 30*SEC, 10*SEC,
5*SEC, 1*SEC, 500*MSEC, 100*MSEC
};
3. The spacing chosen from the table is the nearest value less greater than or equal to an ideal spacing.
4. The ideal spacing is computed as follows:
- Let dfov be the field of view of the viewport diagonal (the displayed FOV is actually the vertical field of view.)
- Let M be the maximum number of RA or declination lines shown in the field of view
- The ideal spacing for declination lines (parallels) is dfov / M
- The ideal spacing for RA lines (meridians) varies based on the declination--at the pole, the meridian density is higher, so the angular spacing must be greater to accomodate this. The spacing is chosen to be the declination spacing divided by cos(d), where d is the minimum declination (closest to equator) in the field of view.
5. Circular regions near the poles are left empty to avoid a crowd of meridians in those areas.
6. Labels for RA and declination are placed at the viewport borders at the intersections of meridians/parallels with the viewport edges. This avoids a clutter of labels in the middle of the screen and prevents labels from being obscured by the object of interest, which tends to be located in the middle of the screen.
7. RA labels are shown on the top and right of the screen; declination labels are on the left and bottom. This ensures that labels will always be visible no matter how the viewport is oriented. Putting only one type of label at each border prevents RA and declination labels from overlapping each other.
It would also be possible to use a different label placement scheme. The one I've picked is close to what Stellarium does; another possibility would be to arrange the labels in the same manner as Google Sky. I much prefer having labels at the border, but it's not to everyone's taste.
--Chris
.