1.5.0 prerelease 2

[Chuft-Captain]

Will this install over the 1.4.1 version? I would like to take a look at this but I don't want to lose the older version just yet.

Reiko,

What OS are you using. I assume Win-XP?
In windows, Celestia releases install by default into the C:\Program Files\Celestia folder, so if you rename your existing folder (before installing the new version ) to something like C:\Program Files\Celestia 1.4.1, then it won't be overwritten. (You should also rename and change any existing Windows Shortcuts you have, to point to the renamed 1.4.1 directory).

There will be a similar/analogous procedure for other OS's.

If you're still not sure how to do this then PM me for more detailed instructions.

[Reiko]

Will this install over the 1.4.1 version? I would like to take a look at this but I don't want to lose the older version just yet.

Reiko,

What OS are you using. I assume Win-XP?
In windows, Celestia releases install by default into the C:\Program Files\Celestia folder, so if you rename your existing folder (before installing the new version ) to something like C:\Program Files\Celestia 1.4.1, then it won't be overwritten. (You should also rename and change any existing Windows Shortcuts you have, to point to the renamed 1.4.1 directory).

There will be a similar/analogous procedure for other OS's.

If you're still not sure how to do this then PM me for more detailed instructions.

Thanks! I just installed the 1.5.0 into a folder called celestia2 and all is happy.

[Paolo]

In the CVS version I've disabled halos around planets. I also fixed a long-existing bug in point stars mode--now the planets with an apparent size of a pixel or less will also be rendered as points.

--Chris

I've used for a while the 1.5.0 pre, I've red all the reference documentation provided by Chris. Now that I've undestrood the things behind the scenes I think that Chris' firts attempt is buggy but good. With some experimentation and further "scientific" development as claimed by Fridger it should be a great visual improvement. Specially the trasition and the clipping of the halos need to be improved. But the biggest bug is the fact that now the glare is visible around the satellites even if they are seen from the darkside.

Morevore I say again that I would prefer only two rendering styles one with HDR and one without instead than the current scaled disks, points, fuzzy points.

Kind regards.

[AlexChan]

Hmm..I am using WinXP, and I havnt turn ambient light on...
Try to think...if Earth orbit Saturn, when Earth behind Saturn and cant see the sun,
People must open light and that time, so all "planet" should turn to night light map...not 1 side is night light map but another side just have black shadow cover it...

[psCargile]

I'm new to Celestia and new to the forum, and I find the debate over halos around planets and moons to increase the appearance of brightness interesting. There are valid points for halos and no-halos, and I think its dependent on how we use Celestia.

I'm going to use it as an aid to building my own sci-fi universe, so I'm not looking for accurate realism in how things are depicted.

For those using Celestia as a desktop means to explore the regional cosmos, then that accurate realism has its place.

Would it be possible to switch on and off planetary and satellite halos like atmospheres and clouds can be with 1.4.1?

[rthorvald]

Just a little thing:
How items are named is inconsistent between the browser and the console: for example, if you have the same object defined twice in the SSC file (like two different earths for summer and winter maps), then in the browser Earth still shows up just once. But if you type "earth" into the console, it lists both entries.

I think the same behaviour should apply in both places. Preferably, it should list the object only once, no matter where it is listed.

- rthorvald

[rthorvald]

3: Crazy texture behaviour
(Click to enlarge):


... By some reason, 1.5 pre 2 messes up this model - it uses the wrong
texture for the ground. The above picture is from 1.5 pre 2, the below one
from 1.4.2. I won??t rule out a bug in the model yet, though: i have
just starte experimenting. But if it is, it is a bug only sensitive to 1.5.

... This behaviour is evident in other models too, but this is the one i have examined in detail.

1)
It makes no difference if it is in CMOD or 3ds format

2)
If i remove meshes from it, it *still* happens. But depending on which - or how many - meshes i delete from it, the texture swapping changes. It seems to be completely random, too. I at some point thought it had to do with transparency, but even when i remove ALL transparent meshes, it still happens. It happens no matter how much detail i remove.

It seems Celestia 1.5 are unable to sort many separate textures used in the same model correctly. 1.4.2 had none of these problems. (Let me add that each texture is on a separate mesh, as it should be. And 1.4.2 shows this is correct).

- rthorvald

[rthorvald]

Regarding the "texture swapping" bug:
I have now discovered that:

1.5 pre 2 is unable to show more than 3 textures in the same model.

I tested this with textures of various sizes - even as small as 128x128, and when adding a fourth mesh (with a 4th texture on it), the model breaks. This behaviour is NOT apparent if one use simply colors instead of texture mapping.


