Celestia 1.3.2pre8

[chris]

A new prerelease package is long overdue . . . Get it here:

http://www.spacesim.net/prerelease/cele ... .2pre8.exe

This new package has changes to scripting and many data file updates, including corrections to stars.dat and extrasolar.ssc. solarsys.ssc has split into several files: asteroids.ssc, comets.ssc, outersys.ssc, and spacecraft.ssc. A model and trajectory for the Cassini mission are now part of the standard package (so you'll have to make some adjustments if you've already installed a Cassini add-on.) Finally, labels of solar system objects can now be occluded by objects in front of them--I'm very interested in feedback on this.

--Chris

[granthutchison]

When I hived off outersys.ssc, I took the opportunity to add some of the largest Edgeworth-Kuiper bodies, as well as Sedna from the inner Oort.
So if you have made yourself add-ons containing Sedna, 2004 DW, Quaoar or 2002 AW197, you need to know that they'll cause duplications with the new Celestia installation.

Grant

[Bob Hegwood]

The new addons - as part of the basic package - are a great idea. Also like the
location displays a lot better, and the entire package was a piece of cake to
install and modify for all of the different textures and addons that I have.

The Phobos, Deimos CMODs look fantastic with a good texture applied, and they
seem to appear much more realistic on my limited machine.
Great piece of work.

Thanks muchly, Bob

[selden]

None of the new shader routines are included with pre8

texphong_arb.vp
texphong_nv.fp
bumpdiffuse_nv.fp
diffuse_nv.fp

are all missing.

Until pre9 is available, they can be downloaded from
http://cvs.sourceforge.net/viewcvs.py/celestia/celestia/shaders/

[symaski62]

None of the new shader routines are included with pre8

texphong_arb.vp
texphong_nv.fp
bumpdiffuse_nv.fp
diffuse_nv.fp

are all missing.

Until pre9 is available, they can be downloaded from
http://cvs.sourceforge.net/viewcvs.py/celestia/celestia/shaders/

merci

nouveau
texphong_arb.vp
texphong_nv.fp
bumpdiffuse_nv.fp
diffuse_nv.fp

prochaine 4 semain C 1.3.2 pre 9

/symaski62

[TERRIER]

A model and trajectory for the Cassini mission are now part of the standard package (so you'll have to make some adjustments if you've already installed a Cassini add-on.)

--Chris

Cheers for the new pre-release, I've not had chance to run it yet as I'm in the process of re-organising some of my Celestia files.
I'm wondering if the new Cassini and Huygens Probe xyz trajectories are more up to date / accurate than the ones provided by Jack in his original add-on. Should I replace them ?

None of the new shader routines are included with pre8 .......

Merci for this information, from me too

[granthutchison]

I'm wondering if the new Cassini and Huygens Probe xyz trajectories are more up to date / accurate than the ones provided by Jack in his original add-on.

They're the trajectories currently available from JPL Horizons, with the new planned Huygens release, which was pushed back from Nov to 25 Dec 04. Jack's now taken down his Cassini xyz, but the last note on his site says that he's waiting for the trajectory for the new Huygens release to become available, so I guess his add-on is no longer current.

Grant

[Evil Dr Ganymede]

Shaders?

Does that mean it's possible for someone to code a Lommel-Seeliger photometric function for surfaces of the airless bodies in the solar system?

[Bob Hegwood]

Selden...

Shaders? These won't have any effect on my machine will they?
I haven't noticed anything different yet, except that some of the objects
look a lot better for some reason. Is this the effect of the CMOD's?

Thanks, Bob

[selden]

Oh Evil One,

The "vertex shaders" I'm referring to are OpenGL routines that are loaded directly into the graphics hardware. They help support the code that does specular reflections, as well as the smooth penumbral shadowing that currently requires FX cards, for example. I suspect that alternative terminator shadowing functions would require new shader routines, too.

Bob,

No, you won't need them. They're used by cards that support some of the newer OpenGL v1.4 functionality.

Yes, some objects do look better because of their improved CMOD models. In principle, I suspect some of the improvements could have been done using 3DS models, but they would have been harder to do. Some of the 3DS models haven't been converted yet, though.

[Bob Hegwood]

Finally, labels of solar system objects can now be occluded by objects in front of them--I'm very interested in feedback on this.

Chris...

Just viewed the locations of Phobos while displayed in front of Mars, and the
occlusion is very nice in my opinion. You can pick out the locations of craters
on both Mars and Phobos at the same time, and the occlusion effect maintains
a rational approach to viewing the locations on one object - as opposed to the
other. Personally, I *like* it...

Just me though.

Thanks again for the new pre-release. I also *very* much like the CMODs.
I'm getting some fantastic resolution and detail of Phobos and Deimos now -
even on my graphically-challenged machine. Very Nice.

Take care, Bob

[Toti]

Chris,

Thank you very much for the prerelease. As Bob already wrote, the effect on screen readability is superb!
What is the performance tradeoff of this new feature? Can this be applied to markers as well?

A minor thing: sometimes -when viewed from certain angles- a planet label is hidden by its signaled body. This is specially notable with Earth.
It happens in windowed and fullscreen modes, but in the latter case, when the mouse pointer pops up the menu bar the label reappears.
Unfortunately WinMe refuses to take cel://url so these bookmarks are the only thing I can send as an example (I have all View Options menu options checked)
Move around a little. The planet label should appear and disappear:

Code: Select all

