My Globular Cluster Package for Testing

[ANDREA]

And, being so close to both 1.6 and to the globular clusters release, would it be possible to add to .cel and .celx commands the ones regarding such objects, I mean
renderflags set/clear "globularclusters" and
labels set/clear "globularclusterss" ?
Vincent?

Andrea, I've modified renderflags, orbitflags and labels CEL commands so that CEL and CELX share
the same table of names for these commands. That means that all names added to CELX will be used by
CEL too. As an example, there will be no need to add 'globulars' to CEL since Fridger already added it to CELX.
If Chris is OK, I'll check in this change in a couple of hours, as well as the change that adds globulars and the
new grids to the Windows View Option dialog.

Thanks a lot, Vincent, I'll add these commands to the .cel Wiki manual I'm writing just now.
BTW, I fear that your LUA EDU TOOLS don't work in Fridger's new r4446, but may be I made some installation mistake with them.
Could you please kindly chcek if the problem is mine?
Thanks a lot.
Bye

Andrea

[danielj]

Very interesting,but I will wait to test until it is available to the normal Celestia.I read and think it?s too complicated to work in a SVN version that it isn?t present in Cartrite?s site.But no hurry;I?m sure the globular rendering will be improved each time more...

[ANDREA]

Fridger, I get black globulars at high zoom value (see screenshot below)
Here's how you can try to reproduce the problem:
- Select M80 and zoom in until FOV reaches ~1'
- Increase distance with the mouse wheel
This only happens when the observer is in the neighbourhood of the Milky Way.
As an example, this doesn't happen when I move the observer out of the Milky
Way and try the above procedure with Pal5 instead of M80. It seems that the
problem is due to the superposition of galaxies and globulars sprites...

Yes, I confirm, it happens only when the Milky Way is in the background.
Bye

Andrea

[t00fri]

Very interesting,but I will wait to test until it is available to the normal Celestia.I read and think it?s too complicated to work in a SVN version that it isn?t present in Cartrite?s site.But no hurry;I?m sure the globular rendering will be improved each time more...

Daniel,

Cartrite has built already a version SVN-4449 with my new globular code. Just go and download it.

Fridger

[Cham]

Fridger,

I'll try your suggestion next. But here's a quick reproduction of the dark blurry disk I was talking about (I rised the luminosity and contrast of the picture to reveal clearly the dark disk effect) :

dark-disk.jpg

[Vincent]

Fridger,

I get black globulars at high zoom value (see screenshot below)
Here's how you can try to reproduce the problem:
- Select M80 and zoom in until FOV reaches ~1'
- Increase distance with the mouse wheel

This only happens when the observer is in the neighbourhood of the Milky Way.
As an example, this doesn't happen when I move the observer out of the Milky
Way and try the above procedure with Pal5 instead of M80. It seems that the
problem is due to the superposition of galaxies and globulars sprites...

[t00fri]

Fridger,

I get black globulars at high zoom value (see screenshot below)
Here's how you can try to reproduce the problem:
- Select M80 and zoom in until FOV reaches ~1'
- Increase distance with the mouse wheel

This only happens when the observer is in the neighbourhood of the Milky Way.
As an example, this doesn't happen when I move the observer out of the Milky
Way and try the above procedure with Pal5 instead of M80. It seems that the
problem is due to the superposition of galaxies and globulars sprites...

Yes that's right, but here we need Chris L's OGL expertise. Apparently something gets wrong with the glBlendFunc() when there are superimposed galaxies in addition.

But anyway, I am used to plenty of analogous effects since a long time which also showed there is a rendering bug of some kind. Hence this calls for a /general/ solution beyond the new code.

@Andrea: this also applies to the phenomena you spotted earlier.

Fridger

[Cham]

since the recompiling only takes < 1 minute, it would really be of diagnostic value if you did comment out

if (wgt < 0.95f)

I tried this. I don't see any differences yet. What is this supposed to do ?