- rthorvald

[chris]

Regarding the "texture swapping" bug:
I have now discovered that:

1.5 pre 2 is unable to show more than 3 textures in the same model.

I tested this with textures of various sizes - even as small as 128x128, and when adding a fourth mesh (with a 4th texture on it), the model breaks. This behaviour is NOT apparent if one use simply colors instead of texture mapping.

Something is certainly messed up here, but I don't think that there's a three texture limit. The default ISS model is working with four textures. I'll finally have time to look deeper at this and other issues this weekend. Sorry I've been rather absent lately.

--Chris

[rthorvald]

Something is certainly messed up here, but I don't think that there's a three texture limit. The default ISS model is working with four textures

This is strange. I only get three.

My test was to create four simple, low-poly spheres and map one 64px x 64px texture to each, in the same model. Saved as 3ds. I tested with both PNG and JPG versions. The model only shows 3 textures in each case, that is, it messes up the fourth and show one of the other three instead.

This was done on this config: v.1.5 pre 2, intel OSX 10.4.8, 256 MB vram/2GB ram.

... On a different tangent, there is also something the matter with transparent textures: a transparent png file will NOT show up unless i define a transparency in % in the 3D editor, too. Which makes whatever is 100% opaque in the PNG file a little transparent, too (99% opaque works, but not 100%). Also, if i have TWO transparent PNGs, the opaque level must have DIFFERENT values for both of them to show up in Celestia. Setting both to 99% will cause one of them to be 100% invisible... Setting one to 99% and another to 98 will make both work.


- rthorvald

[Cham]

I confirm there's a problem with semi-transparent PNG textures not showing in the latest CVS celestia. Apparently, there's a weird relation between the order the pieces are ordered in the modeler and what Celestia is showing. Sometimes, putting the piece with the transparent PNG texture at the beginning of the list (or sometimes at the end) in the modeler may solve the problem in Celestia. Sometimes it makes the problem worst.

It seems to be another depth sorting bug again.

[chris]

3: Crazy texture behaviour
(Click to enlarge):


... By some reason, 1.5 pre 2 messes up this model - it uses the wrong
texture for the ground. The above picture is from 1.5 pre 2, the below one
from 1.4.2. I won??t rule out a bug in the model yet, though: i have
just starte experimenting. But if it is, it is a bug only sensitive to 1.5.

... This behaviour is evident in other models too, but this is the one i have examined in detail.

1)
It makes no difference if it is in CMOD or 3ds format

2)
If i remove meshes from it, it *still* happens. But depending on which - or how many - meshes i delete from it, the texture swapping changes. It seems to be completely random, too. I at some point thought it had to do with transparency, but even when i remove ALL transparent meshes, it still happens. It happens no matter how much detail i remove.

It seems Celestia 1.5 are unable to sort many separate textures used in the same model correctly. 1.4.2 had none of these problems. (Let me add that each texture is on a separate mesh, as it should be. And 1.4.2 shows this is correct).

- rthorvald

Thanks for the detailed bug report Runar. I was able to track down the problem and commit a fix to CVS. We'll make another prerelease shortly.

--Chris

[rthorvald]

I was able to track down the problem and commit a fix to CVS. We'll make another prerelease shortly.

Great, thanks!

BTW, something new: i have just noticed that the clock is off by several seconds if you go into BCE. I noticed because i set a Beginning date for an object some three thousand years ago, and the julian converter gave a different time than the Celestia screen. Which is _different_ than in 1.4.2, since i had previously done the exact same thing there with the same date and object... And the same converter then agreed with Celestia.

- rthorvald

[selden]

Don't forget that Celestia now uses TDB internally but displays UTC on the screen. UTC includes leap seconds and other dynamical effects that TDB does not. There currently is about a minute difference between them. The offset will be different in the far past.

For a detailed description, see http://en.wikibooks.org/wiki/Celestia/Time_Scales

[rthorvald]

Don't forget that Celestia now uses TDB internally but displays UTC on the screen. UTC includes leap seconds and other dynamical effects that TDB does not. There currently is about a minute difference between them. The offset will be different in the far past.

Aha, i see.
Well, that makes the converter i have a little messy to use... Anyone know of one that can convert Celestia screen dates to internal julian dates?

- rthorvald

[volcanopele]

I am having some difficulty getting spice kernel files to work in Celestia using this pre-release version. I am trying to create animations of the Cassini Enceladus flyby next March, so I downloaded the spice file 060323AP_SCPSE_06082_08222.bsp, which appears to be the latest file that covers that time period. I also edited solarsys.ssc for Enceladus, Saturn, and the Sun:

