Celestia 1.4.0 prerelease 4

[chris]

Yet another 1.4.0 prerelease for Windows:

http://www.celestiaproject.net/~claurel/celest ... e4-exe.zip

This one is identical to 1.4.0pre3 except for two things:
- Cloud layers should be properly illuminated by multiple light sources--no more black clouds or abrubt changes in brightness.
- I made a few changes to the OpenGL 2.0 shaders so that they should now work with the ATI driver. If you have a Radeon 9500 or later, I'd appreciate the testing; if you see red planets when the OpenGL 2.0 path is enabled, make sure you post the contents of shaders.log to the bugs forum. It's the only means I have to get to the bottom of these problems.

--Chris

[Cormoran]

Chris et al,

Woohoo! First review of 1.4.0 pre 4 is me

Okay, having downloaded the EXE, I tried it. Sheer loveliness on the clouds. Also seems faster on the framerate.

Now all we need is Grant and Toofri's Near Star Add-on (don't rush guys, do your usual excellent job )

As a side-question, how many binary systems are you guys going to code?

Cheers,

Cormoran

[kikinho]

The version 1.4.0 pre 4 will work good for Nvidia FX 5200 cards with 512 Mb RAM about framerate or Celestia still slows down? I'm doing this question because i'm not home, and the computer i'm using is different than mine.

[t00fri]

Chris et al,

Woohoo! First review of 1.4.0 pre 4 is me

Okay, having downloaded the EXE, I tried it. Sheer loveliness on the clouds. Also seems faster on the framerate.

Now all we need is Grant and Toofri's Near Star Add-on (don't rush guys, do your usual excellent job )

As a side-question, how many binary systems are you guys going to code?

Cheers,

Cormoran

I don't know about Grant. He seems away since several
days. Last time we communicated about the matter he
and me were looking into the 6th catalog of binary
orbits, that has about 1800 orbits. Yet it does not have
mass ratios which are crucial to determine the
baycenter...


Since about one week, I am working instead with 205 /completely/
analyzed orbits (based on Hip and Tycho astrometry and
notably the amazing Hip Transit data) . The results are
from a very sound professional paper (which I have).


These 200+ orbits also include a careful determination of
the required /mass ratios/!


Many orbits have less than 10% uncertainty on m2/m1!
There are also narrow spectroscopic doubles in the list!


What is missing here are the spectral classes
(eff. surface temperatures) of the secondaries. Since a week or so, I
work on that issue...exploiting and combining HR
(luminosity-temperature) and mass-luminosity relations
for the primary components, whose spectral classes and
luminosities are all given. And I know their masses...try
to find universal curves that may be used to infer the
spectral classes of the secondaries...

Bye Fridger

[TERRIER]

Woohoo! First review of 1.4.0 pre 4 is me

Bah, it mighta been me, if I hadn't been down at Tesco's

The version 1.4.0 pre 4 will work good for Nvidia FX 5200 cards with 512 Mb RAM about framerate or Celestia still slows down?

Yeh, I'm still experiencing slowdown, especially when viewing Saturn up close. I'm still getting a reasonable 7-8 fps when looking at Saturn with the 'multiple Sol' set up, which I guess is working my video card really hard, but I've got to say that everything looks fine.

[Evil Dr Ganymede]

What is missing here are the spectral classes (temperatures) of the secondaries. Since a week or so, I work on that issue...exploiting HR (luminosity-temperature) and mass-luminosity relations for the primary components, whose spectral classes and luminosities are all given. And I know their masses...try to find universal curves that may be used to infer the spectral classes of the secondaries...

You've got those already. You should be able to figure it out from the mass-luminosity table I posted in the double stars thread.

[TERRIER]

Just another question about the forthcoming binary star systems - will they be kept separate from the main stars.dat ?

cheers,
TERRIER

[selden]

Terrier,

Can you provide a URL of your slow Saturn display and/or a description of what it looks like?

I get between 30 and 60fps. I'd expect you to get at least half of that, since your CPU is about half the speed and the graphics card is the same.

60 fps, 50% CPU utilization:
cel://Follow/Sol:Saturn/2004-11-01T20:19:52.37568?x=AORG97W30iOKDA&y=iieQHK5+tcP//////////w&z=VRQGVyfIqJN6/////////w&ow=-0.880252&ox=-0.341286&oy=-0.320637&oz=0.076638&select=Sol:Saturn&fov=40.650936&ts=1.000000<d=0&rf=38839&lm=71

I have an LCD display which only runs at 60Hz. A faster screen refresh rate would increase Celestia's CPU utilization, of course.

30fps, 100% CPU utilization:
cel://Follow/Sol:Saturn/2004-11-01T23:54:56.99416?x=gCyW2v0SdyaKDA&y=ylRFiFIkQrT//////////w&z=XdnBhBxwEYp6/////////w&ow=0.417640&ox=-0.678876&oy=-0.203846&oz=0.568464&select=Milky%20Way&fov=40.650936&ts=1.000000<d=0&rf=38839&lm=71

I'm guessing that the framerate falls off because parts of the rings are off-screen and clipping is expensive.

System:
512MB 2.4GHz P4, WinXP Pro SP2
128MB FX5200, ForceWare v66.81 (beta)
AGP 4x, 1600x1200, 32bit color
Celestia v1.4.0pre4

[t00fri]

What is missing here are the spectral classes (temperatures) of the secondaries. Since a week or so, I work on that issue...exploiting HR (luminosity-temperature) and mass-luminosity relations for the primary components, whose spectral classes and luminosities are all given. And I know their masses...try to find universal curves that may be used to infer the spectral classes of the secondaries...

You've got those already. You should be able to figure it out from the mass-luminosity table I posted in the double stars thread.

