Celestia Forums

Hi all,

after quite some time, I have finished a substantial update of my globular cluster package. Unfortunately, for family reasons, I had very little spare time / leisure for coding during the past weeks since end of November...

Here is the new patch for you to test:

+++++++++++++++++++++++++++++++
http://www.celestiaproject.net/~t00fri/images/ ... _r4602.zip

The archive contains BOTH a standard patch file, as well as all the modified C++ code files for a simple replacement. All refers to the latest SVN, r4602
+++++++++++++++++++++++++++++++

Let me summarize next the various points, where I have implemented significant improvements:

• There are now strictly no cluster stars beyond the tidal radius!
  
  While before I did some "plumbing" with an approximate scaling law for the outer cluster stars, I now found an exact, highly efficient star generation algorithm, perfectly following the King luminosity distribution out to the tidal radius.
  
  This progress became possible by exploiting some crucial mathematical/statistical tricks. Let me briefly summarize:
  
  Von Neumann's "Acceptance-Rejection" method allows to sample random data (stars) following an arbitrary probability distribution, with the help of another (quickly generated) reference distribution, which majorizes the one in question everywhere. Initially, I used as a majorizing distribution p a uniform one (p ~ constant), which is very fast, but highly inefficient, given the strong central peaking of the desired King luminosity distribution! The uniform distribution was near at hand, since the random number methods in the code are always sampling uniformly (mathf::frand(),...)
  
  The perfect remedy was to employ a p ~ 1/Z^3 inverse power distribution, instead of a uniform one for majorizing. Due to the particular scaling dependence of the parameters/variables in King's distribution, a single, new variable Z could be found for the power distribution that majorizes the King distribution for ALL values of the King parameters/variables, r_c, c, r:
  
  [tex]Z = \sqrt {(1+r^2/r_c^2)/(1+r_t^2/r_c^2)}[/tex]
  
  The second trick was that the random sampling according to a 1/Z^3 distribution can be VERY quickly done by means of the well-known "Inverse-transform" method. It uses the fact that the cumulative distribution F(y) (expressing the probability that x < y),
  
  [tex]u = P(y) = \int_0^y p(x) dx[/tex]
  
  is itself a random variable u, which will occur with uniform probability density on [0, 1]. Here p(x) would be the desired 1/Z^3 distribution, with the stochastic variable x being distributed according to p(x)!
  
  In a few cases, including the 1/Z^3 distribution, this relation can be analytically inverted and thus the desired data x can be obtained from the /uniformly/ distributed ones as
  
  [tex]x = P^{-1} (u)[/tex]
  
  Hence, by sampling u with mathf::frand(), x is obtained immediately from a simple transformation formula in terms of u! This works beautifully and VERY fast.
  
  +++++++++++++++++++++++
  With this new method I could increase the efficiency of generating cluster stars following King's distribution out to r_tidal from a fraction of a percent to almost 100%!
  +++++++++++++++++++++++
  
  The approximate scaling trick by which I attempted initially to compensate for the low efficiency, has now become reluctant. The corresponding results were unfortunately quite inaccurate in certain cases.
  
  
• Here are some plots, illustrating the achieved progress:
  
  First, let us consider the 3d King luminosity profiles (solid colored lines) as function of the scaled distance [tex]\eta=r / r_t[/tex] for the relevant range of King concentration parameters c. The dashed lines are the majorizing 1/Z^3 distributions,
  
  
  
  You see that small c corresponds to a more shallow light distribution, while large c shows a heavy central bias!
  
  In terms of the above variable
  [tex]Z = \sqrt {(1+r^2/r_c^2)/(1+r_t^2/r_c^2)}[/tex]
  
  all these different curves collapse into a universal one, as you see in this plot:
  
  
  
  In the next plot, I generated 20000 stars with the new algorithm. You can see yourself, how well the corresponding histogram of the generated stars matches the theoretical King profile function (red line). The black line is the normalized, intermediate 1/Z^3 profile. The efficiency is now 82%, while it was only a fraction of a percent before!!!
  
  
  
  
• To avoid color inverted clusters in front of bright galactic clouds, the blending of the cloud sprite texture and the star sprite texture has been modified essentially as investigated by Chris . While this is perfect for the cloud sprite texture, it's only a compromise for the star sprite texture. But it seems for now, it's an improvement... At least there are NO black clusters anymore
  
