My Globular Cluster Package for Testing

[Cham]

Now, when I go away from a cluster, the center disappear before all. Is this normal?

This sounds like the effect that I described.

[t00fri]

Now, when I go away from a cluster, the center disappear before all. Is this normal?

This sounds like the effect that I described.

Never mind, we'll get rid of it, eventually. The main challenge here, is NOT to affect the underlying King luminosity profiles in the blending process, both in 2d and 3d. That's what makes this issue non-trivial...

Fridger

[danielj]

I installed and worked,but still there si two entries for each globular cluster.For example,I have Omega Centauri with the galaxy type rendering and nearby,the globular cluster with the new rendering.Is it possible to disable the old mesh or will mess up with the general galaxy rendering?

[t00fri]

I installed and worked,but still there si two entries for each globular cluster.For example,I have Omega Centauri with the galaxy type rendering and nearby,the globular cluster with the new rendering.Is it possible to disable the old mesh or will mess up with the general galaxy rendering?

It seems you still have Selden's globular cluster add-on lurking around in your installation (extras directory!?) ?

Clearly you cannot mix such things and still expect a consistent display!!

Fridger

[t00fri]

Chris,

I inspected your patch --independently of my theoretical doubts.

As to Vincent's black cluster stars, it's OK, but the correct blending between the central cloud sprite and star sprites is lacking now. We seem to be back at the old problem of a far too bright center...

In view of my above arguments, I understand WHY.

Fridger

[chris]

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!

The results appear to be visually indistinguishable except in high-zoom situations with non-black background.

m13-dark.jpg

m13-ok.jpg

I'll run through the calculations to see where the patched code might give completely wrong results.

--Chris

[t00fri]

The results appear to be visually indistinguishable except in high-zoom situations with non-black background.

m13-ok.jpg

--Chris

But the patch modifies the luminosity profile (I am sure) and the cluster in your above image is again too bright in the center! I checked it in Celestia.

Fridger

[t00fri]

Chris,

here is a demo about what I am arguing about:

For a better comparison, I inverted your original m13-dark.jpg above that is dark in front of a non-black background. This image I then compare to the result from your patch: m13-ok.jpg.

This comparison clearly shows that --apart from color inversion-- my original central behaviour is fine while your patched result modifies the central profile incorrectly: it's far too concentrated at center!

1) The correct, but inverted image : m13-dark.jpg

2) The incorrect patched central behaviour (m13-ok.jpg)


Fridger

[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)

I think that you might be misunderstanding what the alpha weight does in OpenGL. You've set up the OpenGL blend mode as follows:

glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

This means that the final pixel color will be:

As * (Rs, Gs, Bs) + (1 - As) * (Rd, Gd, Bd)

Cs = (Rs, Gs, Bs) is the source color: the r, g, b values given in glColor4f multiplied by the texture color. Cd = (Rd, Gd, Bd) is the destination color--whatever happens to already be in the frame buffer. When writing to black framebuffer (Rd, Gd, Bd) will be zero, and thus the final color is simply:

As * (Rs, Gs, Bs)

You can see that in this case, the original color/alpha:

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

is exactly equivalent to the patched on:

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

When there's something else in the background (e.g. a galaxy), there is a difference between the two, and the screen shots in the previous post show that multiplying the alpha by br is clearly the right approach. Most importantly, it won't have any effect on the King profile.

The situation is more complicated for the stars. Since they're rendered after the cloud sprite, their alpha values definitely will affect the overall brightness.

Once again, we have the blending equation:

As * (Rs, Gs, Bs) + (1 - As) * (Rd, Gd, Bd)

In the original code, Cs = br * (Rr, Gg, Bb) and As = 1-w. The final color is:

(1-w) * br * Cs + w * Cd

In the patched code, Cs = (Rr, Gg, Bb) and As = (1-w)*br. The final color is:

(1-w) * br * Cs + (1 - (1 - w) * br) * Cd

The source term is the same, but the destination blend factor is different, and that's probably not what we want. What we should do is use the first part of the patch, since that gives identical result to the original except the blending with the background will be improved. The second part of the patch is not correct (though I have yet observe differences visually) and requires a different approach.

--Chris

[t00fri]

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)

I think that you might be misunderstanding what the alpha weight does in OpenGL. You've set up the OpenGL blend mode as follows:

glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

This means that the final pixel color will be:

As * (Rs, Gs, Bs) + (1 - As) * (Rd, Gd, Bd)

Cs = (Rs, Gs, Bs) is the source color: the r, g, b values given in glColor4f multiplied by the texture color. Cd = (Rd, Gd, Bd) is the destination color--whatever happens to already be in the frame buffer. When writing to black framebuffer (Rd, Gd, Bd) will be zero, and thus the final color is simply:

As * (Rs, Gs, Bs)

You can see that in this case, the original color/alpha:

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

is exactly equivalent to the patched on:

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

When there's something else in the background (e.g. a galaxy), there is a difference between the two, and the screen shots in the previous post show that multiplying the alpha by br is clearly the right approach. Most importantly, it won't have any effect on the King profile.

The situation is more complicated for the stars. Since they're rendered after the cloud sprite, their alpha values definitely will affect the overall brightness.

Once again, we have the blending equation:

As * (Rs, Gs, Bs) + (1 - As) * (Rd, Gd, Bd)

In the original code, Cs = br * (Rr, Gg, Bb) and As = 1-w. The final color is:

(1-w) * br * Cs + w * Cd

In the patched code, Cs = (Rr, Gg, Bb) and As = (1-w)*br. The final color is:

(1-w) * br * Cs + (1 - (1 - w) * br) * Cd