I am considerably beyond your table since quite some
time...


Rather than using stellar evolution theory, I prefer to
study actual binary data with /measured/ masses and
luminosities directly.


1) I exploit the original (binary) catalog(s) and use
exactly the same 'spectral class - temperature'
conversion lookups as in Celestia's star.cpp for
consistency. So I can examine the binary stars in
question, given their data on mass and luminosity. Still I
am examining at present, which of the various familiar
"visual" luminosities is "best" i.e produces most
universal results:

Johnson (V_J) , Hiparcos (Hp) or Tycho (V_T).
The conversions are known but somewhat messy...
(it's all in my Perl scripts of course). Bolometric
luminosities seem to be less universal in fact.
For the bolometric corrections I also employ the ones
used in Celestia.


I do not remember any discussion on these important
issues in your post. Since I am using Perl and my
professional plotting tools, examining these different
possibilities takes comparatively little time.


In my analysis, I put great efforts to taking experimental
uncertainties into account. That's the advantage of my
"direct" method: all data I use, have carefully
determined error bars that can be propagated via
Gauss ... The stellar evolution theory has none...


2) The mass-luminosity relation task is close to trivial and
finished for main sequence stars, of course.


Your table also refers mostly to those I gather. But I
need more, of course. That's where the main work is
sitting. The secondaries in my binary systems include
notably plenty of white dwarfs and other "break outs".


Anyhow, it's a lot of fun and I am progressing steadily. If
only I had a little more spare time.


Bye Fridger

[t00fri]

Just another question about the forthcoming binary star systems - will they be kept separate from the main stars.dat ?

cheers,
TERRIER

Yes. I will Perl-generate an stc file for them in the forthcoming distribution.

Bye Fridger

[selden]

Terrier,

Please ignore my previous question.
I realized that I wasn't using the correct STC file.
When I use the correct one, my framerate gets cut in half (30fps and 15fps), so that seems to be consistant with your 7fps.

Sorry to have mislead you

[Guest]

I thought I would drop you this note about the New pre-release. I have a Geforce2 MX graphics card and I am able to see eclipse shadows for the first time that I can recall.

I am glad to be able to see the moons shadows now, but the shadows don't seem to quite line up at the point of maximum coverage. I am not sure why this is, but I am just excited about seeing them regardless.

I thought you may be interested in this finding. I can't wait until everything is complete. Keep up the good work and thank you very much for a wonderful astonomical masterpiece.

[maxim]

selden,

is the AGP4x setting mentioned above due to any configuration consideration or just a hardware limit of your system?

maxim

[selden]

Maxim,

I mentioned AGP4x because it's a feature of my system at work and would be one of the features affecting performance.

The speed of the AGP slot is one of the things which limits the speed at which textures and OpenGL shaders can be loaded into the graphics card. Many current generation cards (like the FX5700LE) claim to support up to AGP8x. (Whether they actually can take advantage of its speed is another matter entirely.) The PCIexpress interface used by the newest cards supposedly is another factor of 2 faster.

My system at home has only AGP2x, but that's supposed to be faster than the speed provided by a standard 16bit PCI interface.

[maxim]

That encourages me a bit
My systems AGP Bus is limited to 4x, and I always refused to think of buying a cheap FX-card (instead of my MX card) because I had the opinion that it doesn't make sense if the hardware is limited anyway.

So I will think about it again.

maxim

[selden]

Maxim,

FWIW... I upgraded my home system's graphics card to an FX5700LE a week or so ago just to be able to see the new Celestia eye candy.

The clock speeds of the FX5700LE are essentially identical to the clock speeds of my previous Ti4200, but it seems to have slightly better performance. I had been thinking about waiting for the 6200 to be available, but apparently they intend to make that card only with a PCIe interface.

[chris]

That encourages me a bit
My systems AGP Bus is limited to 4x, and I always refused to think of buying a cheap FX-card (instead of my MX card) because I had the opinion that it doesn't make sense if the hardware is limited anyway.

It's very unlikely that the speed of your AGP bus will be limit the performance of Celestia. Other factors are much more significant; pixel processing power is probably most important, especially in the OpenGL 2.0 render path.

--Chris

[maxim]

It's very unlikely that the speed of your AGP bus will be limit the performance of Celestia. Other factors are much more significant; pixel processing power is probably most important, especially in the OpenGL 2.0 render path

I recognize three main performance drops with my system:

- fast zooming or flyby on a planet. This may be adressed by ppp (pixel processing power )

- loading time of big textures. I'm not sure if the harddisk or the AGB bus is the bottleneck here. Depends on the current state of the rendering system I think.

- switching on DSOs. This causes dozens of textures to be continously processed and results in a major drop of framerates. I'm sure this is an AGP related issue. I wonder if this could be countered by a tiling algorithm for DSOs.

maxim

[TERRIER]

- switching on DSOs. This causes dozens of textures to be continously processed and results in a major drop of framerates. I'm sure this is an AGP related issue. I wonder if this could be countered by a tiling algorithm for DSOs.

I'm wondering whether VT's for nebulae add-ons would be feasible, and would make much difference to improving the frame rate?
I notice that without any DSO add-ons, and just viewing the default DSO's, my framerates still take quite a dive. Especially when looking at the Milky Way from within our solar system.

[maxim]

Well, as I understand the structure of the program, celestia uses a single (2k?) texture for default DSOs. Every time celestia positions and draws a DSO the texture is sent via AGP to the graphiccard, scaled and drawn there. The most times these DSOs are far away and small, so a 128x128 or even 64x64 pixel image would suffice to be used as texture. So there is a big unneccessary data overhead. (Correct me if I'm wrong, Chris)

maxim