Globular Cluster Simulation

[t00fri]

Hi all,

well, after suffering from all sorts of frustration symptoms recently , I thought it might nevertheless be appropriate to provide some brief status report of my globular cluster simulation that I have developed during the past weeks. I have decided that the code may be integrated into Celestia , if Chris wants it...

I am still planning to expose the underlying astrophysics in a more detailed discussion over at CelestialMatters...And yes, after some further tunings there will be something for you to try out

Let me just start with a few screen shots, so you know that I am not telling you "fairy tales" ...

For now I associated the globular labels with some "sepia red". In this first image, you see that there is quite a bit of new "globular action" in my Celestia canvas:


The labels appear and vanish smoothly in the usual dynamical fashion, and the globulars are based on the following 3 catalogs, listed in the boiler plate of my globulars.dsc data file:

Code: Select all

# "Catalog of Parameters for Milky Way Globular Clusters",
# 2003 Update, by William E. Harris.
# http://physwww.physics.mcmaster.ca/~harris/mwgc.dat
# Bibliography: http://physwww.mcmaster.ca/%7Eharris/mwgc.ref
# supplemented by diameters <=> 25mu isophote from
# Brian A. Skiff/Lowell Observatory, NGCIC project,
# http://www.ngcic.org/data_archive/gc.txt
# supplemented by diameters <=> 25mu isophote from
# the SEDS 2007 catalog (H. Frommert)
# http://www.seds.org/~spider/spider/MWGC/mwgc.html
# Adapted for Celestia with Perl script: globulars.pl Revision: 1.0.0
# Processed 2008-5-10 6 130 0 11:33:33 UTC
#
# by Dr. Fridger Schrempp, fridger.schrempp@desy.de
# ------------------------------------------------------


A typical entry looks right now like this (but will eventually have more color related info)

Code: Select all

Globular "47 Tuc:NGC 104"
{
        SpectralType           "G4"
        RA                 0.4014  # [hours]
        Dec              -72.0808  # [degrees]
        Distance        1.468e+04  # [ly]
        Radius              106.7  # [ly], mu25 Isophote
        CoreRadius            0.4  # [arcmin]
        KingConcentration     2.03  # c = log10(r_t/r_c)
        CentralSB           14.43  # [V mags/arcsec^2]
        AbsMag              -9.42  # [V mags]
        Axis          [ -0.7429  -0.2364  -0.6263]
        Angle               175.9  # [degrees]
        InfoURL  "http://simbad.u-strasbg.fr/sim-id.pl?Ident=NGC 104"
}


Altogether I have 150 globulars associated with the MilkyWay in that list. That's the number that is considered safe.

For now the rendering of the globulars and the label display is activated via the LUA start.celx startup file, with the commands:

Code: Select all

celestia:showlabel("globulars")
celestia:show("globulars")


The light level of the central part of the globulars can be adjusted, but I did not find an empty key anymore . So I put it together with the light level adjustment of the galaxies...

At first sight, the simulation of globulars looks kind of simple, but this is NOT the case! The morphology of globulars actually depends on several radius parameters that characterize the central concentration as well as the total spacial extent of the globular (tidal radius). In addition, from the other two catalogs , I added the mu25 Isophote radius data that provide a physically sensible definition of the cluster's size.

Another delicate characteristic of globulars is their respective "color-magnitude" diagram. Generically, it looks like so:



It is characterized by the bright "red giants" on the top right, the characteristic structure of the "horizontal branch (HB)" and more exotic fellows like the "blue strugglers" etc.

To provide some illustration of the state of the art, here is first of all a comparison of the great 47 Tuc globular in my simulation with the best photographic image I could find. Note the bright "red giants" in my simulation and the inserted photo!. They are bright orange and should be "sprinkled" in a conspicuous manner all over the globular. That's what my simulation shows.



Here is the great OmegaCentauri, so you can get a feel for the diversity of the distributions:


Now, how are the globular star distributions generated?

They are based on some "ingenious" papers by Ivan King long, long ago! In his first 1962 paper, he describes some surprisingly simple surface brightness profiles that still today fit many globulars very well.

http://articles.adsabs.harvard.edu/cgi- ... etype=.pdf

In a later 1966 paper, much of these empirical profiles was derived on the basis of solid astrophysical dynamics.

http://articles.adsabs.harvard.edu/cgi- ... etype=.pdf

The 2003 globular cluster catalog of Harris, fortunately quotes the best King parameters for all globulars in the list. That forms the basis of my simulation. More of this I'll describe in a forthcoming discussion at CM.

The main task is now to randomly generate a set of stars that are distributed in 3d space according to King's luminosity profile, with parameters to be extracted from the Harris catalog.

