Pluto is so far away that is angular size seen from Earth
is very small. I had to tweak my internal scaling constants
so that the raytracer was able to resolve it.
Added radius data for the Sun, Moon, and remaining planets.
Test the raytracer for all other bodies except the Earth and Sun.
There is a problem with Pluto that I still need to figure out.
Fixed an issue in the doxygen-to-markdown translator I wrote
(hydrogen.js): it did not handle when one #define referred
to another #define. Created a more generic markdown expansion
that works in all cases, and creates embedded hyperlinks.
The program 'realpath' does not come installed on Mac OS.
This caused the bash script 'makedoc' to fail on Mac.
The only place I used realpath was to convert relative
paths to absolute paths for filenames passed to
check_internal_links.py.
It turns out Python has a standard function os.path.realpath()
that does the same thing, so I moved the logic into the
Python script itself. Thus makedoc no longer needs the
realpath program, and the Python function will work on
all platforms.
There is a general lesson here: in the future I will
consider moving more of my scripting logic into Python.
It has proven to be more portable than a mixture
of bash scripts and Windows batch files.
There was one more place where novas.c calls abs()
that caused a warning when compiled on the Mac.
It was passing long int to abs(). To be abundantly
cautious, instead of using labs(), I just manually
check for negative values and toggle -- inline abs.
I received a report that there are compiler warnings
that break the build in novas.c when building on the Mac.
In two cases, long integers are passed to abs(), which expects
its argument to be int. The warnings broke the build
of the 'generate' program. I patched the code so these
warnings should no longer occur, though I do not have a
Mac to test. Will ask the correspondent to test for me.
Refactored the Jupiter imager to be a generic planet imager.
Added support for drawing an image of Venus.
Verified that its extreme crescent phase looks correct
for the current date.
I will add radius constants to astronomy.h for each body I support.
The raytracer now includes the option -s (without a numeric
spin angle on the command line) to automatically calculate
the spin angle needed to bring the planet's north pole
exactly upward in the generated image.
Improved the way I create the rotation matrix that
aims the virtual camera at Jupiter. The camera still
aims exactly at Jupiter, but this time it defaults
to having the left/right pixel direction aligning
with the Earth's equator. By experiment, I can spin
the longitudinal camera axis by -10 degrees and get
a good fit with Jupiter's equatorial plane. I will
adjust this more exactly in a future commit.
Now the raytracer requires the user to pass in
both the pixel width and pixel height on the command line.
This allows for generating non-square images, which will
be necessary for the general case of imaging the moons
with respect to the planet.
Now that I have eliminated refraction and reflection
from the astronomy raytracer, there is no need for an
Optics class that represents matte, gloss, and index
of refraction.
I had lots of problems with using AU as my scale units.
By changing to 10000*km units, the vector equation solver
works correctly again, and I actually get an image of Jupiter
and its moons. However, it does not match the test photo:
Ganymede does not appear close to the planet, nor is there
a shadow of it on the planet. I will have to debug that
separately.
Starting to work through adaptation of existing
raytracer code to generate geometrically accurate
images of Jupiter and its moons. Not yet working,
but I believe I am at least aiming the camera in
the right direction.
The documentation for the Python function `SearchAltitude`
was missing a mention of the `altitude` parameter.
I searched for similar mistakes in Python, C#, and C,
having just completed the same exercise in the JavaScript code.
I also found several places where extraneous newlines
between the parameter documentation caused the Markdown
to be rendered incorrectly.
Added documentation about the missing `date` parameter
to the `Elongation` function in the JavaScript version.
I reviewed all the other JavaScript functions to make sure there
were no other similar mistakes with parameters or return types.
Along the way, I discovered and fixed some other issues:
Fixed miscellaneous typos in the documentation.
Consistently refer to enumeration values like `Body.Earth`
instead of strings like `"Earth"`. I want to encourage
use of the enumerations because they make type-checking easier,
especially for TypeScript code.
Reworked `AstroTime` parameters to `FlexibleDateTime` parameters
in all exported functions. This is completely backward-compatible,
and allows callers more flexibility with passing `AstroTime`,
`Date`, or numeric day values.
Now that Microsoft has officially released .NET 6,
I have upgraded the C# version of Astronomy Engine to use it.
No source code changes were needed. I just bumped the
version number in the project files, and targeted .NET 6
in the GitHub Actions continuous integration tests.
Fixed some obsolete wording in generate/README.md.
I used Cassini's Laws to derive an approximate solution
to the Moon's rotation axis. The error is on the order of
5 arcminutes. I still need to correct for physical libration.
I also need to find test data for the Moon's prime meridian
so that I can implement the spin angle calculation.
(I could use test data for all the planets' spins, for that matter.)
In Windows I am running Python 3.7.8.
For some reason, it fails to write Unicode Greek letters
I use in the Markdown documentation unless I explicitly
specify to use utf-8 encoding. I thought that was the default,
because it works fine in Linux running 3.9.2.
I'm not sure whether the issue is due to Windows or
to a change in the Python version. Regardless, I am
explicitly specifying the file encoding to make the
documentation translator I wrote (pydown.py) work.
This issue affected maintainers (mostly me) only.
Developers who are using Astronomy Engine do not need
to worry about this.
Running the source generator on Windows was broken because
I forgot to copy a step over from the Linux build that
prevents building tutorial pages in the master branch.
I didn't notice this until now because makedoc.bat also
had a bug where it detected an error but did not stop
execution... it just kept going and made it hard to
notice something was wrong.
