stars.txt

[hank]

Sorry Fridger, I didn't mean to get you started in on Chris again. I understand your unhappiness about the situation, but I hope you'll be able to work things out with Chris eventually. In the meantime, it sounds like you and Cham are making progress, so that's good news.

- Hank

[Cham]

Chris once told that he wanted to change the ring code, to add some reflectivity (?) and other realistic effects to the rings.

So, what's next?

Asteroid/comet labels transparency effect, dependant on distance and size(*) ?


O well, this is OFF topic anyway...



(*) actually albedo*aera = albedo*size^2, if albedo is defined.

[t00fri]

Meanwhile also the faint, outest ringlet is visible (hi Christophe!)



Bye Fridger

[ElChristou]

Tx for the nice work guys!

Anyway, 2 comments (not really related):

- With markers ON, selecting a barycenter won't show the marker,

- The barycenter labels appear too late (at a too close distance); it would be nice to have the label visible when the whole system cover the screen...

[Cham]

1- With markers ON, selecting a barycenter won't show the marker,

2- The barycenter labels appear too late (at a too close distance); it would be nice to have the label visible when the whole system cover the screen...

About 1, I don't see any problem. My markers are ON, and I can see the red diamond around the selected barycenter.

About 2, yes, I confirm, but I don't see this as a "problem".

Can you give more details about point 1 ?

[t00fri]

Chris,

that's serious down there in Paraguay

With markers on, I definitely see the red diamond at the barycenter! Checked many times today.

Are you really claiming that after CTRL+K and typing

HIP 2237 AB
G
you don't see the red diamond??

Bye Fridger

[t00fri]

Christophe,

I also confirm that the barycenter label comes a bit late in case of HIP 2237. But if we want to assert dynamically for ALL monitor resolutions and ALL possible binary separations that the barycenter label appears BEFORE one of the two components is outside of the screen, this is a bit of a chore...

Cheers,
Fridger

[ElChristou]

Ok, I'm a fool!

I won't have any red marker if the barycenters are already marked by Cham's script!

Now, this open a new topic; I think the marker for the selected object should be dependent from scripted markers... Opinion?

Now I get a strange and annoying behavior; if I'm in full screen and if I press "enter", all is fine, I can type for a barycenter, etc... Now I get a hard crash (very rare on osX) if I press "enter" in windowed mode... Someone can confirm?

Here is the begining of the crash log:

Code: Select all

Date/Time:      2007-10-20 18:34:30.992 -0400
OS Version:     10.4.10 (Build 8R218)
Report Version: 4

Command: Celestia
Path:    /Volumes/Celestia/Celestia/CelestiaW.app/Contents/MacOS/Celestia
Parent:  WindowServer [56]

Version: 1.5.0 (Prerelease)

PID:    1326
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xbe000003

Thread 0 Crashed:
0   libobjc.A.dylib          0x90a40100 objc_msgSend + 32
1   net.shatters.Celestia    0x001104cc MacInputWatcher::notifyChange(CelestiaCore*, int) + 68
2   net.shatters.Celestia    0x0000afd4 CelestiaCore::notifyWatchers(int) + 80
3   net.shatters.Celestia    0x00011b90 CelestiaCore::charEntered(char const*, int) + 2136
4   net.shatters.Celestia    0x00013de8 CelestiaCore::charEntered(char, int) + 32
5   net.shatters.Celestia    0x0004cb18 -[CelestiaOpenGLView keyDown:] + 404
6   com.apple.AppKit         0x937fafa0 -[NSWindow sendEvent:] + 6424
7   com.apple.AppKit         0x937a38d4 -[NSApplication sendEvent:] + 4172
8   net.shatters.Celestia    0x0004c1d4 -[CelestiaApplication sendEvent:] + 140
9   com.apple.AppKit         0x9379ad10 -[NSApplication run] + 508
10  com.apple.AppKit         0x9388b87c NSApplicationMain + 452
11  net.shatters.Celestia    0x00003290 _start + 760
12  net.shatters.Celestia    0x00002f94 start + 48

Thread 1:
0   libSystem.B.dylib        0x9000b348 mach_msg_trap + 8
1   libSystem.B.dylib        0x9000b29c mach_msg + 60
2   com.apple.opengl         0x936f6d60 glcDebugListener + 252
3   libSystem.B.dylib        0x9002bd08 _pthread_body + 96