This task was routine for me.

The statistical generation of stars was of course based on Von Neumann's Rejection-Acceptance method. Every theoretical physicist knows it in and out . Here is a reference:

http://www-theory.lbl.gov/

look up "PDG->Reviews, Tables, Plots->Mathematical Tools" -> MonteCarlo Techniques -> Acceptance-rejection Method (Von Neumann)

I did a lot of experiments to decide about the best rendering solution: sprites versus stars. The present displayed solution corresponds to some simple sprite rendering.

Another interesting issue that I have not yet incorporated, concerns the fact that astrophysically, there is an almost indistinguishable "family relation" between globulars and (spheroidal) dwarf galaxies (note, NOT galaxies, but dwarfs!).
e.g. http://arxiv.org/pdf/0711.4795

Detailed recent investigations have shown that virtually the only distinguishing feature is ellipticity: for globulars it's always < 0.3 while for dwarfs it can be bigger. Moreover there seem to be definite environmental connections between Dwarf Spheroidal Galaxies/ Globulars and their host galaxies
http://arxiv.org/pdf/0802.4061


So much for now...

Fridger

[t00fri]

Oh yes, I forgot...

Here you see that the mu25 Isophote radius is a sensible characterization of the actual size of a globular: The image compares the angular size of the globular M4 (36') with that of the Moon (~30').
Looks OK, doesn't it? Note that other little globular down there


Next, here is a smaller view of 47 Tuc relative to our SMC neighboring galaxy:



Fridger

[ajtribick]

This is great news... globular clusters are a most welcome addition!

Out of interest, how does the distance to PSR B1620-26 (the pulsar+white dwarf+planet system in M4, defined in extrasolar.stc) compare to the distances used in the catalogues?

[BillC]

Fridger,

Lovely lovely work. I hadn't expected accurate star colors - your simulation of 47 Tucana is stunning. Instinctively I agree with the use of sprite rendering - I would want a rendering of globulars to be perceived as somewhere "between" galaxies and open clusters, if you get what I mean. Thanks for all the effort on defining radius, core radius, distribution, etc. - done with your usual thoroughness.

The dwarf galaxies are an unexpected bonus! Are any of these dwarfs in deepsky.dsc? Do we get a tasty side order catalog of dwarfs to go with our entree of globulars?

Bill C

[t00fri]

This is great news... globular clusters are a most welcome addition!

Out of interest, how does the distance to PSR B1620-26 (the pulsar+white dwarf+planet system in M4, defined in extrasolar.stc) compare to the distances used in the catalogues?

The distance of M4 to the Sun, according to Harris 2003 is

Distance 7176 # [ly]

while this extrasolar object in M4 is tagged at

Distance 12000 ly

Since the Harris distance data correspond to the state of the art...I feel the extrasolar value is a bit large . The Harris distances refer to the distances from the Sun to the DSO.


Fridger

[chris]

Hi all,

well, after suffering from all sorts of frustration symptoms recently , I thought it might nevertheless be appropriate to provide some brief status report of my globular cluster simulation that I have developed during the past weeks. I have decided that the code may be integrated into Celestia , if Chris wants it...

Definitely! This work looks very promising indeed. The distribution of stars looks quite convincing.

I do feel like we will need to tune Celestia's sprite rendering code a bit. We attempt to do a logarithmic mapping (i.e. linear with magnitude) of star brightness to pixel value. However, the alpha blending of overlapping stars is linear. Thus given two stars with apparent brightnesses (not magnitudes) b0 and b1, the pixel values are v0 = log(b0) and v1 = log(b1). If these stars overlap the same pixel, the value of that pixel should be vsum = log(b0 + b1). But because hardware alpha blending is linear, we end up instead with vsum = log(b0) + log(b1). This is the reason that double stars often appear too bright when seen from a great distance. It will be even more of a problem with naive rendering of globular clusters, where many stars in the core are likely to overlap the same pixel.

Just to be clear, I am not saying that this a problem with your star distributions, or even a problem specific to globular clusters. Rather, it's a limitation of graphics hardware (and 8-bit per channel rendering) that we need to deal with. With higher dynamic range frame buffers (16-bit per channel or higher), it's not such an issue since we can calculate the log of all pixels after alpha blending everything. For 8-bit per channel buffers, it should be possible to replace rendering many individual stars below some threshold brightness with a single larger sprite representing the cloud of dimmer stars. This brightness of this cloud would vary in physically accurate way based on the apparent size of the cluster and the minimum visible magnitude. This technique also has the advantage of eliminating a lot of extra rendering for small or dim clusters. Do you think that it would be worthwhile to try it?

--Chris

