Galaxy colors etc.

[t00fri]

Hi Toti,

good to read your suggestions!

After getting the first "rough" round in this exciting project done, we all will have to sit down, working seriously on "culling" in order to find back to high fps rates!

That has high priority both from Chris' and my point of view. I wrote earlier that presently with my 10600+ galaxies loaded I drop from

>95 fps to ~ 25fps.

Loading the other 15000+ galaxies from the revised RC3 catalog, I get down to even < 10 fps!

In my view, a solid galaxy population of min =1000 and desirably=10000+ is really an important target. So we got to do something about it.

Then we can see how much playground would be left for incorporating such interesting ideas of yours above!
I would very much like to do so. At least we could experiment with your idea of a prescribed H- table a bit.

Right know the images I showed above were produced with an even simpler H-assignment:

Code: Select all

float h = b.colorIndex<80+10*Mathf::sfrand()?17.0f:243.0f;


directly in Galaxy::render(). No table used

The two (somewhat randomized) values just correspond to the core and periphery Hue.

As to the other point, I am desperately waiting on the screenshots from Chris illustrating his new shader for elliptical galaxies. He is really planning to let us travel inside his elliptical galaxies!

Since he is quite content with the result, I guess we should just wait on what he will soon come up with.

Cheers,
Bye Fridger

[Tosv]

t00fri wrote:

Hi Tosv,

The way modern catalogs do differentiate is by using a much finer
subdivision of the galaxy classification scheme than what we employ so
far in Celestia. We use the classical Hubble classification. With the
newer extended classiifications such differences could partially be
accounted for. Yet one would need an extra template image for each
eaxtended subclass....which seems to show inflationary tendencies Wink


So sticking to Hubble seems like the best compromise at present.

I see, very interesting. I??m looking forward to see what will happen in the future

[essee]

The good Doctor, it seems, is about to deliver himself of a whole new universe.

[Toti]

Hi Fridger,

After getting the first "rough" round in this exciting project done, we all will have to sit down, working seriously on "culling" in order to find back to high fps rates!

That has high priority both from Chris' and my point of view. I wrote earlier that presently with my 10600+ galaxies loaded I drop from

>95 fps to ~ 25fps.

Loading the other 15000+ galaxies from the revised RC3 catalog, I get down to even < 10 fps!

In my view, a solid galaxy population of min =1000 and desirably=10000+ is really an important target. So we got to do something about it.

Some quick thoughts about this:
IIRC galaxies aren't coupled to the octree; this means that the frustum culling phase is heavily overcharged: >10000*6 sphere-plane tests must be made for every frame. These tests are usually fast but by using spatial partitions the process can be done in a much more efficient way.
Also in my original patch I used a single static color table for all galaxy instances. In the current approach, since Value and Saturation are functions of the observer's distance to the body, the table must be recomputed before rendering every single object. But very distant galaxies (most common of them, usually) are composed of only a few grayish blobs: recomputing a whole 256 table for each one of these objects is a performance hit and not really useful. Ordering the (relatively few) galaxies that passed the frustum culling step from front to back could be beneficial: when distance is past certain far point, don't recompute the table anymore: use it as it is and (possibly) adjust brightness by direct alpha channel manipulation of the few yet-to-be-rendered blobs.

Right know the images I showed above were produced with an even simpler H-assignment:

Code: Select all

float h = b.colorIndex<80+10*Mathf::sfrand()?17.0f:243.0f;


directly in Galaxy::render(). No table used

Converting HSV -> RGB for each single blob is too expensive: 5000-8000 computations per galaxy per frame; all blobs share colors, so this is redundant aswell. By using the table we can reduce color operations to a more acceptable (256 or even less) per galaxy. It's not entirely satisfactory, though...

Bye

[t00fri]

Tanks Toti!

