Page 1 of 2

Celestial Grids: Request for Feedback

Posted: 27.05.2008, 19:25
by chris
I'm working on a new implementation of the equatorial grid feature of Celestia. The current one suffers from the following shortcomings:

- 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

Re: Celestial Grids: Request for Feedback

Posted: 27.05.2008, 19:51
by t00fri
Chris,

I installed your patch. What I find a bit odd is the fact that upon little movements of mouse_L+SHIFT the grid often changes from VERY narrow and unnaturally looking rectangle shape (h<<w) to (h~ w). What's the incentive, here?

Fridger

Re: Celestial Grids: Request for Feedback

Posted: 27.05.2008, 20:05
by chris
t00fri wrote:Chris,

I installed your patch. What I find a bit odd is the fact that upon little movements of mouse_L+SHIFT the grid often changes from VERY narrow and unnaturally looking rectangle shape (h<<w) to (h~ w). What's the incentive, here?

This is a result of point #2, which I may not have explained very well. I'm trying to maintain spacings that, as you zoom in, evenly divide the previous spacing. Consider the options if you start with 1 degree spacing. There are three sensible ways to subdivide the interval:
2 * 30 minute intervals
3 * 20 minute intervals
5 * 12 minute intervals
Let's say that you try and limit the amount of subdivision and choose 30 minute subintervals. The 30 minute interval then gets divided into 2 15 minute intervals. Then 3 5 minute intervals. Now we've hit the problem: this interval can only be divided into 5 subintervals if we want to obey constraint #1 (spacings are integer multiples of degrees, minutes, and seconds.) Immediately after the split, the grid will be divided into approximately square patches; but right before it, the aspect ratio will be different by a factor of five. I think that this a necessary consequence of constraints #1 and #2 and the fact that 5 is one of the prime factors of 60.

So perhaps the best thing to do is remove the constraints? The spacing table used in the code allows for this.

--Chris

Re: Celestial Grids: Request for Feedback

Posted: 27.05.2008, 20:19
by chris
Continuing my previous post . . . It would be possible to prevent extremely elongated grid blocks by subdividing the one degree spacing in this sequence:

30 minutes
15 minutes
7 minutes 30 seconds
3 minutes
1 minute

This sequence limits to a factor of three the jump in aspect ratio of a block. The "cost" are parallels that appear in the 7 minute 30 second spacing but then disappear when you zoom in further and see the 3 minute spacing.

--Chris

Re: Celestial Grids: Request for Feedback

Posted: 27.05.2008, 20:51
by chris
An updated version of the patch adds a plus to indicated the north and south celestial poles.

--Chris

Re: Celestial Grids: Request for Feedback

Posted: 27.05.2008, 21:24
by t00fri
chris wrote:An updated version of the patch adds a plus to indicated the north and south celestial poles.

--Chris

Good, I'll have a look!

Fridger

Re: Celestial Grids: Request for Feedback

Posted: 27.05.2008, 21:49
by t00fri
Chris,

looks much better at lower zoom, but at higher zoom there are still some very elongated rectangles.

Here is an example:

Image

Fridger

Re: Celestial Grids: Request for Feedback

Posted: 27.05.2008, 21:56
by chris
t00fri wrote:Chris,

looks much better at lower zoom, but at higher zoom there are still some very elongated rectangles.

Here is an example:

Image

I can add a maximum aspect ratio constraint: if the aspect ratio exceeds some limit, then the maximum density constraint could be violated to allow earlier subdivision of RA.

--Chris

Re: Celestial Grids: Request for Feedback

Posted: 27.05.2008, 22:10
by chris
chris wrote:
t00fri wrote:Chris,

looks much better at lower zoom, but at higher zoom there are still some very elongated rectangles.

I can add a maximum aspect ratio constraint: if the aspect ratio exceeds some limit, then the maximum density constraint could be violated to allow earlier subdivision of RA.

OK. Here's the patch that prevents extremely elongated blocks:

http://www.celestiaproject.net/~claurel/celest ... blocks.cpp