[t00fri]

Fridger,

Lovely lovely work. I hadn't expected accurate star colors - your simulation of 47 Tucana is stunning. Instinctively I agree with the use of sprite rendering - I would want a rendering of globulars to be perceived as somewhere "between" galaxies and open clusters, if you get what I mean. Thanks for all the effort on defining radius, core radius, distribution, etc. - done with your usual thoroughness.

The dwarf galaxies are an unexpected bonus! Are any of these dwarfs in deepsky.dsc? Do we get a tasty side order catalog of dwarfs to go with our entree of globulars?

Bill C

Bill,

thanks for the flowers

The point being that according to latest results, globulars and dwarfs seem very closely related.

So conceptionally the best C++ class structure would be to join my dwarfs (from the local group)[ deepsky.dsc] and the globulars in one class (of course derived from the DeepSkyObject class). Right now I just use a Globular class that is derived from the DeepSkyObject class. The Unification with the Dwarfs from deepsky.dsc is no big deal and can be added any time.

Fridger

[t00fri]

I do feel like we will need to tune Celestia's sprite rendering code a bit. We attempt to do a logarithmic mapping (i.e. linear with magnitude) of star brightness to pixel value. However, the alpha blending of overlapping stars is linear. Thus given two stars with apparent brightnesses (not magnitudes) b0 and b1, the pixel values are v0 = log(b0) and v1 = log(b1). If these stars overlap the same pixel, the value of that pixel should be vsum = log(b0 + b1). But because hardware alpha blending is linear, we end up instead with vsum = log(b0) + log(b1). This is the reason that double stars often appear too bright when seen from a great distance. It will be even more of a problem with naive rendering of globular clusters, where many stars in the core are likely to overlap the same pixel.

Just to be clear, I am not saying that this a problem with your star distributions, or even a problem specific to globular clusters. Rather, it's a limitation of graphics hardware (and 8-bit per channel rendering) that we need to deal with. With higher dynamic range frame buffers (16-bit per channel or higher), it's not such an issue since we can calculate the log of all pixels after alpha blending everything. For 8-bit per channel buffers, it should be possible to replace rendering many individual stars below some threshold brightness with a single larger sprite representing the cloud of dimmer stars. This brightness of this cloud would vary in physically accurate way based on the apparent size of the cluster and the minimum visible magnitude. This technique also has the advantage of eliminating a lot of extra rendering for small or dim clusters. Do you think that it would be worthwhile to try it?

--Chris

Chris,

actually, I spent quite some thinking about this rather obvious issue.

What you suggest is conceptionally clear, but I am not sure whether there is an easy compromise between the rendering issues you address and theoretical exactness of the globulars' luminosity distribution.
And I don't want to sacrifice the latter.

First of all, we must clarify to WHAT reference imaging we want to compare the Celestia rendering of globulars!? Photographic imaging and human vision have drastically different characteristics as to the issue you were addressing. Note that, above, I artificially tuned up the central light level to match the photographic reference image for 47 Tuc! All respective photos are always badly overexposed in the center, due to the poor photographic dynamical range. Actually, the natural central brightness of my globular display is significantly lower, due to my theoretical precautions that I have built in already. But I wanted to display a comparison with some real photo for people to hang on

While I clearly understand what you proposed, it is nontrivial to prove that the light from your big sprites finally is distributed in concordance with the theoretical luminosity distribution. Perhaps you can convince me that your recipe is statistically correct...I would be looking forward to a respective proof. Note that there are some technical complications on the way: the star generation needed to be done according to the 3d King luminosity profile, but then the 3d result has to be projected onto the 2d skyplane. The formulae are in King's papers and can easily be derived.

Anyway, I'll contemplate a bit, perhaps I find a practical way, how to improve on the log (I1*I2) vs log(I1 + I2) problematics, given your suggestions.

Finally, let me put the problem into some generic terms that physicists like in this context: We have a hardware device, the monitor, with a certain (poor) imaging characteristics. The ratio between the TRUE visual light distribution (generated according to King) and the one that the monitor shows is some hardware specific efficiency function. We would be interested in the true light distribution but for practical reasons can hardly account for the efficiency correction in real time. So what is the best approach, if we don't want to loose the connection to the THEORETICAL light distribution!?

Fridger

[chris]

I do feel like we will need to tune Celestia's sprite rendering code a bit. We attempt to do a logarithmic mapping (i.e. linear with magnitude) of star brightness to pixel value. However, the alpha blending of overlapping stars is linear. Thus given two stars with apparent brightnesses (not magnitudes) b0 and b1, the pixel values are v0 = log(b0) and v1 = log(b1). If these stars overlap the same pixel, the value of that pixel should be vsum = log(b0 + b1). But because hardware alpha blending is linear, we end up instead with vsum = log(b0) + log(b1). This is the reason that double stars often appear too bright when seen from a great distance. It will be even more of a problem with naive rendering of globular clusters, where many stars in the core are likely to overlap the same pixel.