Actually, after my last post above (where I was in a hurry), I had also some afterthoughts towards the direction you mention. Since Chris knows all "good and bad tricks" of culling in an /OpenGL/ environment (and I don't), let's wait and see what he will propose. He is completely aware of the problematics. I am quite experienced with time-saving tricks in a non-graphical, general programming context, however.

Clearly, when using Hue instead of RGB we can get along with a MUCH SMALLER color table! Effectively, since we only have limited color inputs from catalogs, and since we want to stick to those (leaving out phantasy colorations I mean), 256 color values in the table represent a huge overkill.

Tonight I shall work a bit in this direction, trying to do some profiling for reduced Hue setups.

Bye Fridger

[t00fri]

Here is another neat little comparison around a galaxy cluster (around ngc 67 - ngc 69) with plenty of different types of small galaxies, including two S0 types for which I used the image as a test.

The Celestia output (top) (as compared to the Digital Sky Survey 2 photo (bottom)) corresponds to the latest version of my galaxy.cpp code, including simple HSV coloration as described above.

Despite his announcement a few days ago, Chris' code has not yet "arrived" ...I suppose the week-end weather was good in the Seattle area

Bye Fridger

[symaski62]

http://members.fortunecity.com/guilpain/Galaxie.htm

C:\Program Files\Celestia\data\deepsky.DSC

bye

[t00fri]

8)
http://members.fortunecity.com/guilpain/Galaxie.htm

C:\Program Files\Celestia\data\deepsky.DSC

bye

That "riddle" again I don't understand at all .

I for myself don't need instructions about the meaning of the parameters in the *.DSC file, since they are unambiguously defined in Celestia's source code...

Working out the necessary set of transformations for each galaxy in the catalog as a sequence of quaternionic actions takes a little bit of thinking, since the subtle conventions are not reliably written up.
They are more tedious to fiddle out from the code.
But the results are entirely straightforward to derive, which I did already several weeks ago.

Guilpain's drawing does not help very much for the really subtle issues, in fact.

Bye Fridger

[Fightspit]

8)
http://members.fortunecity.com/guilpain/Galaxie.htm

C:\Program Files\Celestia\data\deepsky.DSC

bye

That "riddle" again I don't understand at all .

Try here

Bye!

[t00fri]

8)
http://members.fortunecity.com/guilpain/Galaxie.htm

C:\Program Files\Celestia\data\deepsky.DSC

bye

That "riddle" again I don't understand at all .

Try here
Bye!

Why should I do that, this was my original question?

I actually speak fluently French (even carried a french passport a long time ago ) . So the english translation of Guilpain's site is also not needed.

I have explained above that all what may be found on that URL /and much more/, I can also directly read off the Celestia C++ source code. This is much more reliable, since all conventions correspond exactly to the ones used. In such issues involving subtle conventions of rotations etc., I usually only trust myself ...and the ORIGINAL!

Moreover, what I did not understand is that I have finished that task to which symaski62 was obviously alluding to, already weaks ago. Otherwise the successful comparisons of the galaxy orientations above and earlier would have been impossible.

Hence for me there is NO need to look at this site of Guilpain...NOW.

So why did symaski62 refer to it???

As stated repeatedly, I am VERY bad at such riddles and shall not react anymore to such posts, henceforth.

Bye Fridger

[Paolo]

Great Job Fridger
The screenshots are very beautiful.
The work on the HSV Colortable is very interesting.
I hope that at the end the final 1.4.0 will come soon and will include this code and your DSC file.

[symaski62]

http://www.lns.cornell.edu/~seb/celesti ... heets.html
M office V12 ou Open office 1.9.109m fichier.xls



bye

[t00fri]

http://www.lns.cornell.edu/~seb/celestia/hutchison/spreadsheets.html
M office V12 ou Open office 1.9.109m fichier.xls



bye

symaski62,

Grant's excel file is ok for aligning a photo to a mesh with a particular orientation. For galaxy catalogs, the somewhat nontrivial part is to rotate the galaxies by the inclination angle relative to "face-on" view and then to rotate them by the position angle "east of north" from the catalog. That part is only tricky, since one needs to know /precisely/ the definition (signs!) of the appropriate coordinate axes and angles that unfortunately are not too well documented.

The latter rotations are not contained in Grant's excel sheet. The rotations in Grant's excel sheet from the sky plane to the ecliptic plane are of course also needed, however in /inverse/ ordering. But why should I use Grant's EXCEL stuff for the straightforward part of the task? In Perl, there exists a Quaternion module, and to do all what is needed, requires just to multiply 3 quaternions together in the correct sequence.

Also EXCEL is TOTALLY unsuited for this task of preparing 10000-20000 (!) galaxies in *.dsc format from published catalog files. And it's clumsy and unelegant ;

