Home Planet Development Log


download 152.41 Kb.
jenengHome Planet Development Log
Kaca1/5
KoleksiDokumen
a.kabeh-ngerti.com > Astronomi > Dokumen
  1   2   3   4   5
#$1 Home Planet Development Log

by John Walker

Release 2 Development

16 September 1994

Integrated fixes to SKY.C from the Sky Screen Saver which handle failures either to allocate the circular clipping region or to select it into the HDC used to paint the star map. This corrects the mysterious "random blank sky map" problem which occurred when the map window was large and memory was tight.

28 September 1994

Fixed labels in the entry for Uranus in PLANETS.CSV. The "km/sec" that's supposed to follow the escape velocity was appended to Earth masses item instead.

Integrated fix from Sky Screen Saver to correctly flip the Sky window South up for southern hemisphere observing sites.

Integrated fix from Sky Screen Saver to gracefully recover from failure to allocate the Sky window device dependent bitmap. An "insufficient memory"

message is now displayed in the window in this case. I implemented the same logic to handle the corresponding failure in the Telescope dialogue procedure.

Corrected the standard colours requested in the Sky window palette. Several colours used for legends in the Sky map were missing, which could cause unfortunate substitutions on some displays.

Implemented the "Align constellation names" option. If enabled, the Sky window generates custom TrueType fonts to rotate constellation names so they're aligned with the local horizon. This looks more like conventional sky maps, and reduces the likelihood of a constellation name being clipped at the horizon. Constellation names are never aligned in the Telescope window.

Installed fix in SCRNSAVE.C to correct "invalid HWND 0000" when no time zone warning dialogue is removed. Since changes made of late have blown away the ability to build the screen saver, testing this will have to be deferred for a while.

If the Map window was iconised, the Sky window was not updated. This was due to bad logic in updimage (SUNCALC.C), which conditioned updates of the Sky window on whether the Map window was iconic. I changed the test to invalidate the Sky window if it was displayed and was not an icon.

3 October 1994

Integrated a totally new planet position calculator based on the VSOP87 theory of planetary motion. This new module, VSOP87.C, replaces the old-fashioned PLANETS.C which used series from Meeus' 1985 "Astronomical Formulæ for Calculators". The VSOP87 module produces results with errors in the arc-second range over a wide span of time. Corrections for aberration due to the finite speed of light, nutation in longitude and obliquity, transformation from dynamical coordinates to the FK5 system, and compensation for the (very small) latitude of the Sun's apparent position are included. The nutation is calculated by the new function nutation() in ASTRO.C, which uses the IAU expressions. The calculation of the position of the Moon, Pluto, and asteroids and comets being tracked remains as before, except that Pluto's position now benefits from all the corrections mentioned above.

The planetary position calculation function recognises a new bit in the "which" argument FULL_PLANET_INFO. If set, all fields in planet_info are filled in and all corrections are calculated. If zero, only the heliocentric longitude, latitude, and radius vector are computed, the series used to evaluate these items are truncated, and no corrections are applied. This enables the Orrery to bypass these refinements when calculating the planetary orbits (the difference is much less than a single pixel at the scale of the orrery, so accuracy is not sacrificed).

5 October 1994

Installed a canned orbit resource which drastically speeds up the Orrery display--in some cases the Orrery is calculated and displayed 100 times faster than before. The overwhelming percentage of computation associated with the orrery is evaluating the planetary orbits by multiple calls on planets(), yet planetary orbits change but little over time. I included a resource which contains precomputed orbits (stored as scaled 16 bit numbers) circa J2000, which can be used to display the orrery for the millennium centred upon that date.

The orbits drawn by the orrery didn't always precisely close. You never noticed this unless an animation was being run, since the gap in the orbit was always smaller than the planet icon and occurred at the planet's current position in its orbit. I added a closing segment to eliminate gaps in the orbits.

Replaced the old high-precision Moon position calculation with the one derived from Chapront's ELP-2000/82 lunar theory as given in Meeus, "Astronomical Algorithms", chapter 45. This theory is accurate to ten arc-seconds in longitude and 4 arc-seconds in latitude in contemporary epochs. Note that the far less accurate calculation in phase() is still used in several places in the program.

6 October 1994