Just to be clear, I am not saying that this a problem with your star distributions, or even a problem specific to globular clusters. Rather, it's a limitation of graphics hardware (and 8-bit per channel rendering) that we need to deal with. With higher dynamic range frame buffers (16-bit per channel or higher), it's not such an issue since we can calculate the log of all pixels after alpha blending everything. For 8-bit per channel buffers, it should be possible to replace rendering many individual stars below some threshold brightness with a single larger sprite representing the cloud of dimmer stars. This brightness of this cloud would vary in physically accurate way based on the apparent size of the cluster and the minimum visible magnitude. This technique also has the advantage of eliminating a lot of extra rendering for small or dim clusters. Do you think that it would be worthwhile to try it?

--Chris

Chris,

actually, I spent quite some thinking about this rather obvious issue.

What you suggest is conceptionally clear, but I am not sure whether there is an easy compromise between the rendering issues you address and theoretical exactness of the globulars' luminosity distribution.
And I don't want to sacrifice the latter.

First of all, we must clarify to WHAT reference imaging we want to compare the Celestia rendering of globulars!? Photographic imaging and human vision have drastically different characteristics as to the issue you were addressing. Note that, above, I artificially tuned up the central light level to match the photographic reference image for 47 Tuc! All respective photos are always badly overexposed in the center, due to the poor photographic dynamical range. Actually, the natural central brightness of my globular display is significantly lower, due to my theoretical precautions that I have built in already. But I wanted to display a comparison with some real photo for people to hang on

While I clearly understand what you proposed, it is nontrivial to prove that the light from your big sprites finally is distributed in concordance with the theoretical luminosity distribution. Perhaps you can convince me that your recipe is statistically correct...I would be looking forward to a respective proof. Note that there are some technical complications on the way: the star generation needed to be done according to the 3d King luminosity profile, but then the 3d result has to be projected onto the 2d skyplane. The formulae are in King's papers and can easily be derived.

I think the problem can be simplified quite a bit if we just use a single circular (or ellipsoidal, if we get eventually get orientation information) 'cloud' sprite with a luminosity profile matching the projection of the theoretical distribution. There are several ways to do this--a dynamically generated texture, a pixel shader, or simply tessellated circle geometry. Then, the problem is to find a weighting function to blend this 'cloud' sprite and the sprites representing stars. The weighting function would not be constant across the disc of the globular: it would vary based on the density of stars per pixel, favoring the cloud sprite at high star densities and star sprites at low densities.

As a starting point, let's call the weighting function w(r). The unweighted luminosity of the cloud sprite is given by C(r), which is just the projected luminosity profile from the King characteristics of the globular. S(x,y) is the sum of the luminosities of the star sprites, which in aggregate approximates C(r). A simple linear blend w(r)C(r) + (1-w(r))S(x,y) will give a profile that still matches theoretical one, regardless of the weighting function that we choose. Intuitively, we want a weighting that favors the cloud sprite at high star densities in order to prevent stacking of stars and the resultant overbrightness (or underbrightness: if the pixel value of a star sprite is less than 1/255, we get blackness no matter how many are stacked.) A simplistic weighting function might be w(r) = 1 - 1/kD(r), where D(r) is the density of stars per pixel and k is a constant that can be tuned to optimize appearance (any choice will result in a physically correct profile; it should be chosen to avoid rendering either too many or too few stars.) Obviously, the 1/kD(r) term needs to be clamped so that it is <= 1.

A very useful optimization can be used with this scheme. We want to avoid rendering a lot of stars when the apparent size of a globular is very small. In this case, most or all of the luminosity should come from the cloud sprite. We can store the list of sprites for the globular sorted by decreasing distance from the center. When rendering sprites, we can start at the beginning of the list and stop rendering once we reach sprites we reach a threshold radius determined by the weighting function. The threshold is the point at which the weighting function results in sprites too dim to show up. The red giants are much brighter and wouldn't be subject to this culling.

Anyhow, these are just some rough ideas--I could very well be overestimating the impact of overbright/underbright globulars at small apparent sizes and performance problems when many globulars are in view.

Finally, let me put the problem into some generic terms that physicists like in this context: We have a hardware device, the monitor, with a certain (poor) imaging characteristics. The ratio between the TRUE visual light distribution (generated according to King) and the one that the monitor shows is some hardware specific efficiency function. We would be interested in the true light distribution but for practical reasons can hardly account for the efficiency correction in real time. So what is the best approach, if we don't want to loose the connection to the THEORETICAL light distribution!?