Code: Select all

Barycenter "Spice_Sun" "Sol"
{
   SpiceOrbit
   {
      Kernel "060323AP_SCPSE_06082_08222.bsp"
               Target "0"
                Origin "10"
      BoundingRadius 1e10
   }
}


"Spice_Saturn_Barycenter" "Sol"
{
   Color [1 1 1]
   Radius 100
   OrbitBarycenter "Sol/Spice_Sun"
   SpiceOrbit
   {
      Kernel "060323AP_SCPSE_06082_08222.bsp"
               Target "6"
                Origin "0"
      BoundingRadius 1e10
   }
}

"Saturn" "Sol"
{
   Texture "saturn.*"
   Color [ 1.0 1.0 0.85 ]
   HazeColor [ 0.0 0.0 1 ]
   HazeDensity 0.25
   Radius 60268 # equatorial
   Oblateness 0.0980
   OrbitBarycenter "Sol/Spice_Saturn_Barycenter"
   OrbitReferencePlane "ecliptic"
   SpiceOrbit
   {
      Kernel "060323AP_SCPSE_06082_08222.bsp"
      Target "699"
      Origin "6"
      BoundingRadius 1e10
   }
   Atmosphere {
      Height 300
      Lower [ 0.8 0.75 0.65 ]
      Upper [ 0.6 0.55 0.45 ]
      Sky [ 0.8 0.8 0.5 ]
   }
   RotationPeriod        10.65622 # System III (magnetic field)
   Obliquity             28.049   # 28.052   # old value: 26.73
   EquatorAscendingNode 169.530   # 168.8112 # 169.53
        RotationOffset       358.922   # correct System III prime meridian

   Albedo            0.50

   Rings {
      Inner   74500  # includes some ringlets inside edge of C ring at 74660
      Outer  140220
      Texture "saturn-rings.png"
   }
}
"Enceladus" "Sol/Saturn"
{
   Texture "enceladus.*"
   Radius     252.31

   OrbitBarycenter "Sol/Spice_Saturn_Barycenter"

   OrbitReferencePlane "ecliptic"

   SpiceOrbit
   {
      Kernel "060323AP_SCPSE_06082_08222.bsp"
      Target "602"
      Origin "6"
      BoundingRadius 1e10
   }
   Obliquity        0.0
   RotationOffset      322.9
   Albedo         0.99
}


and edited spacecraft.ssc for Cassini:

Code: Select all

"Cassini" "Sol"
{
   Class "spacecraft"
   Mesh "cassini.3ds"
   Radius 0.011
   InfoURL "http://saturn.jpl.nasa.gov/home/index.cfm"
   OrbitReferencePlane "ecliptic"
   Beginning 2450736.893877314 # 1997 Oct 15 09:27:11
   SpiceOrbit
   {
      Kernel "060323AP_SCPSE_06082_08222.bsp"
      Target "-82"
                Origin "6"
      BoundingRadius 1e10
   }
   RotationPeriod 1e9
}


Nothing else was updated or changed.

When I went to the time period for the flyby, March 12, 2008, Saturn was an object that was unavailable for selection. I couldn't select Enceladus or Cassini, or follow them, or do anything with these objects. It was as if they didn't exist. From reading the SPICE thread on the Developer forum, SPICE support was working fine for chris's edits to 1.4.1, so I am wondering if the issue is with how I tried to impliment this or with this version of Celestia.

[selden]

It's been a while since I did any Spice testing, but my understanding is that the current implementation requires Beginning and Ending statements.

Please read through the thread at
http://www.celestiaproject.net/forum/viewtopic.php?p=82509&

[selden]

Another thing I noticed in your SSC file:

OrbitBarycenter is no longer valid in v1.5.0 SSC files, although it doesn't generate any error messages. It existed only briefly in cvs code before the prereleases were made available. You need to use an OrbitFrame statement now.

[Vincent]

Chris,

Celestia 1.5.0 prerelease 2 is not localized. This is because the folders that contain the .mo files for each language are missing in the locale folder.

[chris]

Chris,

Celestia 1.5.0 prerelease 2 is not localized. This is because the folders that contain the .mo files for each language are missing in the locale folder.

Thanks for pointing this out--I thought that I had all the necessary files for i18n, but this is obviously an important omission. I'll be building 1.5.0pre3 tonight, I think. We're obviously not ready for 1.5.0 final, but there have been some important fixes, and a new prerelease is long overdue.

--Chris