Thread 0 crashed with PPC Thread State 64:
  srr0: 0x0000000090a40100 srr1: 0x000000000200f030                        vrsave: 0x0000000000000000
    cr: 0x44000244          xer: 0x0000000020000004   lr: 0x00000000001104cc  ctr: 0x0000000090a400e0
    r0: 0x00000000001104b8   r1: 0x00000000bfffea30   r2: 0x00000000be000003   r3: 0x000000000882fc80
    r4: 0x0000000090aab8bc   r5: 0x00000000000c0fe0   r6: 0x0000000000000000   r7: 0x0000000000000000
    r8: 0x0000000000000000   r9: 0x000000000015f040  r10: 0x00000000005ca840  r11: 0x000000006f54b8bc
   r12: 0x000000000882ca4b  r13: 0x0000000000000000  r14: 0x0000000000000000  r15: 0x0000000000000000
   r16: 0x0000000000000000  r17: 0x0000000000000000  r18: 0x0000000000000000  r19: 0x0000000000000000
   r20: 0x0000000000000000  r21: 0x0000000000000000  r22: 0x0000000000000000  r23: 0x0000000000000000
   r24: 0x0000000000000000  r25: 0x00000000005a6060  r26: 0x0000000008826860  r27: 0x00000000bfffefa8
   r28: 0x0000000000000080  r29: 0x00000000bfffeabc  r30: 0x000000000882fc80  r31: 0x000000000019ee60

[ElChristou]

Christophe,

I also confirm that the barycenter label comes a bit late in case of HIP 2237. But if we want to assert dynamically for ALL monitor resolutions and ALL possible binary separations that the barycenter label appears BEFORE one of the two components is outside of the screen, this is a bit of a chore...

I can imagine...

Now HIP 2237 is really not the only case where the barycenter label comes late. I've done again a few random click and go, and in almost ALL the cases, one must zoom on the barycenter to see the label... I find this a bit annoying... (I mean don't make much sense...)

[Cham]

OUCH !

I confirm the crash !

Happens in windowed mode only.

Dirkpitt ?

Now HIP 2237 is really not the only case where the barycenter label comes late. I've done again a few random click and go, and in almost ALL the cases, one must zoom on the barycenter to see the label... I find this a bit annoying... (I mean don't make much sense...)

Yes, but don't forget that a barycenter isn't a star. It's just a place, so it doesn't make sense to have a label of the same style as a star. Personaly, I don't think there's a problem with that label behavior. That's why I'm using a script to see the barycenter, if I need to.

[ElChristou]

Meanwhile also the faint, outest ringlet is visible (hi Christophe!)

Nice!

[ElChristou]

OUCH !

I confirm the crash !

Happens in windowed mode only.

Dirkpitt ?

Happy to see I'm not alone, lost between those binaries...

[ElChristou]

Yes, but don't forget that a barycenter isn't a star. It's just a place, so it doesn't make sense to have a label of the same style as a star. Personaly, I don't think there's a problem with that label behavior. That's why I'm using a script to see the barycenter, if I need to.

True it's why I was thinking in he possible use of the locations color for barycenters...

[Cham]

True it's why I was thinking in he possible use of the locations color for barycenters...

It would be too flashy, on a black background.

I think it's a good compromise to have barycenter labels associated to the star labels (at least for the moment). So personaly, I don't care much about the barycenter labels fading a bit too fast. Usually, I don't want to see them, and only the star labels. If I need to see the barycenter, I just mark it (using ctrl-P).

[t00fri]

...
Now HIP 2237 is really not the only case where the barycenter label comes late. I've done again a few random click and go, and in almost ALL the cases, one must zoom on the barycenter to see the label... I find this a bit annoying... (I mean don't make much sense...)

Actually, this observation of yours is coming together with another deficiency for which I have proposed a suitable remedy already years ago when I released the first versions of my binary orbit data:

The problem is that usually a GOTO (G key) to a binary system ends up with the two components NOT fitting onto the monitor view! This is very easy to fix for any resolution using the actual FOV etc. Chris L. had long announced to implement this feature, so I refrained so far from doing it myself.

Within the same fix one could also make sure that the barycenter label always appears first, while the (two) components are still on the screen.

Bye Fridger

[t00fri]

After these extensive tests, the latest and apparently perfect CVS candidate versions of my visualbin.stc, spectbin.stc data files and the corresponding PERL scripts visualbin.pl and spectbin.pl are here