Symaski62 , why do you keep sending me new irrelevant information about such things? Nothing is needed anymore. Or should I print out my respective Perl code to prove it?

MY TASK IS FINISHED since 2 weeks. My catalogs are finished and Chris and I use them already since a week to test out new galaxy code.
I did not yet publish them since we need to first finalize the code to use them and to implement some culling to make things faster;-) ...

Bye Fridger

[t00fri]

Perhaps I should add that at present there is a strong need for /precisely/ aligned and good quality galaxy templates for the 7 standard spiral Hubble types S0,Sa,Sb,Sc,SBa,SBb,SBc. These have been so far derived from nice face-on photographic images of real galaxies of the respective types.

Both Toti and I used some simple code he has written to vectorize the corresponding 128x128 *.bmp images. Unfortunately, Toti's code has it's "own will" and correspondingly the results are often NOT as desired...

Let me emphasize --notably also to symaski62 -- that any possible remaining inaccuracies with the apparent alignment of galaxies compared to DSS photos are due to some left-over alignment inaccuracies in the local "template frame"!

It seems that the commercial Adobe Illustrator has the best built-in features for vectorizing images. Unfortunately, I don't have that program. The result as we need it for a template are numerical data in a file e.g. S0.pts, consisting of the 4 columns

x, y, z, b = brightness; 0<b<=1

Any xyz-plot program (including Maple) can easily display the template galaxy points in form of a 3d set of points.

As to the elliptical galaxy templates , they will be directly generated in the Celestia code using Chris' new shader. I am looking forward to it.

Bye Fridger

[t00fri]

Hi all,

while waiting for Chris to complete his part of the galaxy coding (due since ~ 2 weeks), .....

I thought I might as well "entertain" some of you a bit by telling you about some research I did to get the distances of my 10000-25000 galaxies right. This is quite an art, as you will see below.

There are about 6 popular methods used professionally to determine the distances of galaxies:

a) Hubble's law, using the galaxy's recessional (radial) velocity v_rad:
-------------------------------------------------------------------

d ~ v_rad/H0, H0= 72 km/sec/Mpc (WMAP'05)

with H0 being today's value of the Hubble constant. It's accuracy has greatly increased since the famous WMAP results 2005 about the cosmic microwave background radiation. In a uniformly expanding universe, a galaxy with a larger velocity lies further from an observer than one with a smaller velocity. It is very easy to measure a galaxy's radial velocity with a spectroscope - hundreds of thousands of galaxy velocities have been measured.

Unfortunately galaxies also have smaller NON-radial velocity components, notably when they are part of HUGE clusters of galaxies (Virgo,...). Also one has to wonder in what system one best specifies the velocity. Heliocentric is most usual, galactic center is popular and best is the cosmic microwave background frame (CMB) that I also have adopted.

Moreover... there are also several blue-shifted galaxies, like Andromeda (M31), Triangulum (M33) and a few others. This means v_rad is NEGATIVE and thus clearly the Hubble distance law is inapplicable...

So for these cases of negative or too small v_rad, other distance methods are needed:

b) Surface Brightness Fluctuations (SBF)
------------------------------------------------
The further away a galaxy is, the smoother it looks on a photograph. This can be used to accurately measure the distance to the galaxy, although you need to subtract the contribution from the globular clusters around the galaxy which make a galaxy look less smooth. Large numbers of distances to other galaxies are being produced by this technique although it works best on elliptical and lenticular galaxies or on spiral galaxies with broad smooth central bulges.

The seminal papers about this method are by J. Tonry et al. (2001...)

Besides SBF, there are 4 more quantitative distance methods that I just list for completeness:

c) Globular Cluster Luminosity Function (GCLF)

d) Planetary Nebula Luminosity Function (PNLF)

e) Photometric Distances

f) Cepheid Distances
The latter is the oldest and most famous distance method
also pioneered by Edwin Hubble in 1922. The method uses Cepheid variable stars - yellow giant stars which pulsate. The luminosity of these stars is directly proportional to the pulsation periods...The rest should be obvious...

There is another most simple but more qualitative method that I have applied in cases of galaxies where neither v_rad nor the SBF method was applicable or available. It assumes that galaxies of a given Hubble type have to good approximation a very similar absolute magnitude