• The sizes of the globular stars are now fixed numbers (unlike their proportionality to the cluster radius before). They are much smaller than before.
  
  +++++++++++++++++++++++++++
  At the same time I implemented a nice NEW option to travel right through the core of any globular cluster!!
  
  Here is how to do it:
  
  Enter the name of a globular into the command line (e.g. Omega Centauri, M 13, 47 Tuc, M 53, ...). Next type G (GoTo). Make sure that the field of view (FoV) corresponds to the default value 30-45 degrees (hit the middle mouse key to reset). The cluster should fill about 1/3 of the screen now. Next hit F7 and then use the 'A' and 'Z' keys for adjusting your travel speed. Don't go too fast (hit 'Z' to slow down, 'A to accelerate)! Once you passed through the center, you may hit ' * = SHIFT+8' and then you can look back, watching the cluster moving away from you...
  
  How do you like it???
  +++++++++++++++++++++++++++
  
• The new sizes of the globulars have been cross-checked in many ways!
  
  This is quite a non-trivial task, since the clusters don't have a sharp boundary. Here is an example of such a decisive test:
  
  I exploited that for King concentration c-> 0 the core radius r_c -> r_t, and the distribution of stars becomes very shallow, still vanishing exactly at the tidal radius r_t. Then I composed a test.dsc file with a fake "ring galaxy" of outer radius r_t and a corresponding globular that has precisely the angular diameter of the full Moon. Here you see how well everything matches:
  
  
  
  This image tests the globular cluster sizes BOTH in terms of the solar system sizes (Moon) AND independently, via the galactic size scale!
  
  
  
• The cluster star distribution is now considerably narrower than before, since the incorrectly placed stars further out have gone. Moreover, the low dynamic range of displays is simply unable to render > 10 magnitudes of faint cluster stars. Hence the outer region of clusters looks much more "depleted" than in reality, since the very faint stars can hardly be rendered along with the brightest ones.
  
  I made a lot of experiments and found that the so-called half-light radius or it's theoretical counterpart, the half-mass radius is a much better looking radius for characterizing the clusters' extent in the computer (not in Nature!). The half-light radius is also a very basic globular cluster parameter and has various theoretical advantages: it has been shown to be almost time independent on galactic time scales, for example. Also, the half-light radius is used in various other fashionable research contexts, e.g. for satellite clusters consisting of Dark matter in the neighborhood of galaxies.
  
  In Celestia, we cannot deny that for practical reasons certain significant "abstractions" are unavoidable:
  
  -- total number of globular cluster stars: in Nature it ranges between 10^4 and 10^7! In my code I use only 8192 (for obvious reasons of speed!).
  
  -- From the many available color-magnitude diagrams for globular clusters,
  
  http://dipastro.pd.astro.it/globulars/
  (click Databases->Ground-based data) or directly
  http://dipastro.pd.astro.it/globulars/d ... abase.html
  
  you may readily see that the apparent visual magnitude of cluster stars typically ranges over /many/ orders of magnitudes (>10), typically between mag=8-12 and mag=22-23! The vast majority of cluster stars has app.mags fainter than 20!
  
  In Celestia, all these faint stars cannot be rendered together with the brightest cluster stars. In Nature these faint stars are responsible for defining the mu25 isophote radius that we presently use as a standard cluster size parameter! The half-light radius or correspondingly the half-mass radius is much less dependent on all these faint stars that Celestia cannot render...
  
  On the other hand the mu25 isophote radius is the most correct radius from a researcher's point of view, say.
  
  I therefore retained the correct mu25 isophote radius in the text output on the canvas, but used the more appropriate half-mass radius for the red selection cursor!
  
  Note that I have implemented a patch by Chris that rotates the red selection cursor by 45 degrees, to avoid overwriting of labels, as I have proposed.
  This also improves on aliasing artefacts...
  
  The fake "galaxy ring" corresponds in it's outer rim to the half-mass radius
  
  
  
  
• For reasons of speed, I account for the dependence on the King concentration in form of 8 discrete bins of c, rather than admitting the full continuous range 0.5 < c < 2.58. The resulting bin width is 0.26.
  
  Here is a plot of the binned histogram for my actual data set of the 150 globular clusters in globulars.dsc.
  
  
  
  This simplification greatly increases the performance, while graphically the simplification can hardly be noted.

Enjoy,
Fridger