It is possible to account for the efficiency function in real time on GeForce 6 class or later hardware and floating point frame buffers. This requires very significant (but worthwhile) modifications to Celestia's rendering. This affects a lot more than the rendering of globular clusters, however. For the specific case of globular clusters,

--Chris

[ElChristou]

Stunning work, as always!

[ANDREA]

Wow, Fridger, your GCS results look fantastic, indeed.
Very appreciated, many thanks.
Bye

Andrea

[Cham]

Looking very promising. Thanks for that great work !

[buggs_moran]

I did a lot of experiments to decide about the best rendering solution: sprites versus stars. The present displayed solution corresponds to some simple sprite rendering.

By this statement and your ensuing discussion with Chris should I assume you are definitely going the sprite route for cluster generation or are you still on the fence Fridger? I also assume the reason to stay away from stars is the large draw on resources.

[BobHegwood]

If I might just make a small observation here?

The globular clusters via sprites simply do NOT look realistic on my system. I don't know if it has something to do with my hardware or not, but I had the same problem with Io's eruptions when Chris tried rendering them with point sprites. For whatever reason, these look way too artificial (and hard-edged?) on my system.

Not complaining here, just my two cents worth again.

Thanks, Bob

[t00fri]

Chris,

sorry for my delay in answering, but I was pretty busy with other duties during the last few days.

I think the problem can be simplified quite a bit ...

As I will discuss below, this holds only, since your arguments, miss out virtually all the non-trivial complications that are typical for the simulation of globulars in 3d...

The scenario that you outlined, was the first one I tried quite a while ago.

Yet I soon realized that due to the complex interplay of 3d distributions and their 2d sky projections and notably due to the dependence of the globular morphology on 3 crucial parameters, your simplistic type of 2d textbook alpha blending ansatz tends to become too involved for being practical. At least for my taste. Of course, if one is ready to fiddle and give up much of the underlying theoretical framework, what you described will work fine. But I am not.

In other words,

• your weight function w(r) is obviously not only a function of r but also of the characteristic shape parameters r_c (core radius) and c=King concentration = log10(r_t/rc). In my present code, I exploited a scaling property of the 3d King profile in r/r_c. So, in the initialization method, I generated once for all a set of 8 globularForms, covering the physical range of c values :
  

  Code: Select all

      globularForms = new GlobularForm*[8];
    for (unsigned int cslot  = 0; cslot <= 7; ++cslot)
    {
        float c = 0.5 + (float) cslot * 0.35f;
      globularForms[cslot] = buildGlobularForms(c);
    }

  
  The r_c dependence simply enters via a form->scale command
  during the sprite rendering stage
  

  Code: Select all

  form->scale = Vec3f(0.4f/r_c, 0.4f/r_c, 0.4f/r_c);

  
  This quite effective parameter handling works rigorously, since I did not subscribe to the hybrid scenario that you proposed.
  
