Code Documentation of Celestia 1.4.1 (Doxygen)

The place to discuss creating, porting and modifying Celestia's source code.
Avatar
Topic author
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 22
With us: 22 years 7 months
Location: Hamburg, Germany

Code Documentation of Celestia 1.4.1 (Doxygen)

Post #1by t00fri » 14.01.2006, 21:53

Here is what you always wanted to know about the latest Celestia version (pre 1.4.1 CVS) and never dared to ask ;-)

Using the latest versions of Doxygen and the graphing package graphviz-2.6.1, I prepared an extensive documentation of the latest (pre 1.4.1 CVS) version of Celestia.

You may interactively browse e.g. the source code, the class structure (textually and graphically), the methods, variables, referencing, include dependency graphs and MUCH more:

http://www.celestiaproject.net/~t00fri/celesti ... index.html


Note, every text and graphical output is clickable revealing a host of valuable information about Celestia's structure! The same docu I always have integrated in my GUI KDevelop environment, hence it's always ready during my development work.

Bye Fridger

MKruer
Posts: 501
Joined: 18.09.2002
With us: 22 years 2 months

Post #2by MKruer » 14.01.2006, 22:22

t00fri

Do you have a list of improvements of 1.4.1 over 1.4.0?

Avatar
Topic author
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 22
With us: 22 years 7 months
Location: Hamburg, Germany

Post #3by t00fri » 14.01.2006, 23:05

MKruer wrote:t00fri

Do you have a list of improvements of 1.4.1 over 1.4.0?


Yes, you can easily find that yourself in CVS ...

Here it is so far...there may be more

Code: Select all

1.4.1
* Windows: Added time zone selection to set time dialog
* Windows: Fixed hard to read text in set time dialog (bug was only present for
  certain Windows shell appearance settings.)
* Changed maximum number of eclipse shadows in OpenGL 2.0 path from two to three;
  if max is exceeded, clamp to three rather than not rendering the shadows at all.
* Corrected a bad calculation in ring shadow shaders that caused ring shadows to
  be drawn in the wrong place.
* Windows: Fixed the minimum feature size slider in the locations dialog so it
  updates in response to all the standard controls.
* Added a correct InfoURL for the Moon
* Windows: added splash screen with a progress indicator
* KDE: fixed some AMD64 bugs
* GTK: added splash screen with a progress indicator
* GTK: Added configure options to enable or disable Cairo support for splash
* Corrected a local flashing of the Milky Way brightness.
* Now the distance to the galaxy center is displayed, if the observer is located inside
  the galaxy (Milky Way...).
* Eliminated various incorrect Hubble type acronyms in deepsky.dsc that had penetrated
  the PERL filter.
* Add the corrected PERL script deepsky.pl.     
* Mac: OpenGL 2.0 render path should now work on many configurations
  (requires OS X 10.4.3 or later)
* Mac: Offer option to disable vertex programs automatically when ATI Radeon
  9200 renderer is detected (avoids hard crash)
* Mac: Progress message and version number displayed on splash screen
* Mac: Fixed French translation for Set Time panel
* Mac: Changed wording of "Subtract Light Travel Delay" menu item to
  "Add/Subtract Light Travel Delay" to more accurately reflect its function
* Mac: More sensible default values for preferences
* Mac: Bug fixes to favorites, InfoURL handling
* Mac: Cleaned up README in general
* Added Phoebe textures in medres and lores directories from recent published
  Cyclops cylindrical maps
* Updated  Titan and Iapetus textures in lores directory
* Windows: save and restore the last used GL render path
* Removed the GeForce FX render path; GLSL path is preferred
* Added lunar elevation map, using Clementine laser altimeter data, merged in the
  polar regions, with topographic data  from Clementine 750 nm oblique and nadir images.


Bye Fridger

MKruer
Posts: 501
Joined: 18.09.2002
With us: 22 years 2 months

Post #4by MKruer » 15.01.2006, 02:03

Thanks

Paolo
Posts: 502
Joined: 23.09.2002
With us: 22 years 2 months
Location: Pordenone/Italy

Post #5by Paolo » 15.01.2006, 14:34

Hi Fridger

Many thanks for doing this! :D

Can you please post a tarball of the whole thing or the doxyfile that you've used to create the documentation?
For the ones like me that haven't a flat internet connection it is necessary to have this documentation available offline.

Thank you again!
Remember: Time always flows, it is the most precious thing that we have.
My Celestia - Celui

Avatar
selden
Developer
Posts: 10192
Joined: 04.09.2002
With us: 22 years 2 months
Location: NY, USA

Post #6by selden » 15.01.2006, 15:00

Paolo,

The changelog is small.
You can read it (and thus download it) on the Web at
http://cvs.sourceforge.net/viewcvs.py/c ... 6&view=log
Selden

buggs_moran
Posts: 835
Joined: 27.09.2004
With us: 20 years 2 months
Location: Massachusetts, USA

Post #7by buggs_moran » 15.01.2006, 18:12