M_abs ~ -19 to -20.5. (empirically)

If true, one then can easily compute the distance from the difference of the (assumed universal) absolute magnitude and the measured apparent magnitude:

distance = 10**((Bmag - M_abs+5)/5)*3.26167 [ly]

where Bmag is the apparent blue-band magnitude of the galaxy.

In order to check for the accuracy of this method, I did the following: I used the accurately known SBF distances of hundreds of galaxies (cf above) and their measured Bmag values to solve for the corresponding absolute magnitude M_abs (assumed universal)!

So, how well does the above formula really hold??

Here is the result, as evaluated with the help of Maple for
elliptical and spiral galaxies, separately:



The absolute magnitude M_abs is displayed on the x-axis (abszissa)

What can we learn from this plot?

-- the distributions of M_abs are really quite peaked around some most probable value.

-- that peak value is systematically different for elliptical and spiral galaxies by about 1 unit.

-- last not least: that this sort of study is quite a bit of fun

So this was some "fairy-tale" about how I chose to determine the distances in my catalog with 25000+ galaxies...

Bye Fridger

[t00fri]

Hi all,
after fiddleing over the weekend with octrees, hunting bugs and plenty of email exchange with Toti...

Here is some dramatic speed improvement:

With 10632 galaxies from my catalog and the M65-66 region displayed, have a look at the fps rate at the bottom LEFT!



Bye Fridger

[danielj]

It should be good news,but the fact is you have a monster computer(Athlon FX-55,2 GB RAM and Geforce 6800 Ultra in SLI 2x256 MB) and very few people own this.So it??s better to consider a light version of this file...Me,for example,will have in 6 months,with luck,only a Athlon FX-51,1 GB RAM and Geforce 6600 GT single...

Hi all,
after fiddleing over the weekend with octrees, hunting bugs and plenty of email exchange with Toti...

Here is some dramatic speed improvement:

With 10632 galaxies from my catalog and the M65-66 region displayed, have a look at the fps rate at the bottom LEFT!



Bye Fridger

[t00fri]

It should be good news,but the fact is you have a monster computer(Athlon FX-55,2 GB RAM and Geforce 6800 Ultra in SLI 2x256 MB) and very few people own this.So it??s better to consider a light version of this file...Me,for example,will have in 6 months,with luck,only a Athlon FX-51,1 GB RAM and Geforce 6600 GT single...

Daniel,

first of all, I have a completely different computer setup from what you wrote:

INTEL CPU 3.2 GHz, 3GB RAM and an oooooold NVIDIA 5900FX Ultra mit 256 MB DDR Ram. Nowadays this is certainly NOT a monster computer. 3.0 GHz CPU's are getting really cheep. So is memory.

Last not least your GeForce 6600GT will be presumably faster than my card.

And finally, with one command in my Perl script, I can cut down the size of my galaxy *.dsc file to 10%,say, by just imposing a brightness cut. The official distribution will certainly only contain a reduced size galaxy file.

Nevertheless, I suppose you understand that Celestia's developers also have other "visions" but your specific computer layout

Bye Fridger

[ElChristou]

Hi,

What about releasing dsc by "level"? the first 5000, another + 5000, a third + 5000 etc... as it users can choose their level of complexity... (can be done also with stars...)

Bye

[t00fri]

Hi,

What about releasing dsc by "level"? the first 5000, another + 5000, a third + 5000 etc... as it users can choose their level of complexity... (can be done also with stars...)

Bye

But there needs to be a sensible physical criterion of how the sets of 5000 are selected! Usually one takes appropriate brightness windows:

e.g. Vmag (or Bmag) <12
12 < Vmag < 15
15 < Vmag

For Perl this is just one command.

But we are far from releasing the set, since Chris again seems to be much more active in climbing mountains than in coding galaxies....

It makes little sense to release the catalog, as long as we are not definite about which parameters we shall eventually need for a complete and automatic shape and color characterization of all galaxies. Of course interested people can always download everything (catalogs, Perl script and final catalog) on demand -> PM/email. Chris and Toti have it, for example.

Toti and I have set up a rather definite coding program that we are both following as much as time allows. The above fps increase is a result from that joint effort.

Bye Fridger