[t00fri]

since the recompiling only takes < 1 minute, it would really be of diagnostic value if you did comment out

if (wgt < 0.95f)

I tried this. I don't see any differences yet. What is this supposed to do ?

Get possibly rid of that dark disk. It's a culling statement which might unexpectedly act somewhat different if the monitor resolutions differ.

Anyway, ChrisL has a MAC and he can surely analyze that effect most concisely. I cannot see anything of that sort on my machines and operating systems.

Fridger

[chris]

since the recompiling only takes < 1 minute, it would really be of diagnostic value if you did comment out

if (wgt < 0.95f)

I tried this. I don't see any differences yet. What is this supposed to do ?

Get possibly rid of that dark disk. It's a culling statement which might unexpectedly act somewhat different if the monitor resolutions differ.

Anyway, ChrisL has a MAC and he can surely analyze that effect most concisely. I cannot see anything of that sort on my machines and operating systems.

Fridger

I can get this effect on my Windows machine too. It's a result of the blend mode. Additive blending would solve the problem, but I thought that you perhaps chose a different blend mode to avoid getting overbright clusters. I'll take a look at the code shortly.

--Chris

[selden]

I defined a "real" Star near the center of 47 Tuc. After going to it, it's fun to make all those cluster stars swirl around (by rotating around the Star) with no reduction of framerate.

Code: Select all

Star "T47"
{
        RA                 6.021 # degrees = 0.4014  # [hours]
        Dec              -72.0808  # [degrees]
        Distance        1.4681e+04  # [ly]

   SpectralType "G2V"
   AbsMag 4.93
}

[t00fri]

I can get this effect on my Windows machine too. It's a result of the blend mode. Additive blending would solve the problem, but I thought that you perhaps chose a different blend mode to avoid getting overbright clusters. I'll take a look at the code shortly.

--Chris

Aha? But if you can have a look at the OGL stuff it's certainly the most effective action, given my rather basic OGL knowledge.

Fridger

[cartrite]

Concerning the KDE version and the Shift + u and Shift + e, I revised kdeapp.cpp and kdeapp.h and was able to get them working. I am including the files in a zip file attached here.

kdeapp.zip

Never posted a zip file here so I hope it works.
cartrite

[t00fri]

Concerning the KDE version and the Shift + u and Shift + e, I revised kdeapp.cpp and kdeapp.h and was able to get them working. I am including the files in a zip file attached here.

kdeapp.zip

Never posted a zip file here so I hope it works.
cartrite

Thanks, Steve.

so far the patch looks good to me. If there are no further complaints, do you want me to commit it?

Fridger

[cartrite]

I haven't seen any negative side affects. The options or labels guis are not affected. If you want you can commit it but given this is the first time I did such a thing, maybe we should wait till others can confirm that this does not cause any conflicts? I leave it up to you.
cartrite

[t00fri]

I haven't seen any negative side affects. The options or labels guis are not affected. If you want you can commit it but given this is the first time I did such a thing, maybe we should wait till others can confirm that this does not cause any conflicts? I leave it up to you.
cartrite

Indeed I was meaning to wait a bit of course.

Fridger

[t00fri]

I defined a "real" Star near the center of 47 Tuc. After going to it, it's fun to make all those cluster stars swirl around (by rotating around the Star) with no reduction of framerate.

Code: Select all

Star "T47"
{
        RA                 6.021 # degrees = 0.4014  # [hours]
        Dec              -72.0808  # [degrees]
        Distance        1.4681e+04  # [ly]

   SpectralType "G2V"
   AbsMag 4.93
}

Cute!

Fridger

[chris]

Here's a patch that addresses the black stars and core in globulars.

glob-patch.zip

I changed just two lines in globular.cpp. First the blending of the sprite:

Code: Select all

@@ -387,7 +387,7 @@
    if (br > 1.0f)
       br = 1.0f;
 
