Drawing a better star

Description: Discussion forum for Celestia developers; topics may only be started by members of the developers group, but anyone can post replies.

chris
Topic author, Site Admin
chris
Topic author, Site Admin
Posts: 4217
With us: 15 years 3 months
Location: Seattle, Washington, USA

Re: Drawing a better star

#61by chris » 17.11.2011, 20:34

t00fri wrote: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
Avatar
t00fri
Age: 15
Posts: 8800
With us: 15 years 1 month
Location: Hamburg, Germany

Re: Drawing a better star

#62by t00fri » 17.11.2011, 21:05

chris wrote:
t00fri wrote: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
Image

chris
Topic author, Site Admin
chris
Topic author, Site Admin
Posts: 4217
With us: 15 years 3 months
Location: Seattle, Washington, USA

Re: Drawing a better star

#63by chris » 18.11.2011, 18:51

t00fri wrote: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.)

t00fri wrote: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.

t00fri wrote: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
Avatar
t00fri
Age: 15
Posts: 8800
With us: 15 years 1 month
Location: Hamburg, Germany

Re: Drawing a better star

#64by t00fri » 18.11.2011, 21:49

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
Image

t00fri
Avatar
t00fri
Age: 15
Posts: 8800
With us: 15 years 1 month
Location: Hamburg, Germany

Re: Drawing a better star

#65by t00fri » 18.11.2011, 22:55

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
Image

chris
Topic author, Site Admin
chris
Topic author, Site Admin
Posts: 4217
With us: 15 years 3 months
Location: Seattle, Washington, USA

Re: Drawing a better star

#66by chris » 19.11.2011, 00:12

t00fri wrote: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
Topic author, Site Admin
chris
Topic author, Site Admin
Posts: 4217
With us: 15 years 3 months
Location: Seattle, Washington, USA

Re: Drawing a better star

#67by chris » 19.11.2011, 00:14

t00fri wrote:[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 M
Avatar
PlutonianEmpire M
Age: 32
Posts: 1351
With us: 12 years 8 months
Location: MinneSNOWta

Re: Drawing a better star

#68by PlutonianEmpire » 19.11.2011, 01:05

chris wrote: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?
Terraformed Pluto: Now with New Horizons maps! :D

t00fri
Avatar
t00fri
Age: 15
Posts: 8800
With us: 15 years 1 month
Location: Hamburg, Germany

Re: Drawing a better star

#69by t00fri » 19.11.2011, 11:00

chris wrote:
t00fri wrote:[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
Image

Nibla
Nibla
Posts: 5
With us: 4 years 3 months
Location: Europa

Re: Drawing a better star

#70by Nibla » 03.02.2013, 16:55

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?

Image
^_^

abramson
abramson
Posts: 402
With us: 13 years 10 months
Location: Bariloche, Argentina

Re: Drawing a better star

#71by abramson » 03.02.2013, 19:49

Nibla wrote: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
Nibla
Posts: 5
With us: 4 years 3 months
Location: Europa

Re: Drawing a better star

#72by Nibla » 04.02.2013, 12:22

abramson wrote:
Nibla wrote: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! :wink:

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.
john Van Vliet wrote: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
Avatar
t00fri
Age: 15
Posts: 8800
With us: 15 years 1 month
Location: Hamburg, Germany

Re: Drawing a better star

#73by t00fri » 04.02.2013, 14:46

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
Image

Alexell M
Site Admin
Avatar
Alexell M
Site Admin
Age: 23
Posts: 206
With us: 6 years 7 months
Location: Moscow, Russia
ICQ Facebook Skype Twitter

#74by Alexell » 02.02.2017, 11:54

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


Is it worth it to engage in improvement?
Admin of celestiaproject.net.
PC: Lenovo IdeaPad Z570. Intel Core i5-2450M CPU @ 2.50GHz, 8 ГБ ОЗУ, NVIDIA GeForce GT 540M, Windows 7 Ultimate x64.
Phone: iPhone 5S 16 Gb. iOS 10.
Image

John Van Vliet
Avatar
John Van Vliet
Posts: 2589
With us: 14 years 8 months

#75by John Van Vliet » 02.02.2017, 23:52

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

they are a pain in the rear end

Fenerit M
Avatar
Fenerit M
Posts: 1864
With us: 10 years 1 month
Location: Thyrrenian sea

#76by Fenerit » 03.02.2017, 00:31

John Van Vliet wrote:normally i would want to remove the errors added in by the secondary mirror supports

they are a pain in the rear end
:smile:

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.
Never at rest.
Massimo

Alexell M
Site Admin
Avatar
Alexell M
Site Admin
Age: 23
Posts: 206
With us: 6 years 7 months
Location: Moscow, Russia
ICQ Facebook Skype Twitter

#77by Alexell » 04.03.2017, 14:38

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:
Screenshot_1.png
Admin of celestiaproject.net.
PC: Lenovo IdeaPad Z570. Intel Core i5-2450M CPU @ 2.50GHz, 8 ГБ ОЗУ, NVIDIA GeForce GT 540M, Windows 7 Ultimate x64.
Phone: iPhone 5S 16 Gb. iOS 10.
Image


Return to “Ideas & News”

Who is online (over the past 5 minutes)

Users browsing this forum: 1 guest