Celestia Forums

OK, I downloaded 1.4.0pre1, and used the following code that Selden posted on another thread to make the Alpha Centauri system - I saved this as an STC file:




Then, I created a planet in an SSC file to orbit the Alf Cen A, like so:



When I fire this up, I don't see multiple illumination. In fact, I only see multiple illumination occurring when B is closer than 21.7 AU from the planet - it cuts out very suddenly.

To see this, go to this CEL URL:
cel://PhaseLock/Rigel%20Kentaurus%20A:Prometheus/Rigel%20Kentaurus%20B/2366-02-26T19:54:24.16683?x=AI5ZmJkqPKaB7+b//////w&y=oEJZ4FCPrA8sndL//////w&z=qtRYzZxDdzTDiCo&ow=-0.367940&ox=-0.121596&oy=0.674201&oz=-0.628719&select=Rigel%20Kentaurus%20B&fov=20.765589&ts=1.000000<d=0&rf=38711&lm=71

Then fastforward time by a factor of about a million or so and watch what happens. In this view, you're looking at the hemisphere of the planet illuminated by Alf Cen B. As soon as the distance to B is larger than about 21.7 AU, the illumination suddenly disappears, and the planet is only illuminated by A. When it gets closer than that distance, the illumination from B returns.

Now, I know that Chris wanted to make illumination from more distant stars less visible than illumination from the primary, but that seems a little extreme . (I'd have though illumination from stars beyond 1000 AU might be less visible, but not 21.7 AU). So I'm wondering if this is a bug.

Two questions: is this the standard format, then, for creating a multiple system? And, does this "over ride" the Alpha Centauri that is already there?

...John...

Evil Dr Ganymede wrote:OK, I downloaded 1.4.0pre1, and used the following code that Selden posted on another thread to make the Alpha Centauri system - I saved this as an STC file:

Code: Select all

Barycenter "AlfCen"
{
   RA 219.916998
   Dec -60.83748372
   Distance 4.395
}
71683 # ALF Cen A
{
   OrbitBarycenter "AlfCen"
   SpectralType "G2V"
   AppMag 0.01

   EllipticalOrbit {
      Period          79.914
      SemiMajorAxis   10.8928   # mass ratio 1.09:0.92
      Eccentricity    0.5179
      Inclination   82.98
      AscendingNode   67.71
      ArgOfPericenter 3.77
      MeanAnomaly     200.12
   }
}
71681 # ALF cen B
{
   OrbitBarycenter "AlfCen"
   SpectralType "K0V"
   AppMag 1.34

   EllipticalOrbit {
      Period          79.914
      SemiMajorAxis   12.7872   # mass ratio 1.09:0.92
      Eccentricity    0.5179
      Inclination   82.98
      AscendingNode   67.71
      ArgOfPericenter 183.77
      MeanAnomaly     200.12
   }
}


Dollan wrote:Two questions: is this the standard format, then, for creating a multiple system? And, does this "over ride" the Alpha Centauri that is already there?

1) Selden will know better than me.
2) It appears to override the existing system, yes.

Though it seems that you can't see the Stars orbits yet. And they don't appear to have labels that can be made visible either.

Overriding previous systems is good. Nothing scares me more than having to go into the stars dat file and figure things out!

Oh, I did have another question; in the stc file you have posted, the A and B components show two differnet semi-major axis amounts. should they be the same?

...John...

h? voila !!

cel://Follow/Rigel%20Kentaurus%20A:Prometheus/2004-10-27T05:37:00.79320?x=92zYp8hAWb9e7+b//////w&y=1uDjdy6pv6FMnNL//////w&z=mbr4HyZbGN9giSo&ow=-0.088575&ox=-0.154765&oy=0.983524&oz=0.029729&select=Rigel%20Kentaurus%20A&fov=19.737228&ts=1.000000<d=0&rf=104195&lm=71

I can adjust the logarithmic light intensity adjustment, but really, I don't think that you should see Alpha Centauri B noticably illuminating the planet, even when the star is closest. You've placed the planet just 0.4 au from A, which is substantially brighter than B. I never see the apparent brightnesses of the stars get closer than 10 magnitudes, or a factor of 10,000. That's probably at the edge of human perception. If you really want to see both suns lighting the planet, I'd recommend putting it in orbit around B and making the semimajor axis larger. Or, put a planet in a 20au orbit around Proxima. A quick check showed that the difference in the apparent brightness of Proxima and Alpha Centauri A was just 3 magnitudes.

The sudden cutoff of the second light is a bug. I've done all of my testing lately with the OpenGL 2.0 path and completely neglected to scale the brightness of the stars in the other paths. I'll have a fixed version ready very soon.

--Chris

chris wrote:I can adjust the logarithmic light intensity adjustment, but really, I don't think that you should see Alpha Centauri B noticably illuminating the planet, even when the star is closest. You've placed the planet just 0.4 au from A, which is substantially brighter than B. I never see the apparent brightnesses of the stars get closer than 10 magnitudes, or a factor of 10,000. That's probably at the edge of human perception. If you really want to see both suns lighting the planet, I'd recommend putting it in orbit around B and making the semimajor axis larger. Or, put a planet in a 20au orbit around Proxima. A quick check showed that the difference in the apparent brightness of Proxima and Alpha Centauri A was just 3 magnitudes.

The sudden cutoff of the second light is a bug. I've done all of my testing lately with the OpenGL 2.0 path and completely neglected to scale the brightness of the stars in the other paths. I'll have a fixed version ready very soon.

--Chris

Chris

chris wrote:The sudden cutoff of the second light is a bug. I've done all of my testing lately with the OpenGL 2.0 path and completely neglected to scale the brightness of the stars in the other paths. I'll have a fixed version ready very soon.