Thanks very much for the hard work here Good Doctor...
I'll giver 'er a test.

Brain-Dead

EDIT:
Nevermind... Dunno where to put the files.

BobHegwood wrote:Thanks very much for the hard work here Good Doctor...
I'll giver 'er a test.

Brain-Dead

You're welcome

Cheers,
Fridger

Everything looks good here. I built the KDE and QT4 versions. The QT4 version has the toggle switch built into the gui. Nice Job.
The clusters don't disappear too early anymore when moved to the edge of the screen. They look a bit dimmer too. More realistic I think.
Many Thanks.

BobHegwood wrote:EDIT:
Nevermind... Dunno where to put the files.

Fridger,
I don't know how long you are going to wait to commit this to svn so If you want, I can build the Windows version and put the executable in the svn update at CM.
Or I'll just wait until it is commited?
cartrite

cartrite wrote:Everything looks good here. I built the KDE and QT4 versions. The QT4 version has the toggle switch built into the gui. Nice Job.
The clusters don't disappear too early anymore when moved to the edge of the screen. They look a bit dimmer too. More realistic I think.
Many Thanks.

BobHegwood wrote:EDIT:
Nevermind... Dunno where to put the files.

Fridger,
I don't know how long you are going to wait to commit this to svn so If you want, I can build the Windows version and put the executable in the svn update at CM.
Or I'll just wait until it is commited?
cartrite

Many thanks Steve,

good to hear that things seem to be about OK so far...

Since I have rewritten a lot of code, it might be a good idea to have a Windows binary available. Sorry, I did'nt find the time to make one myself like last time.

Cheers,
Fridger

BobHegwood wrote:Thanks very much for the hard work here Good Doctor...
I'll giver 'er a test.

Brain-Dead

EDIT:
Nevermind... Dunno where to put the files.

Bob,

sorry, time was too short to produce a Windows binary. The C++ files are to replace the ones of the same names in the r4602 SVN sources. They are all located in the src/celengine subdirectory.

After that, Celestia will have to be recompiled, of course.

Fridger

OK The patched version of svn now has the new globular code. The regular svn version has the old globular code so they can be compared.
I was wondering. Which globular was used to compare it's size to the moon?
cartrite

cartrite wrote:I was wondering. Which globular was used to compare it's size to the moon?
cartrite

The reason I ask is because these new globulars look a lot smaller.
Both of these screenshots used the same bookmark so thet should both have the same settings.


cartrite

Fridger,

I've tested your files. It's working very well, but I have four "complaints" :

1- The orange blobs are too big at close range, compared to the white ones. I suggest to reduce their size a bit.

2- In the case of M4, I noticed a flickering effect while zooming on the cluster. At close range, the effect is also occuring while rotating gently around it. I can even make the cluster to totally vanish ! I didn't noticed that effect with other clusters yet, so I don't know why this is occuring with M4. I suspect this has nothing to do with the clusters, and may be an old bug in the galactic rendering.

3- Is it normal that we can't click on any cluster to select it ? EDIT : Actually, I can click on some clusters, but some other clusters are very hard to be clicked. Some clusters can't be clicked at all.

4- I noticed that in several cases, there's an isolated white blob which is standing pretty far away from the cluster. This solitary blob is annoying, visually. It should be removed.

I like pretty much the new 45° tilted cursor, by the way.

cartrite wrote:

cartrite wrote:I was wondering. Which globular was used to compare it's size to the moon?
cartrite

The reason I ask is because these new globulars look a lot smaller.
Both of these screenshots used the same bookmark so thet should both have the same settings.

old-m4.jpg

new-m4.jpg

cartrite

Steve,

In my original code, I still used this inferior star generation algorithm, which became highly ineffective at larger distances from the globular center. Therefore, to save CPU time, I only generated the stars near the center according to the peaked King profile and then did some "brute force" rescaling to account for the stars in the periphery, which unfortunately turned out quite incorrect for many globulars (like in your M 4 comparison!).

As I pointed out above, a concise test of the globular size is all but trivial, since globulars don't have a well defined extension. Instead, their luminosity distribution as function of distance from the center is characterized by various "radius" parameters (coreRadius, halfMassRadius, mu25Isophote Radius, tidalRadius)...

Since the Celestia stars are cut off already around appMag ~ 9 or so, we are hardly able to use the location of nearby stars, and their mutual distances on sceen as a check for the globular size scale in comparison with photographs.