The drawback is that it can result in an inappropriately dense grid. The problem I think is still the five-fold subdivision. A better solution to the problem of elongated blocks is a different set of spacing tables. I'll produce an alternate set which avoids extremely elongated blocks (though it won't have some of the nice properties of the current choices.)

--Chris

Re: Celestial Grids: Request for Feedback

Posted: 27.05.2008, 22:38
by t00fri
Almost perfect, except at very high zoom:

Image

There are also once or twice some vertically elongated rectangles, but not so extreme as the horizontal ones.

Fridger

Re: Celestial Grids: Request for Feedback

Posted: 27.05.2008, 22:41
by chris
t00fri wrote:Almost perfect, except at very high zoom:

Image

There are also once or twice some vertically elongated rectangles, but not so extreme as the horizontal ones.

Fridger

This is a result of missing levels at the end of the spacing table. I'll add those now.

--Chris

Re: Celestial Grids: Request for Feedback

Posted: 27.05.2008, 22:46
by t00fri
After merely testing, my brain now started to work slowly as well ;-).

Question: why are the resulting rectangular patterns so little repetitive? Somehow, it must be due to your subdivisions, but still it's amazing for how long I get each time new patterns upon zooming in a bit.

What would be the type of subdivision that would --in contrast-- make the rectangular patterns to cycle much quicker? Symmetry?

Fridger

Re: Celestial Grids: Request for Feedback

Posted: 27.05.2008, 23:10
by chris
t00fri wrote:After merely testing, my brain now started to work slowly as well ;-).

Question: why are the resulting rectangular patterns so little repetitive? Somehow, it must be due to your subdivisions, but still it's amazing for how long I get each time new patterns upon zooming in a bit.

What would be the type of subdivision that would --in contrast-- make the rectangular patterns to cycle much quicker? Symmetry?

To make the patters cycle more quickly more spacings can be added to the table. Here's another version of the patch that does exactly this:

http://www.celestiaproject.net/~claurel/celest ... pacing.cpp

Instead of jumping from 5 degree to 1 degree spacings, this table features an intermediate 2.5 degree spacing (as well as 2.5 minute and 2.5 second spacings.) You can add as many intermediate spacings to the table as you like. In general, the more choices of spacings that there are, the more square the grid blocks will tend to be. The larger the 'jump' between adjacent table entries, the more elongated the grid blocks can be. The table in render-finderspacing.cpp has a maximum jump of 3x. Those could be eliminated by adding a 15 degree spacing in between the 30 and 10 degree ones.

In Stellarium, it appears that they chose not to use any 'intermediate spacings'; blocks can appear very significantly elongated after the jump from 5 deg/min/sec spacing to 1 deg/min/sec.

--Chris

Re: Celestial Grids: Request for Feedback

Posted: 27.05.2008, 23:25
by t00fri
These rapidly cycling tables look better, but still now we got this

Image

Chris, could you increase the brightness of the numbers/grid a bit for testing? It's too dark on my screen.

I don't mind these intermediate numbers. (as long as I can read them ;-) )

Fridger

Re: Celestial Grids: Request for Feedback

Posted: 28.05.2008, 00:21
by chris
t00fri wrote:These rapidly cycling tables look better, but still now we got this

Chris, could you increase the brightness of the numbers/grid a bit for testing? It's too dark on my screen.

I don't mind these intermediate numbers. (as long as I can read them ;-) )

I agree that they're an improvement over the extremely elongated grid blocks. I think that the 3x elongation that we see now is a reasonable compromise, but it is possible to split the 3x jump into 1.5x and 2.0x.

The latest version of render.cpp in http://www.celestiaproject.net/~claurel/celest ... ptivegrid/ contains a fix for disappearing RA labels.

You can easily experiment with different label and grid colors using script. Here's an example:

Code: Select all

celestia:setlabelcolor("equatorialgrid",   0.36, 0.39, 0.75)
celestia:setlinecolor ("equatorialgrid",   0.23, 0.24, 0.38)


I think that the current defaults are a bit too dark as well.

--Chris

