Things to fix in Celestia (IMO)

[Malenfant]

I've been thinking lately of some of the main problems I have with Celestia, that I believe need to be a priority to be fixed. This is just my opinion of where the priorities should be - of course, others' opinions will probably be different . I'm just throwing this out there to focus a bit of discussion on these, especially now that development seems to be picking up again finally. In no particular order:

---------------------------------------------------------------

1) Incorrect constants/values need to be corrected: Celestia currently uses an incorrect value for the speed of light, and offsets the position of Sol from the coordinate origin at an arbitrary distance. (see posts on this page of the FT1.2 thread and the stars.dat thread). The speed of light problem definitely needs to be corrected as this is a major flaw in any claim to realism.

The Sol offset should IMO also be corrected - it's an inelegant holdover from an old system that we don't need anymore, and frankly it makes no sense to keep it (it's surely not too much to expect any scriptwriters affected by this to fix their cel URLs themselves).

Also we need to ensure that the values used for planets in solarsys.ssc are accurate. I've sent updated albedos to Grant but haven't heard anything back from him (did they get incorporated into the latest CVS?)

---------------------------------------------------------------

2) Barycentres: Several things here:

a) we need to be able to see the orbits of objects around Barycentres.
b) Barycentres need to be defined as the parents of objects that are orbiting them. Otherwise they are inaccessible in scripts (plus the current situation is just plain inconsistent with how other hierarchies are implemented in Celestia).
c) Barycenters should be defined in a similar way for planetary bodies as they are for stars. ie. define a barycenter that orbits a star, then put the planets in orbit around that. This should be possible without using an invisible object - just a simple barycenter definition statement.

e.g. like this:

Code: Select all

"Barycenter 1" "Sol"
   EllipticalOrbit {
      Period          50.09
      SemiMajorAxis   19.8
      Eccentricity    0.592
      Inclination   97.51
      AscendingNode   161.33
      ArgOfPericenter 184.56
      MeanAnomaly     40.89
   }

"Planet 1" "Barycenter 1/Sol"
{ data }

"Planet 2" "Barycenter 1/Sol"
{ data }


---------------------------------------------------------------

3) 16000 ly Distance limit: see this thread - particularly "The real long-term solution is to allow multiple star databases, each referred to a different center. This is analgous to the way that solar systems are handled now, with the coordinate system for planets 'rezeroed' to the location of central star." This topic keeps coming up and perhaps it's time to take a look at this properly.

---------------------------------------------------------------

4) Photometry of surfaces: The current shaders are not at all realistic for many planets. Accurate photometric functions need to be implemented, such as Lommel-Seeliger or Buratti or maybe even Hapke, so we don't see limb-darkening in Celestia where we shouldn't see it (eg the Moon). Raleigh scattering in atmospheres would also be a nice thing to see, but I'm not sure how implementable that is without raytracing. See the bottom of http://www.mmedia.is/~bjj/3dtest/ for a visual demonstration of the difference this makes.

---------------------------------------------------------------
5) Multiple Lighting: I don't know if the implementation of multiple light sources was completed, but if not, it should be .

[granthutchison]

I've sent updated albedos to Grant but haven't heard anything back from him (did they get incorporated into the latest CVS?)

Fridger sent me your albedos for comment, and I replied pointing out that Celestia would need both Bond albedos and visual geometric albedos to work accurately, but I suggested that the pair of you should do whatever you liked with the ssc data.
Didn't you receive that e-mail?

Grant

[Malenfant]

I've sent updated albedos to Grant but haven't heard anything back from him (did they get incorporated into the latest CVS?)

Fridger sent me your albedos for comment, and I replied pointing out that Celestia would need both Bond albedos and visual geometric albedos to work accurately, but I suggested that the pair of you should do whatever you liked with the ssc data.
Didn't you receive that e-mail?

Hm, I thought I replied to that? *looks at emails again*. Oh, right, I see, you did reply, sorry .

My own feeling is that for now it's best to just use the visual albedos for now and not worry about the Bond ones, because as it stands temperature isn't accurate in Celestia anyway (if an atmosphere is present, anyway).

Though ideally the solution would be to add a Bond Albedo term (and a greenhouse effect term) and then we can use them both .

Another possible thing to add would be to make the brightness of the roughly pixel-sized dot you see when you look at a planet from far away vary depending on how illuminated it is from the observers' viewpoint. So if the distant planet was 'full' then the dot would be brightest, if it was half-lit then it'd be grey, and if it was unlit as seen from the observer it'd be black.

[cpotting]

1) Incorrect constants/values need to be corrected

In the stars.dat thread I didn't see any need to break the existing cel urls to fix the offset problem. However, I do agree that the light-year problem should be fixed - even if it does break the cel urls. It is a far more serious problem. Now, if the cel urls are going to be broken in order to fix the light-year problem, then my only reason for not fixing the offset problem becomes moot.

Therefore, IMHO: fix away!

2) Barycentres: Several things here:

a) we need to be able to see the orbits of objects around Barycentres.

agreed

b) Barycentres need to be defined as the parents of objects that are orbiting them. Otherwise they are inaccessible in scripts (plus the current situation is just plain inconsistent with how other hierarchies are implemented in Celestia).

I'm not sure about this. My concern here is that if the parent object for a system is the barycentre, then it is not possible to tell which child is the traditional parent. E.g., if the all the bodies in our solar system orbit a common barycentre, then how can a script distinguish Sol as the main or traditional centre of the system? Similarly, if Jupiter and all it's moons orbit a common barycentre then how does one find that this is the "Jupiter" system?
Ideally (but probably not practically), we could define either the barycentre as the parent and Sol as the uncle, or visa versa.

c) Barycenters should be defined in a similar way for planetary bodies as they are for stars. ie. define a barycenter that orbits a star, then put the planets in orbit around that. This should be possible without using an invisible object - just a simple barycenter definition statement.

Shouldn't the star orbit the barycentre?

3) 16000 ly Distance limit

I agree

4) Photometry of surfaces

I agree

5) Multiple Lighting

I thought this was implemented.