--Chris

That sudden cutoff is what I was thinking was the bug... I understand about the rest though

You want something really weird, put the planet in orbit around the barycentre. Then you get a permanent ring of shadow going round the planet, and everywhere else is illuminated because both stars are always on opposite sides relative to eachother!

I'll try the pre2 version. Guess I'd better find me an OGL 2.0 compatible card...

Chris - nope, pre2 didn't fix it.

Now I'm seeing a kinda dark looking planet with fully visible clouds when B is distant. And then that illumination cuts out suddenly at 21.7 AU.

This is on OpenGL/NVIDIA render path BTW - the video card is an 128 MB Asus Geforce FX 4200Ti, on Windows 2000 SP4.

Use the cel link I posted earlier to see this...

OK, I'm trying Pre4 now and I've lost the cloud illumination from B completely - nothing switches on or off when B is between 11 and 35 AU. Even when it's at 11 AU I still can't see any illumination at all on the surface from B.

Use this URL now, it's better. B is 11 AU away directly behind the camera here, so we should see some illumination from it on the dark half of the planet. But we don't.

cel://PhaseLock/Rigel%20Kentaurus%20A:Prometheus/Rigel%20Kentaurus%20B/2355-03-18T16:59:32.72130?x=ICFV3YsldN/F7+b//////w&y=/JXOKDVSoWannNL//////w&z=wIrbyNtbBdM6iCo&ow=-0.981026&ox=0.055384&oy=-0.166949&oz=-0.081540&select=Rigel%20Kentaurus%20B&fov=6.760695&ts=1.000000<d=0&rf=38711&lm=71

I'm still not remotely convinced that it's accurate to see no illumination here. If earthshine from a full Earth (magnitude -17) can be seen with the naked eye on the darkside of a crescent moon in the sky, then we should darn well be able to see direct illumination on the dark side of a planet from a star that is at magnitude -20.

Unless it's my card/drivers that are the problem...

Oh, Evil One,

After upgrading the drivers, I also still could see no illumination from B.

*However*, reexamining the STC and SSC files, I found a typo in my STC file: it was missing a trailing } after the definition for Alf Cen B.

As a result Alf Cen B wasn't being redefined: Celestia was still using the predefined version of the star, not the new version that's part of the same star system with the redefined Alf Cen A.

I inserted the trailing } and restarted Celestia. Now both sides of the planet are illuminated.

System:
512MB 2.4GHz P4, WinXP Pro SP2
128MB FX5200, ForceWare v66.81 (beta)
Celestia v1.4.0pre4

Evil Dr Ganymede wrote:I'm still not remotely convinced that it's accurate to see no illumination here. If earthshine from a full Earth (magnitude -17) can be seen with the naked eye on the darkside of a crescent moon in the sky, then we should darn well be able to see direct illumination on the dark side of a planet from a star that is at magnitude -20.

I'm not completely convinced either way yet. But remember, it's the relative brightness that matters--although the secondary star is magnitude -20, the primary is significantly brighter than the Sun appears from Earth.

I'm still investigating the right way to handle brightness adjustments. I've already abandoned the naive approach where the apparent brightnesses of light sources are normalized with linear scaling. Linear scaling would mean that you'd see no visible effect from any light source less with than 1/255 (for an 8-bit per channel frame buffer) the intensity of the brightest. The human eye has a roughly logarithmic response, but I've deliberately chosen not use a logarithmic adjustment for brightnesses. The problem is that the logarithmic adjustment sort of conflicts with assumptions of linear brightness further down the rendering pipeline. It's still not quite correct, but I've opted for now to adjust the brightness with a gamma (power) function, with the exponent chosen so that a light source 1/10000th the intensity of the brightest will be just barely visible when rendering to an 8-bit per channel framebuffer. That is, gamma is chosen so that (1/10000)^gamma = (1/255). But, all monitors are different, and a single bit difference between pixel values may not be perceptible--very dark colors may all appear black. I could change the the value of gamma, but I don't want to just arbitrarily try different values without some further research. I have considered Earthshine; in fact, that's where the value 1/10000th comes from.

Of course, the right way to handle this is to use high-dynamic range rendering and floating point framebuffers. No tricks are required, and light intensity is treated as linear throughout rendering. Once rendering is completed, a final exposure post-processing step converts the pixel values to 'human perceptual space' with a log function before the scene is displayed on screen. I'll get to this eventually, but you'd better have powerful hardware. It's a technique that's only practical on GeForce 6600 and 6800 cards; even the most recent ATI hardware doesn't fully support floating point framebuffers.

--Chris

Well, I wouldn't mind that myself, since I'm getting a 6600

So using a floating point system is basically like rendering the system as it really is and letting our own eyes decide what we can see instead of having the program determine that for us?

I'm not completely convinced either way yet. But remember, it's the relative brightness that matters--although the secondary star is magnitude -20, the primary is significantly brighter than the Sun appears from Earth.

Yes, but the primary's brightness doesn't matter when figuring out how the companion illuminates the surface, does it?

I'm wondering if you could throw in a phase angle dependency here. Like I said elsewhere, we can see earthshine on the dark side of the moon when a crescent moon is lit by the sun. So could you set things up so that the illumination from B appears dimmest when the phase of the planet lit by A is nearly full, but it increases as the phase lit by A goes toward crescent and new?

EDIT: Oh yeah, Selden - I think my STC has the corrected {brackets} already.

Wouldn't it be an option to add these choices to the celestia preferences.
'linear', 'logarithmic' or 'gamma <value>' as parameter for the experienced user to specify on his own?

maxim