• The next major complication is the non-trivial interrelation of 2d and 3d luminosity profiles along with their different purposes. Note the random generation of small star sprites in 3d has to proceed according to the 3d profile phi_3d(r,...)! The following number distribution of 3d globular points was generated with the code below (buildGlobularForms(float c)) and agrees perfectly with the normalized King 1962 luminosity profile (red curve):
  
  
  
  Here is the corresponding code:
  

  Code: Select all

  GlobularForm* buildGlobularForms(float c)
{
   GBlob b;
   vector<GBlob>* globularPoints = new vector<GBlob>;

   float prob;
   float cc =  1.0f + pow(100.0f,c);
   unsigned int i = 0;
      
   // 3d King1962 profile at center:   
   float prob0 = acos(1.0f/sqrt(cc)) - pow(10.0f,c)/cc;
      
   // generate globular surface distribution from King,I.R. 1962
   // probability prob ~ phi(rho) of King; rho =r/r_c
   // King c-parameter: c=log10(r_t/r_c)
   // reference r_c = 0.4f arcmins.      
   // use acceptance-rejection method (Von Neumann) for generating points
   // according to distribution prob of King 1962.   
      
   do
   {   
      float r = 1.0f * Mathf::frand();
       float rho = r/0.4f;
      float rho2 = 1.0f + rho*rho;
      
      // 3d King1962 luminosity profile:      
      prob = (acos(sqrt(rho2/cc))/sqrt(rho2) - sqrt(cc-rho2)/cc)/rho2;
            
      // generate 3d points of globular cluster in polar coordinates
      // as function of r = sqrt(x^2 + y^2 + z^2), they will be       
      // distributed according to the 3d King luminosity profile:      
      if (Mathf::frand() < prob/prob0)
      {
         float u = Mathf::sfrand();
         float theta = 2 * PI * Mathf::frand();
         b.position = Point3f(r * sqrt(1 - u * u) * cos(theta), r * sqrt(1 - u * u) * sin(theta), r * u);
         b.brightness = r;
           unsigned int ci =  (unsigned int) (r * 512);       
           b.colorIndex  = ci < 256? ci: 255;
            globularPoints->push_back(b);               
         i++;      
      }
   } while (i < GLOBULAR_POINTS);
   sort(globularPoints->begin(), globularPoints->end());   
   random_shuffle( globularPoints->begin() + KMIN, globularPoints->end());   
   GlobularForm* globularForm  = new GlobularForm();
   globularForm->gblobs        = globularPoints;
   globularForm->scale         = Vec3f(1.0f,1.0f,1.0f);   
      
   return globularForm;
}


  
  
  Now...
  
  Your advocated matching between the big cloud sprite distribution and the distribution consisting of individual small star sprites happens in its 2d sky projection phi_2d(r,...)! The relation between the two is NON-local in r, i.e involves an extended integration:
  
  [tex]\large \phi_{3d}(r)=-\frac{1}{\pi}\int_r^{r_t}\left[\frac{d\phi_{2d}(r^\prime)}{dr^\prime}\right]\frac{dr^\prime}{\sqrt{r^{\prime\,2}-r^2}}[/tex]
  
  Now on the right-hand side of this formula, you have to insert your 2d hybrid ansatz including the weight function w(r,...),
  
  [tex]\phi_{2d}(r^\prime,...) = w(r^\prime,...) \, C(r^\prime,...) + (1 - w(r^\prime,...))\, S(x^\prime,y^\prime,...),[/tex]
  
  Now w(r') is NOT arbitrary anymore due to the integration...Notably, the integration can most probably not been done analytically anymore, as in my setup. This costs time...
  
• Finally, the blending between the cloud sprite and the discrete star sprite distribution has to be perfect also upon close approach, when the full 3d structure becomes paramount.

I also used effective measures to control the central brightness. And certainly, I do not generate star sprites unnecessarily once the globular size is below the 'minimumFeatureSize = pixelSize * distanceToDSO'. I also cannot observe any problem of performance with my code. Of course these standard issues were carefully examined since early on... Also my somewhat related galaxy code so far has performed pretty well...

But most importantly, before addressing all this "technology", one has to decide about the basic question:

++++++++++++++++++++++++++++++
What do we want to take as a reference for the modelling of central DSO brightness in Celestia?
++++++++++++++++++++++++++++++
The two main alternatives are:

a) We compare TWO "low dynamics" imaging devices, i.e the DSO rendering on a computer monitor with the rendering on a photograph. Both have STRONG (related) dynamical limitations, YET people are used to photographic imaging characteristics! That should perhaps NOT be ignored...

Practically ALL existing lower resolution photos of globulars are hopelessly overexposed i.e saturated in their centers compared to their visual appearance through a (small) telescope. Hence the apparent central brightness in photos is largely UNRELATED to the integrated magnitude of the cluster!

b) We try to model "somehow" the visual appearance. This is a largely subjective procedure, since precise data are lacking (both concerning efficiencies and a reduction of the globular appearance to visual level).

It was entirely unclear to me, which of these two alternatives you intended to approach by means of the "tuning" you proposed above ...

The problematics of linear hardware blending in the context of central stacking of overlapping sprites is a general issue, and should equally have been discussed in the context of galaxies, binaries etc. So I don't quite understand why you did get into "teaching mode" NOW, even before you had a chance playing with my globular cluster code .

Since you are the local OpenGL expert, perhaps you know a method of blending that will be essentially compatible with all these theoretical constraints. Why don't you try writing down some more concrete blending code that respects all this?

Fridger

[chris]

I still think that there's some merit to my approach, but I'll wait for your first implementation before commenting further. If you already have an approach that performs well and renders globular clusters nicely at a variety of apparent sizes, then there's no need for my hybrid rendering approach. I'm still not convinced that the globulars will look right at small sizes, but I'll wait and see.

Chris,
Here is the corresponding code:

Code: Select all