Hence let me precisely state what the above quantitative triple test with the Moon amounts to.
You can easily repeat it yourself:

Let me redisplay the image for better reference:


Here is the mock .dsc file that I used for that test in extras/.

------------------------------sizetest.dsc--------------------------------------------------------
Globular "MT"
{
RA 16.5431 # [hours]
Dec -26.5253 # [degrees]
Distance 7176 # [ly]
Radius 32.773 # [ly], mu25 Isophote = core radius[ly]
CoreRadius 15.7 # [arcmin]
KingConcentration 0.001 # c = log10(r_t/r_c)
AbsMag -7.2 # [V mags]
Axis [ 0.1967 -0.6744 -0.7117]
Angle 171.8 # [degrees]
InfoURL "http://simbad.u-strasbg.fr/sim-id.pl?Ident=NGC 6121"
}

Galaxy "MT_core"
{
Type "E0"
RA 16.5431 # [hours]
Dec -26.5253 # [degrees]
Distance 7176 # [ly]
Radius 32.773 # [ly], "galaxy" radius [ly] <=> Moonradius (15.7') * distance [ly]
AbsMag -7.2 # [V mags]
Axis [ 0.1967 -0.6744 -0.7117]
Angle 171.8 # [degrees]
}

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

There are TWO objects centered at the same location, a "ringed" fake galaxy (MT_core) and a fake globular cluster (MT). (The object is a somewhat modified M 4. I moved the RA by about a degree.)

The galaxy-ring structure is from replacing the E0.png elliptical template with this ringed template



Here is the 128x128 .PNG original for download
http://www.celestiaproject.net/~t00fri/images/E0_ring.png
You must rename it to E0.png and save the original.

The outer rim of the ring has been set to Radius = 32.773 ly, which -- given the distance of 7176 ly -- amounts to an apparent angular size = 31.5 arcmin, identical to the angular size of the full Moon! By comparing the outer rim of the ring with the full moon size, tests immediately, whether the size scaling has been set correctly for galaxies... You can see from my image that this works fine.

Next, let us add in the globular cluster size test: We know from my above discussion (first image) that the luminosity distribution becomes increasingly shallow when the King concentration parameter decreases towards zero. This is good, since we want to see from the star distribution whether tidalRadius has the correct scale size! Since in general

tidalRadius = 10^c * coreRadius

for the limit c =>0, we get

tidalRadius = coreRadius

Therefore in the above fake globular MT, I put

c = 0 and
coreRadius[arcmin] = MoonRadius[arcmin] = 15.7 '

Moreover as Radius parameter, I inserted again the MoonRadius converted into lightyears!

Generating stars for c=0 means that not a single one must lie outside the coreRadius indicated by the outer rim of the "ring galaxy" MT_core.

In addition, if we substitute the true King distribution in eta =r / r_t (third image above, blue histogram!) by a uniform one in the same interval [0,1], then stars will be visible out to the tidalRadius and we can test immediately, whether all this is as expected.

To do this test yourself with the above .dsc file, all you got to modify in the globular.cpp code are two lines in the method 'buildGlobularForms(float c)':
-------------------------------- globulars.cpp -------------------------
line 545: do
// float eta = uu / sqrt((cc - 1.0f) * (1.0f - uu * uu) + 1.0f);
float eta = uu;
line 564: comment it out
// if (Mathf::frand() < prob / cH)
------------------------------------------------------------------------------

These two replacements substitute a uniform distribution for eta in [0,1], since uu = Mathf::frand() and Von Neumann has been "put on ice" !

Remember, the reason is that we want the stars to be visible out to the tidalRadius.

Recompile and try. The Moon is nearby MT, so you can easily compare the sizes...

Of course I have done many more related tests also using realistic values of the King concentration c and the correct King luminosity profile.

Fridger

Cham wrote:Fridger,

I've tested your files. It's working very well, but I have four "complaints" :

1- The orange blobs are too big at close range, compared to the white ones. I suggest to reduce their size a bit.

2- In the case of M4, I noticed a flickering effect while zooming on the cluster. At close range, the effect is also occuring while rotating gently around it. I can even make the cluster to totally vanish ! I didn't noticed that effect with other clusters yet, so I don't know why this is occuring with M4. I suspect this has nothing to do with the clusters, and may be an old bug in the galactic rendering.

