Drawing a better star

[chris]

Anyway, you did not reply to the main part of my above question: How can we use that star shader code (or improvements thereoff) for Celestia or Celestia.Sci, given that tacitly it was copyrighted by ASTOS solutions long ago??

I don't know. I thought it was different enough. I can talk to ASTOS about it. It's probably safest to completely rewrite it, though I don't have time to do this myself.

The linearToSrgb transformation can be omitted to save time. Then, the star rendering would only work correctly on hardware that supports the EXT_framebuffer_sRGB extension, but that's most hardware now.

--Chris

[t00fri]

Anyway, you did not reply to the main part of my above question: How can we use that star shader code (or improvements thereoff) for Celestia or Celestia.Sci, given that tacitly it was copyrighted by ASTOS solutions long ago??

...It's probably safest if we don't use it, I suppose.

--Chris

Well that's presumably why nothing happened at the Celestia front for many months with respect to "Drawing a better star"... At least, the answer to Andrew's above question.

So any progress on getting this finished into the main code for 1.7?

should now be evident.

As emphasized, I am using an improved version of the star shaders for Celestia.Sci that is really different analytically. Still the linearToSRGB is the same as VESTA (so far).

Incidentally, I did some benchmarks with your patch/VESTA shaders and found that with my older graphics cards at least (GeForce 7950 GT, ..., shader model 3.0), it slows down the fps quite dramatically compared e.g. to the "scaled disk" star style. Did you also notice this?

I wonder why you used a vertex array scenario instead of VBO based rendering? Also VESTA uses vertex arrays for star rendering only if VBOs are unavailable.

With the same graphics cards of mine, your Cosmographia rendering is extremely smooth! Probably related to VBO technology? Is there a (hidden) fps display key in CG??

Fridger

[chris]

Incidentally, I did some benchmarks with your patch/VESTA shaders and found that with my older graphics cards at least (GeForce 7950 GT, ..., shader model 3.0), it slows down the fps quite dramatically compared e.g. to the "scaled disk" star style. Did you also notice this?

I haven't benchmarked the star shaders since I generated the results earlier in this thread. Some slowdown is to be expected based on increased pixel shader load. This will be most evident when:
- The limiting magnitude is set very high, resulting in stars with large glare haloes
- Running on older graphics cards, which were released at a time when there were few complex pixel shaders, and thus are less balanced for shader computation power

(I created an OpenGL ES version of the star shader for iOS, and it performs very well on my iPhone 4.)

I wonder why you used a vertex array scenario instead of VBO based rendering? Also VESTA uses vertex arrays for star rendering only if VBOs are unavailable.

For anyone reading that's unfamiliar with the terminology:
- A vertex array is an area of CPU-accesible memory filled with vertexes
- A VBO (vertex buffer object) is a block of memory filled with vertices that may be placed in either CPU or GPU memory, depending on the usage performance. For optimal performance, you want your vertex data to stay in GPU memory.

I never got around to changing Celestia to use VBOs for star rendering. VESTA renders stars in a very straightforward way: the entire catalog is stored in a single static VBO and dumped to the hardware with a single draw call. There's no attempt to cull stars that aren't visible because they're either outside the view frustum or too faint. This approach actually works very well for few tens of thousands of stars, but it obviously doesn't scale well. By contrast, Celestia uses an octree culling scheme and does a significant amount of processing work for each star while filling a vertex array in system (i.e. not video) memory. It's thus slightly more complicated to get a performance boost from VBOs in Celestia.

The star rendering code in Celestia hasn't fundamentally changed in probably eight years. There are big opportunities to optimize it to take care of the programmable graphics pipeline that is ubiquitous on today's GPUs. However, I'm not sure that it's worth the effort until much larger star catalogs are available. With the standard ~100K catalog, even Celestia's current, relatively inefficient star rendering code gets stars onto the screen very quickly. There are more serious performance problems elsewhere.

With the same graphics cards of mine, your Cosmographia rendering is extremely smooth! Probably related to VBO technology? Is there a (hidden) fps display key in CG??