GlobularForm* buildGlobularForms(float c)
{
   GBlob b;
   vector<GBlob>* globularPoints = new vector<GBlob>;

   float prob;
   float cc =  1.0f + pow(100.0f,c);
   unsigned int i = 0;
      
   // 3d King1962 profile at center:   
   float prob0 = acos(1.0f/sqrt(cc)) - pow(10.0f,c)/cc;
      
   // generate globular surface distribution from King,I.R. 1962
   // probability prob ~ phi(rho) of King; rho =r/r_c
   // King c-parameter: c=log10(r_t/r_c)
   // reference r_c = 0.4f arcmins.      
   // use acceptance-rejection method (Von Neumann) for generating points
   // according to distribution prob of King 1962.   
      
   do
   {   
      float r = 1.0f * Mathf::frand();
       float rho = r/0.4f;
      float rho2 = 1.0f + rho*rho;
      
      // 3d King1962 luminosity profile:      
      prob = (acos(sqrt(rho2/cc))/sqrt(rho2) - sqrt(cc-rho2)/cc)/rho2;
            
      // generate 3d points of globular cluster in polar coordinates
      // as function of r = sqrt(x^2 + y^2 + z^2), they will be       
      // distributed according to the 3d King luminosity profile:      
      if (Mathf::frand() < prob/prob0)
      {
         float u = Mathf::sfrand();
         float theta = 2 * PI * Mathf::frand();
         b.position = Point3f(r * sqrt(1 - u * u) * cos(theta), r * sqrt(1 - u * u) * sin(theta), r * u);
         b.brightness = r;
           unsigned int ci =  (unsigned int) (r * 512);       
           b.colorIndex  = ci < 256? ci: 255;
            globularPoints->push_back(b);               
         i++;      
      }
   } while (i < GLOBULAR_POINTS);
   sort(globularPoints->begin(), globularPoints->end());   
   random_shuffle( globularPoints->begin() + KMIN, globularPoints->end());   
   GlobularForm* globularForm  = new GlobularForm();
   globularForm->gblobs        = globularPoints;
   globularForm->scale         = Vec3f(1.0f,1.0f,1.0f);   
      
   return globularForm;
}


I think that there's a bug in this code--it doesn't seem like it will generate a spherically symmetric distribution of stars. Stars will tend to be concentrated near the poles of the cluster. You pick z coordinate of the sprites randomly, but the area of the sphere slices of constant z decreases as |z| increases. I think that you want something like this:

Code: Select all

Vec3f pos;
bool accept = false;

while (!accept)
{
    // Pick a random point in the cube with corners (-1, -1, -1) and (1, 1, 1)
    pos = Vec3f(sfrand(), sfrand(), sfrand());
    float r = pos.length();

    // Reject any points that like outside the unit sphere
    if (r < 1.0f)
    {
        float rho = r/0.4f;
        float rho2 = 1.0f + rho*rho;
      
        // 3d King1962 luminosity profile:      
        prob = (acos(sqrt(rho2/cc))/sqrt(rho2) - sqrt(cc-rho2)/cc)/rho2;

        accept = Mathf::frand() < prob/prob0;
    }
}

// pos now contains a point in the spherically symmetric distribution


Your advocated matching between the big cloud sprite distribution and the distribution consisting of individual small star sprites happens in its 2d sky projection phi_2d(r,...)! The relation between the two is NON-local in r, i.e involves an extended integration:

[tex]\large \phi_{3d}(r)=-\frac{1}{\pi}\int_r^{r_t}\left[\frac{d\phi_{2d}(r^\prime)}{dr^\prime}\right]\frac{dr^\prime}{\sqrt{r^{\prime\,2}-r^2}}[/tex]

Now on the right-hand side of this formula, you have to insert your 2d hybrid ansatz including the weight function w(r,...),

[tex]\phi_{2d}(r^\prime,...) = w(r^\prime,...) \, C(r^\prime,...) + (1 - w(r^\prime,...))\, S(x^\prime,y^\prime,...),[/tex]

Now w(r') is NOT arbitrary anymore due to the integration...Notably, the integration can most probably not been done analytically anymore, as in my setup. This costs time...

[*] Finally, the blending between the cloud sprite and the discrete star sprite distribution has to be perfect also upon close approach, when the full 3d structure becomes paramount. [/list]

I also used effective measures to control the central brightness. And certainly, I do not generate star sprites unnecessarily once the globular size is below the 'minimumFeatureSize = pixelSize * distanceToDSO'. I also cannot observe any problem of performance with my code. Of course these standard issues were carefully examined since early on... Also my somewhat related galaxy code so far has performed pretty well...

But most importantly, before addressing all this "technology", one has to decide about the basic question:

++++++++++++++++++++++++++++++
What do we want to take as a reference for the modelling of central DSO brightness in Celestia?
++++++++++++++++++++++++++++++
The two main alternatives are:

a) We compare TWO "low dynamics" imaging devices, i.e the DSO rendering on a computer monitor with the rendering on a photograph. Both have STRONG (related) dynamical limitations, YET people are used to photographic imaging characteristics! That should perhaps NOT be ignored...