3- Is it normal that we can't click on any cluster to select it ? EDIT : Actually, I can click on some clusters, but some other clusters are very hard to be clicked. Some clusters can't be clicked at all.

4- I noticed that in several cases, there's an isolated white blob which is standing pretty far away from the cluster. This solitary blob is annoying, visually. It should be removed.

I like pretty much the new 45° tilted cursor, by the way.

Martin,

many thanks for testing and your report!

• (1): The big orange stars are the familiar "Red Giant" stars, the diameter of which is really known to be "giant" => 70-100 times the solar one! They are a characteristic feature of most globulars. Here is a reminder: the inner part of M 80 from Hubble in true color:
  
  
  
  In my code, the 128 largest cluster stars are always associated with the orange Red Giants.
  
  The normal, smaller ones are then smaller by integer powers of 1.25 down to 1 pixel size, where the rendering stops. The number of stars in each size category increases by powers of two. The main advantage of this scheme is speed, which is crucial here! All these generated stars are effectively too large during the flight through the core. We cannot make the stars much smaller altogether, since we need to render them over a HUGE range of appMags (from 10 to 22!). The orange stars simply stick out more at short distance.
  
  Therefore, I don't want to fiddle the sizes further on close distance, since this just costs CPU time and the "flying through" option is anyway more of a joke. There are many other /unavoidable/ unrealistic issues when the observer is within the globular ... notably the star textures are missing, the stars are by far not bright enough (at least without HDR). Also we only got 8192 stars while realistically we should have 10^4..10^7. Finally we cannot render the large range of brightness needed...
  
  But I am always open to concrete good ideas here...
  
  
• (2): Yes I know about the flickering and tried to get rid of it, but... It is from stars close to the 1 pixel rendering cutoff. Perhaps Chris can help here with less effort?
  
  
• (3): Ooops, I forgot to substitute the mu25 radius by the halfMassRadius in the globular selection method etc. It's corrected now.
  
  
• (4): I cannot make out that white blob, sorry. Anybody can direct me there? How about a cel://url?

Fridger

I'll give your above test a try later today.
For now, here is a screen shot of why this was concerning me.
I went to the surface of the earth and centered the moon. Then I zoomed in a little, split the view horizontally, and used one view to center M4 at the same magnification. According to the text onscreen, shouldn't M4 should be a little bigger than the full moon? As you can see it is about half the size.
Moons apparent diameter as reported in the text is 29 min 44.8 seconds.
M4's apparent diameter as reported in the text is 36 min 11.2 seconds.
It looks a lot different than your test.



cartrite

cartrite wrote:I'll give your above test a try later today.
For now, here is a screen shot of why this was concerning me.
I went to the surface of the earth and centered the moon. Then I zoomed in a little, split the view horizontally, and used one view to center M4 at the same magnification. According to the text onscreen, shouldn't M4 should be a little bigger than the full moon? As you can see it is about half the size.
Moons apparent diameter as reported in the text is 29 min 44.8 seconds.
M4's apparent diameter as reported in the text is 36 min 11.2 seconds.
It looks a lot different than your test.

m4-moon.jpg

cartrite

Steve,

the apparent angular diameter of globulars (as shown on the top left of the canvas) is based on the globular's mu25 isophote radius. This is the "scientific" radius definition, most often used in catalogs etc. But please note: this definition uses very weak stars out to appMag = 22!!

Here you can see for yourself:

As an example, I chose M 4 = NGC 6121:



We simply don't have the technology at present to render in Celestia all those faint stars, making up the bulk of the globular cluster stars! Moreover, for reasons of speed, I can only handle < 10^4 stars while reality requires <10^7 stars. Please note also that from the diagram the brightest stars in M 4 have appMag =11! The cluster is dominated by stars fainter than appMag=16. So how can you ever hope to see such dim peripheral stars from the surface of Earth without a big telescope?

Here is a typical corresponding photo of M 4, from which you can see how tiny the bright core really is!



Note that the radius of the bright angular core of M 4, coreRadius = 0.83 arcmin, i.e. ONLY 1/21 th of the Moon's radius.

+++++++++++++++++++++++++++++++++
That's about how your above comparison image looks like, doesn't it?
+++++++++++++++++++++++++++++++++

The mu25 isophote radius, however is HUGE, compared to the coreRadius and made up by a host of VERY weak cluster stars in the range appMag = 16..21. Visually, such stars are just way out, and Celestia cannot do better here...