Re: Celestial Grids: Request for Feedback

Posted: 28.05.2008, 00:35
by t00fri
I think the elongation is now quite tolerable. Yet, for my taste it's still a bit long (3:1). I still remember about the identical attempts we made long long ago within XEphem. Also without finding an ideal solution ;-)

Fridger

Re: Celestial Grids: Request for Feedback

Posted: 28.05.2008, 14:25
by duds26
chris wrote:Continuing my previous post . . . It would be possible to prevent extremely elongated grid blocks by subdividing the one degree spacing in this sequence:

30 minutes
15 minutes
7 minutes 30 seconds
3 minutes
1 minute

This sequence limits to a factor of three the jump in aspect ratio of a block. The "cost" are parallels that appear in the 7 minute 30 second spacing but then disappear when you zoom in further and see the 3 minute spacing.

--Chris

Adding smaller or larger horizontal or vertical grids to balance the aspect ratio, could that help or not?


What if you let the lines start faint and little transparant instead of immediatelly become visible. The factor 5 won't be that bad then.

Adding in the information text the position of the camera/viewer (with the accuracy in function of the height) and the position of the cursor on the surface (this will be a little more accurate but still pretty innacurate if it is zoomed out so you can see the whole planet) And hide it when the cursor and/or viewer are too far.

Just some thoughts:
Using those coordinates could be handy in scripts and addons. Copying to and from clipboard of coordinates would certainly be handy for this.

For modmakers: to make it possible to give a grid a custom color in a script and place it higher than the surface of the planet.

Re: Celestial Grids: Request for Feedback

Posted: 28.05.2008, 17:36
by chris
t00fri wrote:I think the elongation is now quite tolerable. Yet, for my taste it's still a bit long (3:1). I still remember about the identical attempts we made long long ago within XEphem. Also without finding an ideal solution ;-)

One more version of the patch . . . I've added more entries to the spacing table so that there's never more than a 2x jump. The subdivisions of one degree are now:

1 degree
30 minutes
15 minutes
10 minutes
5 minutes
3 minutes
2 minutes
1 minute

I also increased the brightness of the grid lines and labels. The labels are significantly brighter than the lines in order to improve readability when overlap grid lines.

--Chris

Re: Celestial Grids: Request for Feedback

Posted: 28.05.2008, 20:39
by t00fri
chris wrote:
t00fri wrote:I think the elongation is now quite tolerable. Yet, for my taste it's still a bit long (3:1). I still remember about the identical attempts we made long long ago within XEphem. Also without finding an ideal solution ;-)

One more version of the patch . . . I've added more entries to the spacing table so that there's never more than a 2x jump. The subdivisions of one degree are now:

1 degree
30 minutes
15 minutes
10 minutes
5 minutes
3 minutes
2 minutes
1 minute

I also increased the brightness of the grid lines and labels. The labels are significantly brighter than the lines in order to improve readability when overlap grid lines.

--Chris

Yes, I think this is pretty good now. The rectangular aspect ratio is ~ constant over many zoom stages (with just very few exceptions). But still the shape is not square, rather 2.5:1 or so. One might heretically ask perhaps why this rather zoom-invarant pattern cannot be rescaled vertically to be just a bit more square, altogether?

Fridger

PS: You forgot to provide a link in your post to the respective render.cpp. I went to the usual place and grabbed render.cpp as of May 28.

Re: Celestial Grids: Request for Feedback

Posted: 28.05.2008, 21:34
by chris
t00fri wrote:
Yes, I think this is pretty good now. The rectangular aspect ratio is ~ constant over many zoom stages (with just very few exceptions). But still the shape is not square, rather 2.5:1 or so. One might heretically ask perhaps why this rather zoom-invarant pattern cannot be rescaled vertically to be just a bit more square, altogether?

This is not heretical at all. Reading your comment prompted me to double check a calculation. I found a stray factor of 2 that was causing too great a vertical spacing to be chosen. The fixed version of render.cpp is back in the usual place: http://www.celestiaproject.net/~claurel/celest ... render.cpp

--Chris