Practically ALL existing lower resolution photos of globulars are hopelessly overexposed i.e saturated in their centers compared to their visual appearance through a (small) telescope. Hence the apparent central brightness in photos is largely UNRELATED to the integrated magnitude of the cluster!

b) We try to model "somehow" the visual appearance. This is a largely subjective procedure, since precise data are lacking (both concerning efficiencies and a reduction of the globular appearance to visual level).

It was entirely unclear to me, which of these two alternatives you intended to approach by means of the "tuning" you proposed above ...

I had avoided making any decision about this--I was just concerned with the overlapping sprites problem that must be solved regardless of which alternative we choose.

The problematics of linear hardware blending in the context of central stacking of overlapping sprites is a general issue, and should equally have been discussed in the context of galaxies, binaries etc. So I don't quite understand why you did get into "teaching mode" NOW, even before you had a chance playing with my globular cluster code .

I know it's a problem throughout Celestia. I just wanted to share some ideas about how we might deal with it in the specific case of globular clusters. For a more general solution, I still think that the only satisfactory approach will be to use floating point frame buffers.

Since you are the local OpenGL expert, perhaps you know a method of blending that will be essentially compatible with all these theoretical constraints. Why don't you try writing down some more concrete blending code that respects all this?

It doesn't sound like my ideas were very helpful. Anyhow, if your globular cluster rendering works fine as-is, there's no need for me to pursue my proposed techniques further. I'll wait for the first version of your globular patch to see if some form of my hybrid rendering proposal might still be useful.

--Chris

[t00fri]

I think that there's a bug in this code--it doesn't seem like it will generate a spherically symmetric distribution of stars. Stars will tend to be concentrated near the poles of the cluster.

The method I used is a well-known one to generate a uniform distribution in polar coordinates on the surface of the unit sphere, say. Then this can be scaled with any radius r in which the distribution is a la King. I assure you that I checked the spherical symmetry explicitly as well.

See e.g.
http://mathworld.wolfram.com/SpherePointPicking.html

you will recognize eqs.(6,7,8). The point being that one MUST NOT dial spherical coordinates theta and phi from uniform distributions, to get a uniform distribution on the sphere...since the area element dOmega=sin(phi)d theta dphi is a function of phi, and hence points picked in this way will be "bunched" near the poles .

Fridger

[t00fri]

Chris,

amusingly, and in the context of our discussion, here are some of my old displays, where I used just a single "cloud sprite" to render the globulars. At that stage, the purpose was to check precisely the correctness of the mu25 isophote radius.




The luminosity distribution of that single "cloud sprite" was generated via a procedural texture the light of which was distributed a la King... The angluar diameters of the Moon and that of M4 are almost equal, so...

Fridger

[chris]

I think that there's a bug in this code--it doesn't seem like it will generate a spherically symmetric distribution of stars. Stars will tend to be concentrated near the poles of the cluster.

The method I used is a well-known one to generate a uniform distribution in polar coordinates on the surface of the unit sphere, say. Then this can be scaled with any radius r in which the distribution is a la King. I assure you that I checked the spherical symmetry explicitly as well.

See e.g.
http://mathworld.wolfram.com/SpherePointPicking.html

you will recognize eqs.(6,7,8). The point being that one MUST NOT dial spherical coordinates theta and phi from uniform distributions, to get a uniform distribution on the sphere...since the area element dOmega=sin(phi)d theta dphi is a function of phi, and hence points picked in this way will be "bunched" near the poles .

Yes--I misread the code. It is indeed fine as it is . . .

--Chris

[Cham]

I think that there's a bug in this code--it doesn't seem like it will generate a spherically symmetric distribution of stars. Stars will tend to be concentrated near the poles of the cluster.

The method I used is a well-known one to generate a uniform distribution in polar coordinates on the surface of the unit sphere, say. Then this can be scaled with any radius r in which the distribution is a la King. I assure you that I checked the spherical symmetry explicitly as well.

See e.g.
http://mathworld.wolfram.com/SpherePointPicking.html

you will recognize eqs.(6,7,8). The point being that one MUST NOT dial spherical coordinates theta and phi from uniform distributions, to get a uniform distribution on the sphere...since the area element dOmega=sin(phi)d theta dphi is a function of phi, and hence points picked in this way will be "bunched" near the poles .

Yes--I misread the code. It is indeed fine as it is . . .

--Chris

Fun ! That's exactly the code I was using for my own spherical globular models (CMOD point models), already discused there :

http://celestiaproject.net/forum/viewtopic.php ... ht=cluster