Practically ALL the faint outer stars --that are crucial for the mu25 radius definition-- and correspondingly the large 36' size of M 4, cannot be rendered in Celestia!! That's why the Celestia clusters appear so much smaller than corresponding to the value of the mu25 isophote radii.

Fridger

Here is the corrected globulars.cpp file. The globular cluster selection should work fine now.

http://www.celestiaproject.net/~t00fri/images/globular.cpp.zip

Let me know...

Fridger

OK I see your point. I guess I didn't realize that most of the stars were not visible. I guess I can also remember looking though a telescope at these globulars. I was never able to resolve actual stars. Only a faint haze around a small core.
PS Seems like something is wrong here at the forum. I was unable to "look up" Shatters.net with my browser. I had to use the ip address to get here.
cartrite

NOW I am totally confused!!

++++++++++++++++++++++++++++
The cluster size scale in my new code might just be incorrect, while the old one appears to be roughly right (apart from some stars that were slipped beyond the tidalRadius).
++++++++++++++++++++++++++++

Here is the new STRONG evidence:

At last I found an amazing 3600x3600 photo of M 13 and its environments. I cut out the relevant part, comprising two bright HIP stars and two dim galaxies besides M 13 in all it's splendor. Here is the reference photo:



Note the two galaxies NGC 6207, IC 4617 and the two bright HIP stars, 81848, 81673!

Note the substantial diameter of M13 in comparison to
the distances M13 ---- Hip 81848 and M13 ---- 81673.

Now let's compare this with Celestia. First from my original code (before the patch):



Surprisingly the size of M13 seems about right relative to the distances M13 <-> Hip 81848 and M13 <-> 81673!

Finally, we look at the results from my new patch:



It just seems that the size of M13 is way too small!

+++++++++++++++++++++++++++++++
I am afraid, I'll need another day or two to sort this confusion out...
+++++++++++++++++++++++++++++++

Fridger

t00fri wrote:

Cham wrote:2- In the case of M4, I noticed a flickering effect while zooming on the cluster. At close range, the effect is also occuring while rotating gently around it. I can even make the cluster to totally vanish ! I didn't noticed that effect with other clusters yet, so I don't know why this is occuring with M4. I suspect this has nothing to do with the clusters, and may be an old bug in the galactic rendering.

[*] (2): Yes I know about the flickering and tried to get rid of it, but... It is from stars close to the 1 pixel rendering cutoff. Perhaps Chris can help here with less effort?

I see the star flickering, too. The best way to get rid of it is to enable anti-aliasing (ideally, 4x or better.) To fix it without anti-aliasing, I think we'd have to implement some sort of anti-aliased pointer rendering in the shader. I've thought about doing this for stars, but haven't seriously pursued the idea yet. I have a feeling that Martin is talking about something else though: while I see flickering stars with anti-aliasing disabled, I never see an entire globular cluster disappear. Maybe there's a clipping bug? A cel URL for one of these invisible globulars would be very helpful for debugging.

--Chris

chris wrote:

t00fri wrote:Maybe there's a clipping bug? A cel URL for one of these invisible globulars would be very helpful for debugging.

It feels like a clipping bug to me. Chris, try M4. This is the cluster which suffers the most of the flickering while rotating around the cluster. This is a huge bug, IMO.

Cham wrote:

chris wrote:

t00fri wrote:Maybe there's a clipping bug? A cel URL for one of these invisible globulars would be very helpful for debugging.

It feels like a clipping bug to me. Chris, try M4. This is the cluster which suffers the most of the flickering while rotating around the cluster. This is a huge bug, IMO.

It's working fine for me... Can you give me a cel URL? If this is a clipping bug, it's possible that it occurs on ATI cards only--ATI hardware has shown a lot more sensitivity to clipping issues than NVIDIA hardware.

--Chris

Cham wrote:

chris wrote:

t00fri wrote:Maybe there's a clipping bug? A cel URL for one of these invisible globulars would be very helpful for debugging.

It feels like a clipping bug to me. Chris, try M4. This is the cluster which suffers the most of the flickering while rotating around the cluster. This is a huge bug, IMO.

I normally don't publish huge bugs

I cannot see anything like you describe neither for M4 nor for other globulars. When moving around M4 both at larger and smaller distances I can't even see any flickering at all. For such cases we normally use either a cel://url or a video clip.


Fridger