Things to fix in Celestia (IMO)
Posted: 24.11.2005, 20:06
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:
---------------------------------------------------------------
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 .
---------------------------------------------------------------
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 .