http://www.celestiaproject.net/forum/viewtopic ... &start=171

--------------------------------------------
They incorporate Cham's successful proposal to add 'AB' to the barycenter name, "HIP xxxxx AB", of binaries with only a HIP number designation (i.e no proper name). Only this way the present code allows to GOTO and select the respective barycenters.
Such binaries now are characterized by the triplet:

HIP xxxxx AB (barycenter)
HIP xxxxx A (A component)
HIP xxxxx B (B component)

-------------------------------------------

If Chris L. agrees, I'll commit them to CVS.

Of course, another (better) possibility is to modify the code to make the 'AB' addition superfluous.

Bye Fridger

[Vincent]

And here's my modified script to mark all binaries. In blue : visual binaries (excluding Grant's binaries). In orange : the spectroscopic binaries, in green : other binaries (from Grant).

Hi,

As I did previously for galaxies, I'm thinking about a way to use a Celx script to mark all these binaries. Not only would it be far shorter, but that would also prevent Martin from doing the job manually each time there will be a small change in the database...

The following celx script marks all stellar barycenters:

Code: Select all

-- Title: Mark all stellar barycenters

function mark_spectraltype(x)
    for star in celestia:stars() do
        first, last = string.find(star:spectraltype(), x, 1, true)
        if first == 1 then
            star:mark("#ff99ff", "circle", 5)
        end
    end
end

spectral = "Bary"
celestia:flash("Marking all stellar barycenters.")
celestia:unmarkall()
celestia:setrenderflags{markers = true}
mark_spectraltype(spectral)

Then, having the possibility to distinguish spectroscopic binaries from visual binaries in celx would be great. But since neither the name nor other properties show the difference between spect and visual binaries, the only way to do that would be to add the possibility to celx to track the filename from which the stars were loaded in the database.

Hank, do you think such a feature could be easily added to celx scripting ?

[t00fri]

...
The following celx script marks all stellar barycenters:

Thanks, Vincent,

that's useful, indeed!

However, probably connected with my noted "barycenter anomaly" of binaries that only have a HIP number (and no proper name), some of your marked barycenter circles CANNOT be selected by means of clicking. Usually the A component is selected (not the barycenter) after clicking on your rose circles. It seems this is just a random affair, since the resolution is too low to distinguish between components A, B and the barycenter. Sometimes also the B component appears to be selected after clicking.

The same failure of selection by clicking on the marks, I also found now in Cham's .cel script in case of visual binaries (blue)

Again the barycenter labels come VERY late which is awkward.

Cheers,
Fridger

[Vincent]

However, probably connected with my noted "barycenter anomaly" of binaries that only have a HIP number (and no proper name), some of your marked barycenter circles CANNOT be selected by means of clicking. Usually the A component is selected (not the barycenter) after clicking on your rose circles. It seems this is just a random affair, since the resolution is too low to distinguish between components A, B and the barycenter. Sometimes also the B component appears to be selected after clicking.

Fridger,

I also think that the problem comes from the too low resolution. As an example, I was able to select HIP 60994 AB, which has no proper name, at a distance of ~ 0.05 ly.

I think that it would be a good thing to make starPicker systematically select the barycenter instead of one of the A/B components when the resolution is too low to make a distinction between the 3 objects...

[Vincent]

I think that it would be a good thing to make starPicker systematically select the barycenter instead of one of the A/B components when the resolution is too low to make a distinction between the 3 objects...

The following change in universe.cpp seems to fix the problem:

Code: Select all

Index: src/celengine/universe.cpp
===================================================================
RCS file: /cvsroot/celestia/celestia/src/celengine/universe.cpp,v
retrieving revision 1.53
diff -u -r1.53 universe.cpp
--- src/celengine/universe.cpp   7 Jan 2007 23:03:07 -0000   1.53
+++ src/celengine/universe.cpp   21 Oct 2007 12:23:33 -0000
@@ -567,6 +567,8 @@
     {
         sinAngle2Closest = sinAngle2 > ANGULAR_RES ? sinAngle2 : ANGULAR_RES;
         pickedStar = ☆
+        if (pickedStar->getOrbitBarycenter() != NULL)
+            pickedStar = pickedStar->getOrbitBarycenter();
     }
 }

With this change, the barycenter is systematically selected when the resolution is too low to make a distinction between the 3 objects (Barycenter, A component, B component). Of course, the A/B components can still be selected when the observer is located at a short distance from the system.