-   glColor4f(Rr * br, Gg * br, Bb * br, A);   
+    glColor4f(Rr, Gg, Bb, A * br);
       
    glBegin(GL_QUADS);      


The alpha factor is multiplied by the brightness instead of the color components. Since source blend mode is GL_SRC_ALPHA, the color components will be multiplied by the alpha factor during rasterization. Thus, my patch results in no change to the color of the stars. Multiplying alpha by br means that a dark cloud sprite will also tend to be nearly transparent.

The change for stars is quite similar:

Code: Select all

       
@@ -462,7 +462,7 @@
       
          Color col  = (r_3d < 2 * r_c && pow2 < 256)? colorTable[255]: colorTable[iR];      
       
-         glColor4f(col.red() * br, col.green() * br, col.blue() * br, 1.0f - wgt);
+         glColor4f(col.red(), col.green(), col.blue(), (1.0f - wgt) * br);
                   
          Point3f relPos = p + offset;


I think that this is OK. Certainly it fixes the dark stars problem, but I look at the code some more to better understand the role of the (1 - wgt) term.

I will also have a look at the possibility of using additive blending.

--Chris

[ElChristou]

Christophe, Cham

since the recompiling only takes < 1 minute, it would really be of diagnostic value if you did comment out

if (wgt < 0.95f)

in line 452 of globular.cpp and quickly recompile.

It's better but I'm still able to see a smallest black hole. Now, when I go away from a cluster, the center disappear before all. Is this normal?

[t00fri]

Here's a patch that addresses the black stars and core in globulars.

glob-patch.zip

I changed just two lines in globular.cpp. First the blending of the sprite:

Code: Select all

@@ -387,7 +387,7 @@
    if (br > 1.0f)
       br = 1.0f;
 
-   glColor4f(Rr * br, Gg * br, Bb * br, A);   
+    glColor4f(Rr, Gg, Bb, A * br);
       
    glBegin(GL_QUADS);      


The alpha factor is multiplied by the brightness instead of the color components. Since source blend mode is GL_SRC_ALPHA, the color components will be multiplied by the alpha factor during rasterization. Thus, my patch results in no change to the color of the stars. Multiplying alpha by br means that a dark cloud sprite will also tend to be nearly transparent.

The change for stars is quite similar:

Code: Select all

       
@@ -462,7 +462,7 @@
       
          Color col  = (r_3d < 2 * r_c && pow2 < 256)? colorTable[255]: colorTable[iR];      
       
-         glColor4f(col.red() * br, col.green() * br, col.blue() * br, 1.0f - wgt);
+         glColor4f(col.red(), col.green(), col.blue(), (1.0f - wgt) * br);
                   
          Point3f relPos = p + offset;


I think that this is OK. Certainly it fixes the dark stars problem, but I look at the code some more to better understand the role of the (1 - wgt) term.

I will also have a look at the possibility of using additive blending.

--Chris

Chris,

that sounds almost too simple to me?

Your patch does not affect the RGB colors. No doubt about that

BUT....

The way I constructed things in alpha was as follows:
--------------------------------------------------------------------

The procedural "cloud" texture is RGBA, with A containing as a weight ONLY the
rho-dependent part

relStarDensity(rho) ; rho = r_2d / r_c

of the overall alpha blending weight.

The resolution dependent (pixelWeight), but rho-independent part is subsequently implemented into the cloud texture via

glColor4f(Rr * br, Gg * br, Bb * br, A);

where A = 3.0f * pixelWeight

Hence altogether we have the overall alpha-weight for the cloud texture:

A * relStarDensity(rho)

For the star sprite textures, the overall blending weight should be

1 - A * relStarDensity(r_2d / r_c))

in order to maintain the underlying King profile, independently of the blending transition. That's what it is in my code!

It seems to me that your simple proposal breaks that basic relation once you multiply with the factor br. At least that's why I didn't do that!

Fridger