The source term is the same, but the destination blend factor is different, and that's probably not what we want. What we should do is use the first part of the patch, since that gives identical result to the original except the blending with the background will be improved. The second part of the patch is not correct (though I have yet observe differences visually) and requires a different approach.

--Chris

Chris,

thanks for reviewing this, but I think I was aware of the basic relations.

Part 1 of the patch I never doubted. It was part 2 for the star sprites I didn't like. And that's precisely what you seem to be confirming?

Fridger

[ANDREA]

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.
@Andrea: this also applies to the phenomena you spotted earlier.
Fridger

Thank you, Fridger.
Bye

Andrea

[t00fri]

Chris,

here is actually the VERY simplest patch that gives perfect imaging and remains consistent with Mr. King . There is just ONE little catch (cf below)...

Simply set br=1.0f

This leads to perfect globular shapes and colors over a bright MilkyWay background



while not destroying the normal globular rendering, e.g.



BUT...

we do need that factor br to steer the daylight fading and also the appmag dependences etc.

So where to put it? That's what kept me thinking for a while already. Originally, I chose to use it as a common factor for the colors. But we know meanwhile that this gives black clusters over bright backgrounds, while the globular blending is fine.

So all we need is another place to stick br in, EXCEPT the alpha slots
Can't we do a glColor4f (1.0f, 1.0f, 1.0f, br) somewhere AFTER the blending of the cloud and star textures took place already?

Any ideas?

Fridger

[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.

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?

Andrea,

I think that it would me more appropriate to discuss about this issue in Lua Edu Tools thread...

[ANDREA]

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.

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?

Andrea,
I think that it would me more appropriate to discuss about this issue in Lua Edu Tools thread...

OK, moving it.
Bye

Andrea

[ajtribick]

(KDE, built from SVN 4450)

One problem I've come across is that the decision on whether to draw the cluster or not results in the outer parts of the cluster suddenly disappearing from view when the core moves off the screen, e.g. in the attached image, which consists of two shots taken with a very slight difference in camera angle, from the same position in space.

[Cham]

Ah, yes, this is a problem. Thanks ajtribick.

The cluster shouldn't suddenly disappear from the screen. This also happens with some other stuff...

[ajtribick]

A problem that may be related to this is something I noticed when flying through the core of NGC 6401 at 20 ly/s: some of the sprites disappear before they reach the edge of the screen, again it looks odd.

A few further points: the quoted core radius is apparently in units of minutes of arc, which presumably should change when the observer moves around - is the Radius parameter (with units of light years) also the core radius? Similarly stars display both apparent and absolute magnitudes.

For consistency it might be better to order the properties similarly to the star ones, e.g.

ID1 / ID2 / ...
Globular cluster
Distance: ###
Abs (app) mag: ###
King concentration: ###
Apparent diameter (core): ###
Radius (core): ###

(Might also be worth doing something similar for the galaxies, e.g.)

ID1 / ID2 / ...
Galaxy
Distance: ###
Abs (app) mag: ###
Hubble type: ###
Apparent diameter: ###
Radius: ###

[t00fri]

(KDE, built from SVN 4450)

One problem I've come across is that the decision on whether to draw the cluster or not results in the outer parts of the cluster suddenly disappearing from view when the core moves off the screen, e.g. in the attached image, which consists of two shots taken with a very slight difference in camera angle, from the same position in space.

Andrew,

this and related phenomana I have listed in the Dev list in my SVN checkin
report. This list is meant for Celestia devs

-- since the spacial extension of a globular cluster typically involves stars
BEYOND it's nominal mu25 isophote radius, these stars suddenly cease to be
rendered, if the globular's center is moved sufficiently OUTSIDE the canvas.

That (minor) problem obviously needs a more general consideration about objects involving a certain "fuzziness" beyond their nominal "radius".


Fridger

[ajtribick]

Ah, oops. I thought I'd seen it mentioned somewhere before now.

[t00fri]

A problem that may be related to this is something I noticed when flying through the core of NGC 6401 at 20 ly/s: some of the sprites disappear before they reach the edge of the screen, again it looks odd.

related....

A few further points: the quoted core radius is apparently in units of minutes of arc, which presumably should change when the observer moves around

My God NO. The core radius is a morphological constant (cf below) whose dimensions are conveniently taken to be arcmins.

- is the Radius parameter (with units of light years) also the core radius? Similarly stars display both apparent and absolute magnitudes.

Globular clusters are characterized by several radius parameters. A sensible definition of the "physical" radius is the mu25 isophote radius, which is listed under Radius in the output. Since it's the "physical" radius, it's given in physical dimensions. mu25 isophote radii are used also in many other contexts in astronomy.

Then there are two morphological constants, the 'core radius r_c' and the 'tidal radius r_t' that characterize globulars. These are ALWAYS given in arcmins in ALL catalogs, and I will NOT change established conventions! The core radius typically characterizes the angular size (as seen from Earth) of the globular core region, while r_t defines the distance beyond which NO stars can belong to (be gravitationally bound by) the globular. It has become convenient to introduce instead the dimensionless King concentration parameter

c = =log10(r_t /r_c)

Hence the cluster morphology is characterized by two parameters, r_c and c, which are given in the catalogs. These belong into the second line of output (top left), reserved for the DSO morphology.

All these standard concepts are explained in my well commented code or in King's original papers.

Another popular radius is the half-light or also the half-mass radius with obvious meaning.

There are good reasons for arranging the output in my way:

-- code: this has to do with the DSO class inheritance structure.

DeepSkyObject --> Galaxy, Globular, ....

Of course everything can be coded, but it so happens that the first line after the acronyms is forseen for morphological properties of the DSO:

-- galaxies: Hubble characterization
--globulars: King concentration and core radius

Stars don't have much of a morphology mostly

Fridger