I suspect that Celestia is actually faster. Part of the apparent smoothness of Cosmographia is due to the inertia used when rotating the view with the mouse--something that we really should add to Celestia. (There's some profiling code in UniverseView.cpp that's currently #ifdef'd out; I'll add a keyboard toggle soon.)

--Chris

[t00fri]

Quite soon, I'll be able to offer benchmark comparisons of BOTH a vertex array and a VBO rendering of Celestia.Sci stars. What is particularly interesting in this context is that the stars of all 157 galactic globular clusters are also rendered now with the same shaders (and buffer class) as the normal stars, including the same lookup tables Color(...) = function (Teff).

The interesting aspect in relation to your previous remarks about VBOs in Celestia, is that unlike the normal stars, the globular stars are not culled via an octree mechanism.
Each globular consists of ~ 16k stars that are just organized e.g. in a vertex array for rendering with the shaders. The most important culling here is actually via

if (appMag > faintestMag)
return;
after the generated cluster stars have been sorted in absolute magnitude , initially.
It's a "one branch" octree if you like

Since realistically, my entirely new cluster code involves also lots of dim stars (with appMag>20), the limiting magnitude had indeed to be pushed up significantly, leading to big-sized glaring bright stars, of course. But in case of the "scaled disk" style, the star sizes are about equally big, yet the performance with the latter is much better. So the glare part must be the culprit. I'll try to improve the glare shader code in this respect.

Anyway, I'll do some quantitive comparisons between VBO related performance boosts for octree-culled and non-octree based stars.. While everything is practically ready for such tests, I first want to finish off a major chunk of work on a number of piecewise spline interpolations for various lookup tables of realistic CMDs (Color-Magnitude-Diagrams) relating MV and V-I color for the cluster star generation.

Fridger

[t00fri]

Chris,

here is an illustration of the new 'unified' star shading challenge in Celestia.Sci in an interplay of extremely dim cluster stars (with m>20) with much brighter big-sized glaring stars (m = 7-8 ) in the neighborhood.

[Click on image by all means]

n2419_celSci.jpg

The dim globular NGC 2419 has an integrated m = 10.2, only.

For comparison, I add the corresponding NGC 2419 image, I have read out from the DR7 SDSS database (It uses a different color profile from mine here).
Note analogously the big size of the bright stars in relation to the faint cluster stars.

ngc2419_SDSS.jpg

Fridger

[chris]

Since realistically, my entirely new cluster code involves also lots of dim stars (with appMag>20), the limiting magnitude had indeed to be pushed up significantly, leading to big-sized glaring bright stars, of course. But in case of the "scaled disk" style, the star sizes are about equally big, yet the performance with the latter is much better. So the glare part must be the culprit. I'll try to improve the glare shader code in this respect.

Bright stars rendered using the scaled disk style will always be faster, for two reasons:

1. The number of pixels drawn for a bright star is much greater for the shader stars. A convincing looking glare effect will fill a large radius with dim pixels. While the central part of a shader star may be roughly the same size as a scaled disk star, the glare halo will be much bigger.

2. The per-pixel calculation for the scaled disk star is dead simple: a color is fetched from the star texture and multiplied by the star color. Even with heavy optimization, there's no way the pixel shader for the shader stars will get this simple.

Quite simply, a larger number of more compute intensive pixels.

--Chris

[chris]

[Click on image by all means]

n2419_celSci.jpg

The dim globular NGC 2419 has an integrated m = 10.2, only.

Very nice! It looks quite like the 'grains of sugar on a black table' impression of globulars seen through a telescope.

--Chris

[PlutonianEmpire]

The star rendering code in Celestia hasn't fundamentally changed in probably eight years. There are big opportunities to optimize it to take care of the programmable graphics pipeline that is ubiquitous on today's GPUs. However, I'm not sure that it's worth the effort until much larger star catalogs are available. With the standard ~100K catalog, even Celestia's current, relatively inefficient star rendering code gets stars onto the screen very quickly. There are more serious performance problems elsewhere.

How about trying it with the 2 million stars database? Would that work?

[t00fri]

[Click on image by all means]

n2419_celSci.jpg

The dim globular NGC 2419 has an integrated m = 10.2, only.

Very nice! It looks quite like the 'grains of sugar on a black table' impression of globulars seen through a telescope.

--Chris

Very adequate description. This far improved globular rendering came with using the same shaders as for normal stars. For the globular stars with non-extreme zoom, the new rendering is VERY fast (which is understandable of course).

Here is the appearance of NGC 2419 upon closing in

[ click on images by all means]

n2419_close.jpg

n2419_very_close.jpg

Background Info:
---------------------
All color distributions are in close agreement with observations, via the 'chain':

• input of measured luminosity function dNstars / dM_V (M_V), from which cluster stars with realistic M_V distribution are generated.
• M_V => (measured CMD) => V-I color,
• accounting of reddening E(V-I) and metallicity effects in V-I (M_V) CMD
• V-I => T_eff (V-I) relation and finally,
• Celestia's starColor = function(T_eff) is used
  for each individual cluster star (switchable, e.g. BlackBody).
• highly efficient organization of corresponding code
  

Horizontal branch, RedGiants, Metallicity [Fe/H] and reddening effects are all included in the clusters' HR diagrams. Only the invisible white dwarfs are neglected. It is planned that users can plot the various realistic distributions for each cluster as overlays.

Fridger

[Nibla]

I downloaded an .exe file that made stars looking better. It worked and looked pretty nice, but it looks strange when the stars are too bright. Any idea of how to get rid of that?

[abramson]

I downloaded an .exe file that made stars looking better. It worked and looked pretty nice, but it looks strange when the stars are too bright. Any idea of how to get rid of that?

Hi, Nibla. You probably downloaded my .exe.

I haven't seen this effect before. It's a pity. It's most probably a bug in the "new star" render. Unfortunately Chris never finished it, and now he is no longer committed to Celestia. So it will stay as it is until some other graphics guru codes a beter render path.

My only remotely useful suggestion is to update your graphic card drivers.

Guillermo

[Nibla]

I downloaded an .exe file that made stars looking better. It worked and looked pretty nice, but it looks strange when the stars are too bright. Any idea of how to get rid of that?

Hi, Nibla. You probably downloaded my .exe.

I haven't seen this effect before. It's a pity. It's most probably a bug in the "new star" render. Unfortunately Chris never finished it, and now he is no longer committed to Celestia. So it will stay as it is until some other graphics guru codes a beter render path.

My only remotely useful suggestion is to update your graphic card drivers.

Guillermo

Yes, it is your .exe file I am using. Very nice job making it!

I have the latest updates for my graphic card drivers, but the problem is still there. On my other computer (Windows XP) the problem does not occur.

Nibla

it is very advisable that you get the driver form the hardware manufactures web site

Microsoft removes a lot of "openGL" code from the crippled version they redistribute through "auto update"

And will be happy to remove a working driver and replace it with there crippled version .
And "for your convenience" not tell you they are doing it .
it might even be listed in auto updates as a "security fix"

I have visited Nvidia's website and downloaded the latest updates. My graphic card is GeForce GTX 560 Ti by the way. Running on Windows 7 64-bit.

[t00fri]

Several years ago when ChrisL sent me the first version of his shader star patch, I noted already the above square artefacts in my Win 7/64 bit machine and told him about them. The bright shader stars consist of a core and a glare part, both rendered within a standard square region. If for some reason the sum of intensities does not vanish towards the boundaries of the square, the above artefacts arise.

Meanwhile I wrote my own improved C++ code and shaders for star rendering in celestia.Sci which does not have this artefact problem. Since Celestia development has come to an end since quite a while, I have not taken the time to fiddle with Chris' patch for removing these artefacts.

Fridger

[Alexell]

According to the materials of this topic, I was able to realize the effect created by Chris.

Is it worth it to engage in improvement?

[John Van Vliet]

normally i would want to remove the errors added in by the secondary mirror supports

they are a pain in the rear end

[Fenerit]

normally i would want to remove the errors added in by the secondary mirror supports

they are a pain in the rear end

Indeed usually AAP do add spikes to their astroimages via software... Spikes serves like references for stacking lots of long exposure shots of the target, even when it is imaged the day after, until the final output is achieved.

[Alexell]

Who has the necessary knowledge to modify this function?

Added after 1 minute 31 seconds:
https://github.com/CelestiaProject/Celestia/issues/2

Added after 7 minutes 17 seconds:
One more screenshot:

[prashant121]

And just for fun, diffraction spikes should be an option in the next version of Celestia

[selden]

Such documentation as there is is within Celestia's source code, which is available on SourceForge or GitHub. That source code is what would have to be modified to include additional Star drawing methods. See, for example, https://sourceforge.net/projects/celestia/files/Celestia-source/

In particular, see the source code files render.h and render.cpp in the directory https://sourceforge.net/p/celestia/code/HEAD/tree/trunk/celestia/src/celengine/

[mmontag]

Is anyone currently working on this? I would love to contribute to Celestia and maybe hack on this as my first entry into the void. I will be looking around the forum to try to figure out what the current state of the project is, whether Chris is still involved, etc. Is the github repository now the canonical source?