The asteroid and comet selection mechanism in the Object Catalogue contained logic to deselect a currently-tracked object by choosing an entry named "-none-" (actually, just the leading hyphen is tested, allowing localisation). However, the asteroid and comet databases (ASTEROID.CSV, ASTNUM.CSV, and COMETS.CSV) did not include "-none-" entries. I added them.

11 October 1994

I completed a total revision and update to the asteroid databases, using as a starting point the:

CATALOGUE OF ORBITAL ELEMENTS AND PHOTOMETRIC PARAMETERS

OF 4646 MINOR PLANETS NUMBERED BY NOVEMBER 2, 1990

Yu.V.Batrakov, V.A.Shor

Institute for Theoretical Astronomy of the Russian

Academy of Sciences, St. Petersburg

incorporating the errata from Francois Ochsenbein (CDS, Strasbourg). Data for asteroids 4646 through 5632 were taken from files posted on the CompuServe ASTROFORUM, in MPC format. I merged the resulting database with the earlier one, which contained several asteroids named after the ITA catalogue was published.

The evaluator for Kepler's equation used in ASTEROID.C used Sinnott's binary search method for eccentricities below 0.95 and the iterative Gauss method for higher eccentricities. This caused very eccentric (but still elliptical) cometary orbits such as Halley's to use the Gaussian method in the region where it is extremely slow. I changed the threshold to 0.995, which allows most comets to use the still-accurate Sinnott method, but defers to Gauss for parabolic and hyperbolic orbits. This doesn't make much difference except for the Orrery, which calls the orbital position calculator numerous times to plot the orbit. The orrery display for Halley's comet, for example, dropped from 477 seconds generation time to 13.3 seconds--more than 30 times faster. I also added a "quick" argument to trackAsteroid which suppresses calculation of right ascension, declination, and radius vector and, in turn eliminates evaluation of the obliquity of the ecliptic. When planets() in VSOP87.C is called without the FULL_PLANET_INFO bit set, this mode is selected. This contributes to the speed-up of the orrery calculation.

The clever code which limits the extent of a parabolic or hyperbolic orbit was running afoul of other clever code which estimates the number of segments needed to plot its orbit near perihelion. Result: only he outbound leg of the orbit was plotted, complete with interplanetary U-turn to incorrectly close the orbit. Fixed.

12 October 1994

When the Orrery window was obscured or otherwise damaged while the refresh bitmap remained valid, repainting the image sometimes didn't restore the frame around the Orrery image. This was due to the update region not allowing a full copy of the backing bitplane. I added an InvalidateRgn call to guarantee the entire bitmap is restored.

When the Orrery was being painted, no clip region was used to restrict the image to the display box. If an asteroid or comet appeared outside the box (but still within the astronomical unit limit, due to perspective), it could be drawing outside the image panel. I added a clipping region to prevent this.

Similarly, I added a clipping region to the dragging code for the vertical and horizontal scrollbars. This prevents paint splattering outside the image panel when the Earth icon impinges on its edges.

I ripped out and totally reimplemented the code which plots orbits of comets and asteroids. Before, it shared logic with the planetary orbit code, but the differences were just too great to maintain the fiction that they were logically parallel. All the planetary orbits are close enough to circular that they can be plotted in equiangular segments without obvious errors. Further, they are always closed and have a known period. Asteroid and comet orbits obey none of these simplifying assumptions. I added a general orbit plotter which handles orbits of any eccentricity and size. It calculates the time of perihelion and draws the two arms of the orbit from that point, forward and back, until either they join somewhere on the orrery, or are clipped at the edge of the image. I modified the clipping logic to account for the square boundary of the image panel. More importantly, the code now calculates the instantaneous orbital velocity of the body and dynamically adjusts the time step for each segment of the orbit so the orbit remains smooth throughout, yet no time is wasted during distant, slow-moving sections of the orbit. The time saving from this were rather dramatic. For a bad-boy slightly hyperbolic Sun-grazer comet, orrery calculation time dropped from 880 seconds to a little more than 7 seconds. Music of the spheres to my ears.

I replaced the year-old satellite element databases with versions current as of mid-October 1994. Of course, they'll soon be out of date, but it's better than including hopelessly obsolete data.

13 October 1994