Let me premise this with "I am not a programmer." Okay then, this documentation is really cool and I am having fun perusing the code. I did come up with one question though...

Why are orbits for the solar system defined in the program code and also in the ssc file for the solar system? I suppose I could look at it further, but I am guessing there is a very simple straightforward answer to this...
Homebrew:
WinXP Pro SP2
Asus A7N8X-E Deluxe
AMD Athlon XP 3000/333 2.16 GHz
1 GB Crucial RAM
80 GB WD SATA drive
ATI AIW 9600XT 128M

Avatar
selden
Developer
Posts: 10192
Joined: 04.09.2002
With us: 22 years 2 months
Location: NY, USA

Post #8by selden » 15.01.2006, 18:26

A CustomOrbit that is defined in the code evaluates a series-expansion of approximately a thousand terms, producing an orbital path which takes into account the major gravitational effects for about +/- 3000 years from the present. Celestia currently uses an ephemeris that's called the "VSOP-87 theory." Other ephemerides are possible.

EllipticalOrbits do not take into account any gravitational effects.
Selden

buggs_moran
Posts: 835
Joined: 27.09.2004
With us: 20 years 2 months
Location: Massachusetts, USA

Post #9by buggs_moran » 15.01.2006, 18:40

selden wrote:A CustomOrbit that is defined in the code evaluates a series-expansion of approximately a thousand terms, producing an orbital path which takes into account the major gravitational effects for about +/- 3000 years from the present. Celestia currently uses an ephemeris that's called the "VSOP-87 theory." Other ephemerides are possible.

EllipticalOrbits do not take into account any gravitational effects.


Then why does the elliptical orbit information need to be in the ssc file if you are using a VSOP-87 orbit defined in the code? For information?
Homebrew:

WinXP Pro SP2

Asus A7N8X-E Deluxe

AMD Athlon XP 3000/333 2.16 GHz

1 GB Crucial RAM

80 GB WD SATA drive

ATI AIW 9600XT 128M

Avatar
selden
Developer
Posts: 10192
Joined: 04.09.2002
With us: 22 years 2 months
Location: NY, USA

Post #10by selden » 15.01.2006, 18:57

Yes.

Also, there are circumstances when you want to disable the CustomOrbit for some reason or other. The EllipticalOrbit parameters in the SSC file are reasonably close, so you don't necessarily have to get a new set. Of course, you can get more accurate ones from Horizons for the appropriate Epoch.
Selden

Avatar
fsgregs
Posts: 1307
Joined: 07.10.2002
With us: 22 years 1 month
Location: Manassas, VA

Post #11by fsgregs » 16.01.2006, 00:19

Fridger:

In your list of changes between 1.4.0 and 1.4.1, I do not see the fix for the comet coma problem. If you recall, your FT 1.2 correctly showed no coma when a comet was beyond 6 au or so. When it did show the coma, it was reasonally dim and OK looking.

In contrast, 1.4.0 final still shows an ugly coma around comets all the time, even when they are far beyond Jupiter.

Here is the screenshot.

Image

I thought I recall you reporting that this hopefully was to be fixed in 1.4.1??

:?
If this has not been fixed yet, and considering that you've already written the code for it, is there any chance it can fixed in 1.4.1? This is really a goofy looking comet coma, and detracts from the spectacular graphics that represents all other objects in Celestia!!


Frank

Avatar
Topic author
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 22
With us: 22 years 7 months
Location: Hamburg, Germany

Post #12by t00fri » 16.01.2006, 09:36

fsgregs wrote:Fridger:

In your list of changes between 1.4.0 and 1.4.1, I do not see the fix for the comet coma problem. If you recall, your FT 1.2 correctly showed no coma when a comet was beyond 6 au or so. When it did show the coma, it was reasonally dim and OK looking.

In contrast, 1.4.0 final still shows an ugly coma around comets all the time, even when they are far beyond Jupiter.

Here is the screenshot.

Image

I thought I recall you reporting that this hopefully was to be fixed in 1.4.1??

:?
If this has not been fixed yet, and considering that you've already written the code for it, is there any chance it can fixed in 1.4.1? This is really a goofy looking comet coma, and detracts from the spectacular graphics that represents all other objects in Celestia!!


Frank


Frank,

in my code so far (including FT 1.2) only the fading of the tail NOT the coma has been addressed. I understand that the fading of the coma at a threshold distance from the sun is a much less clear issue and also depends strongly on the type of comet. Like Hale-Bob had an observable coma still > 10 AU away from the sun. At that distance it had long lost its tail, of course!

So NO, there won't be any changes for now concerning the coma. In FT 1.2 it may be that the overall alpha value of the tail display was a little smaller such that also the comet head ("coma") looked weaker than in 1.4.0. But there was definitely never any attempt to implement a distance dependent coma luminosity.

The number of points in the head shape is again the former default which happended during Chris' implementation of our FT 1.2 into CVS. Improving the interpolation of the head shape of course means also a /decrease/ in performance...I may have a look there tonight and perhaps can do something here.


Bye Fridger


Return to “Development”