"Earth" {
   isFolder false
   parentFolder ""
   base   [ 0.003254203044555212 1.537157635092788e-009 1.415602140260928e-005 ]
   offset [ 1.637370794504989e-013 0 -5.827586677109586e-017 ]
   axis   [ -0.129596 0.585784 0.800039 ]
   angle  1.75004
   time   2453148.543372872
   selection "#0/Earth"
   coordsys "geographic"
}

"Jupiter" {
   isFolder false
   parentFolder ""
   base   [ 0.003177186229666954 1.794401221096803e-006 -1.490781696092525e-005 ]
   offset [ 1.155030932009638e-013 1.441988889405721e-017 -7.404558736989753e-016 ]
   axis   [ -0.94042 -0.338387 -0.0332294 ]
   angle  1.36785
   time   2453148.367353901
   selection "#0/Jupiter"
   coordsys "geographic"
}

"Neptune" {
   isFolder false
   parentFolder ""
   base   [ 0.003588640084100748 -4.467839493376083e-007 0.0003448497580371347 ]
   offset [ 2.114831747224155e-013 2.656295322589486e-017 1.957272234912044e-014 ]
   axis   [ 0.118723 0.687208 -0.716694 ]
   angle  3.02421
   time   2453147.779039026
   selection "#0/Neptune"
   coordsys "ecliptical"
}



Also, I noticed that body labels aren't showed when viewer is really close to them (a behaviour that I prefer). Is this intentional?

Bye

[Bob Hegwood]

Another note: This concerning the start.cel...

This is a very nice way to set up the program so that you can view what you
want to view, and to NOT view what you do not want to view. I would make
the following suggestion though...

You might wish to move the main scripting code (i.e. - the script that takes
you first to the Sun, and then to the Earth) to the BOTTOM of the start.cel.
This way, the user can simply un-comment anything he/she wants prior to the
actual execution of the starting script. As it is now, you have to move the
"renderflags" commands to the beginning of the script, or the effects will not take
place until *after* the Sun and Earth have been displayed.

Just a thought for you.

Thanks again for this great update.

Take care, Bob

[don]

Howdy Bob,

Thank you for your compliments on the new start.cel (I wrote it).

You might wish to move the main scripting code (i.e. - the script that takes you first to the Sun, and then to the Earth) to the BOTTOM of the start.cel.

For an experienced scripter, this would be a good idea. However, the intended audience is those UNfamiliar with scripting, so the actual default script code being executed is best listed at the top of the file. Otherwise, it may confuse beginners.

Also, Celestia remembers render settings from one session to another, so once set, the renderflags stay that way until they are physically changed.

Lastly, even with the renderflags being set after the Earth is displayed, all modified flags are displayed as defined when the script is finished. Thus, I don't think where they are set in the script really matters that much.

Just my opinion, but I'm certainly open to other viewpoints and reasonings.

Cheers,

[Bob Hegwood]

I don't think where they are set in the script really matters that much.

Okay, Don... No problem. I just thought I'd mention it because if I have used
markers previously, then they still show up on the Sun and the Earth prior to
being removed by the options which are set *after* the opening display. In fact,
if you have the cloudmaps turned off, the start.cel will first display the Earth
without its clouds, and then it will turn them on as you're looking at the opening
display. Again though... I think it's a great improvement over the previous
start.cels.

Thanks, Bob

[don]

I just thought I'd mention it because if I have used markers previously, then they still show up on the Sun and the Earth prior to being removed by the options which are set *after* the opening display.

Yes, the initial 3 or 4 second display of Sun-->Earth will show the options previously changed manually -- until the start.cel script is finished. Is this what you are saying? Folks who know CEL scripting can certainly move the display code to the end of the script, but I hesitate to do it for everyone since they may look at the first few lines of "modify this code", get lost and simply give up.

Have you noticed that no matter what time of day you run Celestia that the Earth is always showing it's sunny side? This was Chris' idea and it works well.

[TERRIER]

I've not had chance to run it yet as I'm in the process of re-organising some of my Celestia files......

I've had chance to have a look at pre8 now and have also downloaded and installed the 4 missing shader routines that Seldon has mentioned.

All seems fine....except that I seem to lose the haze effect for planets, when I view them using the 'new' NVIDEA Geforce FX render path. (This is especially noticeable when looking at Titan).

However, the haze effects are present when using the Open GL vertex program / NVIDEA combiners render path.

Anyone else noticed this, and can it be easily fixed ?
BTW the haze effect was fine in pre7 when using the NVIDEA GeForce FX render path.

regards,
TERRIER

[chris]

All seems fine....except that I seem to lose the haze effect for planets, when I view them using the 'new' NVIDEA Geforce FX render path. (This is especially noticeable when looking at Titan).

The GeForce FX render path is still experimental . . . In subsequent versions of Celestia haze will be rendered in a fundamentally different way, as part of the atmosphere instead of the surface of planets. I'm not going to bother making it work in the GeForce FX render path until then.

--Chris

[chris]

Shaders?

Does that mean it's possible for someone to code a Lommel-Seeliger photometric function for surfaces of the airless bodies in the solar system?

I'm planning on doing this myself . . . Until then, you might be able to write a custom version of the diffuse_nv.fp shader. Actually, I think it will take some modification to Celestia so that the appropriate surface properties (tangent space eye and light directions) are generated per pixel. Currently, these attributes are only generated per pixel for bump mapped surfaces.

--Chris

[chris]

A minor thing: sometimes -when viewed from certain angles- a planet label is hidden by its signaled body. This is specially notable with Earth.

This is a bug; I should have this fixed in the next prerelease.

--Chris