More fixes to the utility program ASTRELEM.C to handle additional quirks observed in the elements included in Minor Planet Electronic Circulars (MPECs). Objects (for example just-discovered Pluto crossers) with an undetermined eccentricity are given as E = 0.00000 but with the mean anomaly (M) field blank. Home Planet handles a blank mean anomaly correctly but other programs may not, so I fixed the code to include an explicit "0.0" for mean anomaly if it is unknown.

Elements for recovered objects include an "Id." line as the second line (between the name and the Epoch) and omit the "From" line at the end. These are now processed correctly.

The orbital velocity determination code in ORRERY.C could divide by zero if Kepler's equation failed to converge for near-parabolic objects with mean anomalies near 180°. I modified ASTEROID.C to guarantee that the radius vector is returned as zero to indicate the orbital position calculation failed (this is our signal elsewhere, as in PLUTO.C), and fixed ORRERY.C to treat this failure as marking the end of the current branch of the orbit.

I further refined the calculation of time steps based on orbital velocity so that the step size for the inner solar system is always used when the object is within the inner system. This results in much smoother orbits near perihelion, without compromising speed in the much longer outer system branches. Since very eccentric orbits don't spend much time in the inner system, we can afford the additional precision there.

I fixed the horizon view to work properly in both the northern and southern hemispheres. Since in horizon view we're working in altitude and azimuth co-ordinates, which don't depend upon the observer's hemisphere (that being accounted for in the transformation from equatorial to local horizontal co-ordinates), all the vertical flipping and mirroring logic done in the Sky and Telescope views had to be bypassed. In addition, the inverse transformation from horizontal to equatorial co-ordinates done when a left click to aim the telescope or a right click to identify an object ran afoul of an error in the next to last equation on page 89 of Meeus' "Astronomical Algorithms" which should read:

tan(H) = sin(A) / (cos(A) * sin(Phi) + tan(h) * cos(Phi))

Added a Terrain configuration section to the Options dialogue for the Horizon panel. This allows enabling or disabling the synthesised terrain at the horizon, setting the fractal dimension of the terrain (its roughness), and choosing whether "scenery" such as cows, pigs, tractors, houses, etc. is drawn along the horizon. (These parameters are not yet saved in the settings file--that will be done in the final closeout of the settings file.)

14 October 1994

Updated the Spacecraft database (spacecrf.csv) to include all objects launched through the end of 1993, and added apogee, perigee, orbital period, and inclination where known. This database is derived from TS Kelso's SDF satellite database, using a C program (in the TOOLS subdirectory) called SATDBC.C to convert to CSV format, then SORT to put in alphabetical order.

