Well, let me also comment about my prersonal impressions as to Chris'
proposal for new features in 2.0
First of all...
As to GUI improvements in general, I am confused about Chris' underlying
attitude w.r.to the various platforms: Some of his proposed
improvements, including an easily customizable toolbar, programmable
key-shortcuts in a luxourius graphical interface, are since long an
integral part e.g. of the KDE environment and thus of KDE3-Celestia. So
were his proposals just for catching up with Windows?? Or are we
supposed to unify the GUI features now? He referred nowere to the
platform(s) (and the toolkit) he was thinking of...
Two years ago I have suggested to take Qt as a cross platform toolkit,
but as we know, there are also problems...
Specifically, what I think:
-- Key shortcuts:
I definitely agree that the key shortcuts need systematization! I am
less hot on offering fully programmable ones at the USER level (as is
'automatic' in KDE3). Programmable keys may be more useful for
adaptations at a later stage of Celestia development.
What do we (i.e. the average user) gain by this considerable coding
effort? I bet this feature will create confusion to quite some extent.
For instance, we cannot refer anymore in an unabiguous way to certain
keys when helping people etc.. Personally, I never used this key
programming feature in my KDE3 version, although there the
implementation is VERY luxurious, indeed.
I am also somewhat sceptical whether the 'two-letter' key scheme of
Christophe will really 'catch on'. Despite my love for systematics I
find it an 'overkill' in some respects. Indeed you find such schemes
rarely in professional software. Personally, I would prefer a
'classical' 1-key, CTRL+1key, ALT+1key assignment that puts /mnemonic
considerations and simplicity/ first. For me, the multi-language
argument concerning mnemonics is not too convincing (again a more
What might be really useful is to allow binding of keys to scripts!
Again here, I have rather mixed feelings more recently like Pat, I guess.
I have strongly advocated a toolbar in the GUI already close to /two
years ago/, and have even coded some protoype realization myself for
GTK1-Celestia at the time. But then the Linux port switched to KDE3,
where toolbars are an integral "part". Subsequently, I noted that I
have never used the KDE3 toolbar a single time, since its presence just
disturbs the beautiful /fullscreen/ Celestia display too much! I tend to
switch off all 'bars' most of the time! What is really desirable
(Gnome!), is to incorporate a shortcut for switching off the main
Menue bar! [ CTRL-M in KDE. ]
So I see a toolbar rather as a 'beginner' feature with clear
drawbacks. Also, as the experience with the KDE3 toolbar has shown, it
is not easy to design sufficiently clear ICONS that are mnemonic enough
for beginners, given the complex commands we face in Celestia! Think
about an icon that reminds you of what the key 'T' does :-! ... To some
extent, toolbars are more of a 'fashion' feature than a real help...
--Info display overlay
Here I have also written proposals for impovement a long time ago
that --as so often-- remained unresponded...
In general, I think we should be very /conservative/ in what is
displayed, since again too much default output tends to destroy
the nice graphical impression in the main canvas. In a 'nutshell', my
proposition was to move all info that is /independent of the observer's
distance-vector/ (like object radius, daylength, temperature,...) to the
-- General coordinate readouts & respective grids
Again I proposed these things in a very general setup 1-1/2 years ago
and am ashamed that I never came around to implement them myself. Now
that Chris puts these things up again, we are probably going to make it
;-) . [Unfortunately, around that time my professional duties changed
considerably and my remaining time for coding was seriously cut back since.]
So clearly I am very keen to have this important feature finally
This is a very interesting extension that we have widely discussed
already. I would like to have the implementation correlated with the
possibility to click the available light-curve measurements that are
available from AAVSO in nice diagrams for display! I have discussed this
at length in the forum previously. The AAVSO data base of light-curve
diagrams for many binaries is also implemented in XEphem. Once AltAz
mode and coordinate readout is also implemented, amateur astronomers
will be very happy with Celestia as well and appreciate the AAVSO light
curves very much!
Clearly, here we need a considerable improvement as was also discussed
widely before. Various bug reports I wrote are directly related to this
and are still pending. Again as I proposed earlier, we should also
consider (B)splines besides double precision...
-- Internet Updating of satelite data
As I illustrated in the forum in the case of XEphem, an FTP updating
of TLE orbits can be very conveniently realized. It is amazing
to imagine that the great majority of users is presently using
satelite orbits that are so unprecise that the satelites could never be
observed from peoples backyards when they are passing overhead...For
actual observation of satelites, the orbit data should not be older than
A FEW DAYS, as my detailed experiments have shown when we incorporated
all this into XEphem.
Chris Laurel wrote:
>Now that I've shared my thoughts about what needs to be done to wrap up
>Celestia 1.3.2, I want to give my ideas for the next version of Celestia.
>I'd like to call the next version Celestia 2.0. This reflects some
>significant and very visible changes I think we should make in the user
>interface, rendering capabilities, and elsewhere. It'll be a good time to
>'clean house' and get rid of some ill-considered features of Celestia that
>are hampering further development, or are just plain ugly. I don't want
>to break backward compatibility with the large body of add-ons and scripts
>that people have created for Celestia, but I am willing to eliminate
>infrequently features that are causing us grief.
>Here are some ideas I've been thinking about over the last few months:
>- User Interface
> - Implement a customizable keyboard interface with many commands
> accessed via two-key sequences. A new keyboard interface was
> discussed a while ago on this list, and I think we even came to a
> consensus on Christophe's proposal for how it should work. As I
> recall, the proposal allowed (but didn't require) keys to be bound
> to scripts, and allowed customization via a text file.
> - Add a toolbar with frequently used commands. Easier to use than
> keyboard commands if you're new to the program. Less cumbersome and
> more immediately visible than the View options dialog box.
> - Improve the heads up display. The information shown now is a
> hodge-podge of data, especially the selection information. We should
> discuss what information to display and how to best arrange it
> on-screen. One idea I have is to split physical properties of the
> selected object from 'navigational information' i.e. things that
> depend on the observer's position and velocity like distance. The
> physical properties could be shown in a separate information panel
> that could be toggled on and off.
> Navigational info:
> Apparent diameter
> Phase (what does this mean in a binary system?)
> Relative velocity
> Info panel:
> Orbital period
> Rotation period
> Distance from central body (Celestia should be smart enough to
> print 'Dist to Sun' for Earth, or 'Dist to Saturn' for Titan,
> I'm all for eliminating temperature and other derived figures of
> questionable accuracy and relevance, or at least banishing them to
> a separate information panel.
> - Telescope mode. Alt-azimuth mode still needs some work. Show the
> RA/Dec (appropriate for the current reference world) of the cursor and
> the selection. Display a compass on the horizon of the reference
> - New grids: ecliptic, alt-azimuth, galactic. Integrate Selden's
> graticules into Celestia so they can be easily toggled; create
> property dialogs to select units and other options for the graticules.
> - Multiple star systems (finally!). Keplerian elements should be
> adequate for orbits. I've thought of a way to integrate moving
> stars into the static visibility octree--as long as the motion is
> bounded, there's no trouble.
> - Define a multiple star system by specifying the barycenter and an
> elliptical orbit, hierarchically for systems with three or more stars.
> - Extended star attributes: override standard texture, shape, or other
> properties on a per-star basis. Shape can be the standard sphere,
> oblate spheroid, ellipsoid (close binaries), or a mesh (artisitic
> renditions of pulsars, and more)
> - Catalog cross-references. No more hardcoding HD and HIP catalog
> numbers into the star class. Instead, have a unique internal
> id in the star instance, with external tables for HD, HIP, SAO,
> Gliese, or whatever other catalogs.
> - Spectral class improvements. Complete list of spectral classes; we're
> missing white dwarf types now, probably others. Use an external data
> file for spectral class properties like temperature, radius, surface
> - Consider: Colored star light for K, M, and C stars seems to be an
> unpopular feature. It probably should be eliminated . . . But, what
> about contrasting star light colors in multiple star systems?
> - JPL DE200/405/406 ephemerides. Supported now, but still some error
> (less than VSOP87), possibly related to using the wrong time standard.
> Make a JPL ephemeris package available as an add-on. Still need to do
> some extra work to use JPL ephemerides for the Moon.
> - Double precision xyz files
> - Need a better lunar ephemeris, like ELP2000
> - Still using Keplerian elements for some important solar system bodies:
> Phobos, Deimos, Triton, Phoebe. Finish work on custom orbits for
> - Implement new coordinate systems for orbits so we're not forced to use
> the equator of the parent body as the reference plane. This will
> permit turning on precession for Earth, and will make it easier to
> incorporate elements and coordinates from Horizons
> - New orbit types:
> - TLE orbits for artificial satellites of Earth
> - Precessing ellipse
> - Lagrange point orbit type - to keep satellies in Langrangian points
> from drifting away from coorbital bodies with CustomOrbits
>- Improved rendering
> - Correct occlusion of objects that overlap in depth (already have it!)
> - Bring mesh rendering to parity with sphere rendering. This means
> specular maps, normal maps, glow/night maps. Work in progress now,
> but won't be ready until after 1.3.2.
> - Begin using GL Shading Language for shaders--only very recent drivers
> support it, but it makes writing shaders much easier.
> - Fix shadows with ambient light
> - Light from more than one source: binary star systems, planet shine,
> light reflected from rings.
> - Correct eclipse shadows: use circle-circle intersection to do
> penumbrae right.
>- Physically based illumination
> - Full implementation only on hardware that permit blending with
> floating point frame buffers (i.e. just GeForce 6800 for now). Half
> precision floating-point (fp16) gives a range of brightnesses of
> about 2x10^9.
> - Manual or auto-exposure
> - No more fudging of star brightness. For example, stars will just
> 'automatically' disappear from the daytime sky. Because they're
> rendered at a much lower brightness, they're contribution will
> be neglible when blended with the sky.
> - Bloom effects via post-processing (Gaussian filter, efficient
> because it's separable)
> - Better star rendering: glare should be Gaussian - no more atmosphere
> hack (it's linear). Render faintest stars as points
> - Need magnitudes for galaxies and nebula so that their brightness can
> be adjusted for the current exposure.
> - Compute star colors from blackbody spectra, but still offer 'enhanced
> color' mode for those who prefer it
>I have sections to write on atmopshere rendering, mesh animation, and
>miscellaneous features, but I'll postpone that because there's already a
>lot to digest here. I look forward to feedback on my vision for Celestia
>2.0, comments on individual features I've listed, and suggestions for
>other ways to improve Celestia. Fridger, I've deliberately omitted
>conformal mapping and multi-wavelength from my list, because I thought
>you'd like to present them (I've been following the most
>recent multi-wavelength discussion in the forum.)
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>digital self defense, top technical experts, no vendor pitches,
>unmatched networking opportunities. Visit http://www.blackhat.com
>Celestia-developers mailing list