Completed the first cut at the Horizon window and its Horizon options dialogue. This window, activated from the View menu of the Sky window, shows the sky above the horizon at any given azimuth for an observer at the configured observing site. The code that implements the Horizon window is very similar to that of the Telescope, except that co-ordinates are transformed from equatorial to horizontal (altitude and azimuth) before display. This introduces a few interesting wrinkles, the messiest of which is calculating how many segments to subdivide constellation boundaries that run along parallels of declination so that they are drawn curved relative to the sky, not the horizon. Left clicking in the horizon window aims the telescope to the designated location, and right clicking identifies the closest object pointed to in the Object Catalogue (these operations require transforming back from horizontal to equatorial co-ordinates, naturally. The default field of view is 45%, corresponding to the high resolution portion of the eye, but you can configure larger or smaller fields of view, limited only at the point the projection would introduce ridiculous distortion.

The Horizon Options dialogue is very similar to the Telescope Options, except that the South up check box is missing (it would be equivalent to a "Stand on your head" option, which I don't think would be useful) and replaced by a box that controls whether fractal forged terrain is drawn along the horizon and, if enabled, its fractal dimension (lower numbers give smoothly rolling hills, larger numbers rougher, more mountainous terrain) and whether the terrain is decorated with scenery such as cows, houses, and the like. All the options for configuring the objects shown in the sky are identical to the Telescope window.

15 October 1994

To allow user customisation of the scenery icons optionally drawn if Terrain is enabled in the Horizon window, I moved the icons and all the logic for selecting them into a DLL called SCENERY.DLL, which is maintained as a separate project in directory SCENERY. The user can perform simple customisation of the scenery simply by directly editing this DLL with a resource editor such as Application Studio. The DLL contains four numbered string resources:

1 "15 ; Number of icons to use at horizon"

2 "32 ; Size of icons"

3 "10 ; Density to sprinkle icons"

4 "16 ; Total icons in file"

and sixteen icons with resource numbers 1 through 16. You can edit any of the existing icons, replace them with new icons, and/or add new icons, increasing the number in string resource 4 (only the number is scanned; the comment is ignored). If the additional icon is eligible for random selection for drawing at the horizon, increase the number in string resource 1 as well. Icons with indices above that given by string resource 1 can be plotted in sky maps with the "Hnnn" phrase in a User Catalogue entry.

The icon size is specified by the second string resource, but this must presently be left as 32. The third string resource controls the density with which icons will be placed on the terrain. The chance of an icon appearing at a given pixel along the horizon is 1/(icon_size * icon_density), the parameters given by string resources 2 and 3. Thus, with the default values, an icon will be drawn, on the average, every 320 pixels along the horizon (note, thus, that decreasing the density parameter increases the frequency with which icons appear and vice versa). The scenery drawing code automatically guarantees that icons are not drawn on top of one another. If the image in an icon does not fill the 32×32 pixel icon frame, it should be drawn justified against the left and bottom of the icon frame.

Much more sophisticated customisation of scenery generation is possible by replacing the supplied version of SCENERY.DLL with a user-defined version. The interface between Home Planet at this DLL is through the following functions. Whenever the horizon window is redrawn and the user has enabled terrain and scenery, the function:

void FAR PASCAL _export sceneryInit(

double julianDate, // Time and date

double siteLat, // Observer latitude

double siteLon, // Observer longitude

double viewAzimuth, // Azimuth of window center

WORD imageHeight, // Image height

WORD imageWidth, // Image width

WORD randomNumber, // A 15 bit random value

WORD FAR *numIcons, // Return: Number of icons

WORD FAR *iconSize, // Icon size

WORD FAR *iconDensity); // Icon density

is called. This provides the DLL complete information as to the time and date (real or simulated) at which the horizon is being drawn, the

latitude and longitude of the observer, what direction the observer is looking, the height and width of the horizon window in pixels, plus a random number between 0 and 32767 that the DLL can use any way it wants. The function returns three values through pointers: the number of icons it can generate (if zero, scenery is disabled), the size of the icons provided, and the density parameter as described above. Although the SCENERY.DLL provided with Home Planet uses none of the information provided to sceneryInit, I'm sure you'll see how this information can be exploited to show leafy trees in summer, falling leaves in fall, and bare limbs in winter, kangaroos if the observer is in Australia, and more.

Each time Home Planet decides, at random, to place an icon along the horizon, it calls:

void FAR PASCAL _export sceneryIcon(

WORD xPos, WORD yPos, // Where icon is to be drawn

WORD randomNumber, // A 15 bit random number

HICON FAR *hIcon, // Return handle to icon

WORD FAR *hWidth); // Width (advance) after this icon

informing SCENERY.DLL of the X and Y co-ordinates of the top left corner of the icon within the horizon image pane and providing a random number between 0 and 32767. sceneryIcon should return the handle of the icon to be drawn in hIcon, and the width of the image within the icon in hWidth (this is used to keep icons from being drawn atop one another). The icon will be destroyed by Home Planet after being drawn into the terrain.

At the end of generation of the horizon image Home Planet calls:

void FAR PASCAL _export sceneryTerm(void);

to allow SCENERY.DLL to clean up any items it might have allocated in sceneryInit. Home Planet guarantees that SCENERY.DLL will not be called from any other application or instance between sceneryInit and sceneryTerm, allowing it to use local storage within the DLL without conflicts.
  1   2   3   4   5

Share ing jaringan sosial


Similar:

D. susunan planet-planet, satelit, asteroid, komet dan benda lainnya...

Perbandingan diameter sudut sutu bintang saat suatu planet di titik...

Reading log matematika

Astronomer’s Observing Log

Home@daleterrie wanadoo co uk

Pluto (planet)

Karakteristik Planet

Astronom Analisa Misteri Planet Jauh

4. Summary of the Development Process 9

Telescopes, their history, development and the future

Astronomi


Nalika Nyalin materi nyedhiyani link © 2000-2017
kontak
a.kabeh-ngerti.com
.. Home