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.

CAP-Team
CAP-Team
Age: 42
Posts: 195
With us: 10 years 6 months
Location: Vriezenveen, the Netherlands
ICQ

Re: Drawing a better star

#21by CAP-Team » 02.08.2010, 18:01

I really like the new way of drawing stars. Is this going to be an extra option for CTRL+S or will it replace the older methods?

Any chance this wil hit SVN soon? ;)
Windows 7 Ultimate x64, Intel Core i7 2600K 3.4 Ghz, 4 GB RAM, 120 GB SSD + 1 TB hdd, nVidia GTX460 1 GB, Celestia 1.6.0.xxxx
Download my latest SVN Build

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

Re: Drawing a better star

#22by chris » 06.08.2010, 17:30

CAP-Team wrote:I really like the new way of drawing stars. Is this going to be an extra option for CTRL+S or will it replace the older methods?

I'd like it to replace the older methods on capable hardware. After using this new star rendering technique, none of the old methods seem adequate.

Any chance this wil hit SVN soon? ;)

It's not ready for SVN, but I do have a patch ready for testing. PM if your interested (and are building Celestia from the SVN source.)

--Chris

Guckytos
Guckytos
Posts: 550
With us: 13 years 1 month
Location: Germany

Re: Drawing a better star

#23by Guckytos » 07.08.2010, 07:11

chris wrote:
CAP-Team wrote:I really like the new way of drawing stars. Is this going to be an extra option for CTRL+S or will it replace the older methods?

I'd like it to replace the older methods on capable hardware. After using this new star rendering technique, none of the old methods seem adequate.

--Chris

Chris,

what is "capable hardware" in this case? Can you give a minimum graphics chip generation? And how would it impact on the FPS of this minimum?

Regards,

Guckytos

CAP-Team
CAP-Team
Age: 42
Posts: 195
With us: 10 years 6 months
Location: Vriezenveen, the Netherlands
ICQ

Re: Drawing a better star

#24by CAP-Team » 07.08.2010, 08:10

Chris, in the pictures above, do you use the standard star database or some other database?
Windows 7 Ultimate x64, Intel Core i7 2600K 3.4 Ghz, 4 GB RAM, 120 GB SSD + 1 TB hdd, nVidia GTX460 1 GB, Celestia 1.6.0.xxxx
Download my latest SVN Build

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

Re: Drawing a better star

#25by chris » 07.08.2010, 16:11

CAP-Team wrote:Chris, in the pictures above, do you use the standard star database or some other database?

It's the Tycho 2 catalog down to magnitude 10--about a million stars, versus the 100,000 or so in the standard Celestia catalog.

--Chris

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

Re: Drawing a better star

#26by chris » 07.08.2010, 16:30

Guckytos wrote:
chris wrote:
CAP-Team wrote:I really like the new way of drawing stars. Is this going to be an extra option for CTRL+S or will it replace the older methods?

I'd like it to replace the older methods on capable hardware. After using this new star rendering technique, none of the old methods seem adequate.

--Chris

Chris,

what is "capable hardware" in this case? Can you give a minimum graphics chip generation? And how would it impact on the FPS of this minimum?


Any NVIDIA card from the GeForce FX on will work. ATI Radeon cards will work as long as they are from the X1xxx series or later (anything 2005 or later should be OK.) The new stars should actually be faster, since more work gets pushed onto the GPU. In fact, with some modifications to the octree processing, the new star code could be quite a bit faster. The amount of CPU work could be reduced to a bare minimum; I recall that when I last profiled the star code, a significant amount of time was spent computing apparent magnitudes for stars. This step could be eliminated altogether if the star octree traversal and shader were written to work with absolute luminosities instead of magnitudes.

--Chris

CAP-Team
CAP-Team
Age: 42
Posts: 195
With us: 10 years 6 months
Location: Vriezenveen, the Netherlands
ICQ

Re: Drawing a better star

#27by CAP-Team » 08.08.2010, 19:28

A disadvantage of this new star rendering is that it's perfect as long as you don't travel between stars.

If you select a star and then go to it, it brightens twice. First you approach the glare and when that's full screen, you approach the star it self.
But I guess it's hard to find a decent way to transit from a big glare to the star itself.
Windows 7 Ultimate x64, Intel Core i7 2600K 3.4 Ghz, 4 GB RAM, 120 GB SSD + 1 TB hdd, nVidia GTX460 1 GB, Celestia 1.6.0.xxxx
Download my latest SVN Build

Boux
Boux
Posts: 439
With us: 12 years 10 months
Location: Brittany, close to the Ocean

Re: Drawing a better star

#28by Boux » 11.08.2010, 12:39

I have been playing with Chris's code (big thanks for sharing!).
The new star rendering is very nice and can be gorgeous with some tweaking.
First, I have got rid of the 1 Ly solar system size limit so that the transition between shader and mesh rendering is smooth.
Then I have been playing with the variables and I found that brightnessBias is the most controllable.
The screenshots below - /!\ big pics! - are made with brightnessBias set to 0.5, 0.7 and 0.8

EDIT Aug 12 --> brightnessBias back to (0.0f)

The first shot simulates a bare-eyes sight from someone's backyard:
Image

The second shot simulates the same scene as seen through hypothetic binoculars:
Image

Now, let's try with a digital camera on some sort of equatorial stand with a few minutes long exposure time:
Image

Next, this small telescope that we just found at the nearby pawn shop will allow us to do some zooming in:
Image

How about fitting a ccd sensor to our telescope?
Image

OK, enough experimentation for the time being and let's go for more eye candy with our pocket Hubble toy:

Galactic center
Image

Carina
Image

Andromeda
Image

Southern Cross
Image

Now I am going to tweak some more variables :D
Last edited by Boux on 12.08.2010, 09:18, edited 1 time in total.
Intel core i7 3770 Ivy Bridge @ 4.4 GHz -16 GB ram - 128 GB SSD cache - AMD Radeon 7970 3 GB o'clocked - Windows 7 64 Ultimate / Linux Kubuntu

Boux
Boux
Posts: 439
With us: 12 years 10 months
Location: Brittany, close to the Ocean

Re: Drawing a better star

#29by Boux » 11.08.2010, 15:50

As a reference to t00fri's post re alpha cent picture...
Some not so bad shots...
Celestia's sensor is doing pretty well and does not leak light :wink:
Done with brightnessBias(0.65f)
EDIT Aug 12 --> brightnessBias back to (0.0f)
What is weird is that there are more visible differences between fuzzy points and point rendering on my (big) display than on the smallish cropped screen captures.

Fuzzy points:
Image

Points:
Image

Scaled discs:
Image

Scaled discs with a tad more glare effect would be very close. Will check that.
BTW, we need more stars in Celestia!
 
Last edited by Boux on 12.08.2010, 09:19, edited 1 time in total.
Intel core i7 3770 Ivy Bridge @ 4.4 GHz -16 GB ram - 128 GB SSD cache - AMD Radeon 7970 3 GB o'clocked - Windows 7 64 Ultimate / Linux Kubuntu

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

Re: Drawing a better star

#30by chris » 11.08.2010, 16:10

Boux wrote:I have been playing with Chris's code (big thanks for sharing!).
The new star rendering is very nice and can be gorgeous with some tweaking.
First, I have got rid of the 1 Ly solar system size limit so that the transition between shader and mesh rendering is smooth.
Then I have been playing with the variables and I found that brightnessBias is the most controllable.
The screenshots below - /!\ big pics! - are made with brightnessBias set to 0.5, 0.7 and 0.8

The new star rendering is only enabled when point stars mode is selected. The brightnessBias setting will only affect the old star rendering. The adjustable parameters for the new star rendering are the limiting magnitude (adjusted with the square bracket keys) and the various settings in the renderShaderStars method. The three variables that control how star brightness are mapped to pixel values are the limiting magnitude, saturation magnitude, and the just visible pixel value. Here are the values from the code:

Code: Select all

// Saturation magnitude is the magnitude at which a star centered on a pixel                                                                               
// will have the maximum pixel value.                                       
float saturationMag = faintestMag - 4.5f;

// Minimum pixel value (wihout gamma correction) that is visible; this will vary                                                                           
// based on display device and viewing conditions                                                                             
float justVisiblePixelValue = 1.0f / 300.0f;


Roughly speaking, stars with an apparent magnitude equal to the limiting magnitude will have a pixel value equal to the just visible value, and stars at the saturation magnitude will have a pixel value of 1.0. Gamma correction and that the stars are Gaussians rather than points complicates things slightly, but this should give an idea of the physical meaning of the parameters.

One thing missing from your screenshot is a background of faint stars. By adjusting the brightnessBias to a very high value, every star appears bright. For realistic images, there should be a rich field of faint stars in the image.

--Chris

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

Re: Drawing a better star

#31by chris » 11.08.2010, 16:45

In this image, the limiting magnitude is adjusted so that magnitude 10 stars are just visible.

Boux
Boux
Posts: 439
With us: 12 years 10 months
Location: Brittany, close to the Ocean

Re: Drawing a better star

#32by Boux » 12.08.2010, 09:10

Chris,
I must be dumb or very tired or both :?
I messed up two directories with screenshot sets from various tests.
I have uploaded again all the images for my 2 previous posts.
Look at the new series from bare eyes to zooms into the galactic plane.
Limiting magnitude at work.
What was I thinking???
Intel core i7 3770 Ivy Bridge @ 4.4 GHz -16 GB ram - 128 GB SSD cache - AMD Radeon 7970 3 GB o'clocked - Windows 7 64 Ultimate / Linux Kubuntu

t00fri
Avatar
t00fri
Age: 15
Posts: 8800
With us: 15 years 3 months
Location: Hamburg, Germany

Re: Drawing a better star

#33by t00fri » 12.08.2010, 09:40

Chris,

in the context of our Qt discussion, I compiled SVN 5043 with your new star patch, which worked fine.
However, with my laptop (the graphics card of which does not support the EXT_framebuffer_sRGB extension as you know), I observe a rather dramatic decrease in performance (star style = Point):

SVN 5043, Qt 4.6.3: ..............................55 fps for startup screen
SVN 5043 + your star patch, Qt 4.6.3: 32 fps for same startup screen

or worse, centering on Alfa Crux with, automag=OFF and lim.mag ( ] ) = 12

SVN 5043, Qt 4.6.3:................................44.2 fps
SVN 5043 + your star patch, Qt 4.6.3: 22.0 fps! i.e. 50%

How is the analogous situation with a card supporting EXT_framebuffer_sRGB ?
Anyway, it seems some further speed-tuning might be necessary.

Fridger

PS: I'll check myself later today via VNC with my office machine with EXT_framebuffer_sRGB support and Linux.
Image

Boux
Boux
Posts: 439
With us: 12 years 10 months
Location: Brittany, close to the Ocean

Re: Drawing a better star

#34by Boux » 12.08.2010, 12:55

For what it's worth, here is what I am finding here:
- Qt4 build 5043, EXT_framebuffer_sRGB extension supported

Without patch:
- Start-up screen, automag on --> 149 fps
- Center on alpha Crux, automag on --> 193 fps
- Center on alpha Crux, automag off, limitig magnitude 12 --> 150 fps

With patch:
- Start-up screen, automag on --> 150 fps
- Center on alpha Crux, automag on --> 195 fps
- Center on alpha Crux, automag off, limitig magnitude 12 --> 153 fps

No significant loss or gain of performance.
I did the test several times and the results are pretty steady.
Looks like the EXT_framebuffer_sRGB extension is doing its job.
Intel core i7 3770 Ivy Bridge @ 4.4 GHz -16 GB ram - 128 GB SSD cache - AMD Radeon 7970 3 GB o'clocked - Windows 7 64 Ultimate / Linux Kubuntu

t00fri
Avatar
t00fri
Age: 15
Posts: 8800
With us: 15 years 3 months
Location: Hamburg, Germany

Re: Drawing a better star

#35by t00fri » 12.08.2010, 14:27

Boux wrote:For what it's worth, here is what I am finding here:
- Qt4 build 5043, EXT_framebuffer_sRGB extension supported

Without patch:
- Start-up screen, automag on --> 149 fps
- Center on alpha Crux, automag on --> 193 fps
- Center on alpha Crux, automag off, limitig magnitude 12 --> 150 fps

With patch:
- Start-up screen, automag on --> 150 fps
- Center on alpha Crux, automag on --> 195 fps
- Center on alpha Crux, automag off, limitig magnitude 12 --> 153 fps

No significant loss or gain of performance.
I did the test several times and the results are pretty steady.
Looks like the EXT_framebuffer_sRGB extension is doing its job.


Boux,

thanks a lot, that's useful. So everyone better buy a new card ;-)

Fridger
Image

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

Re: Drawing a better star

#36by chris » 12.08.2010, 14:36

t00fri wrote:Chris,

in the context of our Qt discussion, I compiled SVN 5043 with your new star patch, which worked fine.
However, with my laptop (the graphics card of which does not support the EXT_framebuffer_sRGB extension as you know), I observe a rather dramatic decrease in performance (star style = Point):

SVN 5043, Qt 4.6.3: ..............................55 fps for startup screen
SVN 5043 + your star patch, Qt 4.6.3: 32 fps for same startup screen

or worse, centering on Alfa Crux with, automag=OFF and lim.mag ( ] ) = 12

SVN 5043, Qt 4.6.3:................................44.2 fps
SVN 5043 + your star patch, Qt 4.6.3: 22.0 fps! i.e. 50%

How is the analogous situation with a card supporting EXT_framebuffer_sRGB ?
Anyway, it seems some further speed-tuning might be necessary.

No doubt further speed tuning would be helpful. Here are the results I get on my MacBook with an NVIDIA GeForce GT 330M. I'm benchmarking full screen (1680x1050) with 4x AA. The field of view is 47 degrees and the observer is positioned in interstellar space at a point 9 light years from the Sun:

cel://Follow/Sol:Earth/2010-08-12T13:40 ... rc=0&ver=3

No Solar System objects are in view because I'm trying to isolate performance differences due to star rendering.

Code: Select all

Limiting mag    New stars        Fuzzy points       Scaled discs
10.0               370                    342                   335
12.0               284                    342                   304


The new star code is faster than the old code when the limiting magnitude is 10, but significantly slower when the limiting magnitude is modified to 12. Meanwhile, the frame rate doesn't change at all with fuzzy points mode, and the performance drop with scaled discs is more modest. One variable we can eliminate immediately is the number of stars: the HIPPARCOS catalog doesn't have a significant number of stars below magnitude 10, so increasing the limiting magnitude to 12 won't result in an more stars being drawn.

In fuzzy points mode the size of the stars on screen is fixed; with new stars and scaled discs, the size increases with brightness. While the width of the Gaussian increases only very slowly, the glare halo can get very large with the new stars. Quite simply, the new star code draws a lot more pixels at limiting magnitude 12, consuming both additional pixel shader cycles and graphics memory bandwidth. When the limiting magnitude is at 10, the stars are drawn with few pixels, and the CPU efficiency of the new star code pushes its performance above that of the old code.

The new star code moves more of the rendering work from the CPU to the GPU. Part of this change is inevitable with the new algorithm, and part is deliberate. GPUs now have tens or hundreds of processors, so it makes sense to offload calculations there (especially when the results are bound for the screen anyway!) But if the GPU was already a bottleneck, moving more computation to the GPU will only make the problem worse.

I'm almost certain that main reason you're seeing a performance drop with the new star code is because more pixels are drawn... You could be limited by either pixel shader or graphics memory bandwidth. There are a couple tests you can try:

* Modify the assignment of gl_PointSize in the star vertex shader so that all stars are 3 pixels. Bright stars won't look right, but it will give some indication of the performance impact of drawing larger stars.
* Increase the range between the limiting and saturation magnitudes by one or two magnitudes. This generally decreases the size of the star glare.

--Chris

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

Re: Drawing a better star

#37by chris » 12.08.2010, 14:45

Boux wrote:No significant loss or gain of performance.
I did the test several times and the results are pretty steady.
Looks like the EXT_framebuffer_sRGB extension is doing its job.

When the EXT_framebuffer_sRGB extension is available, there are two benefits:
1. Better quality, since the GPU can do gamma correct blending (i.e. blending is performed in linear space)
2. Better speed, since the pixel shader doesn't have to do a linear color space to sRGB conversion

Although my system does support EXT_framebuffer_sRGB, I investigated the performance effect of not having the extension by forcing the linear to sRGB conversion in the shader. These results are with the same settings I reported in my previous message:

Code: Select all

Limiting mag.    linToSRGB on       linToSRGB off
      10                    370                       370
      12                    238                       284


So... no observable effect at limiting magnitude 10. It probably *does* have a minor effect that is being masked by some other performance bottleneck. At limiting magnitude 12, there's a definite slowdown. At this point, there are lot of stars with very large glare halos overlapping, so the extra pixel shader instructions in the linToSRGB function have a very noticeable effect.

--Chris

t00fri
Avatar
t00fri
Age: 15
Posts: 8800
With us: 15 years 3 months
Location: Hamburg, Germany

Re: Drawing a better star

#38by t00fri » 12.08.2010, 16:19

Chris,

my own interpretation of the lim.mag 12 drop matches yours perfectly. I also had tried lim.mag=10, 8
but displayed the one with the dramatic drop.

This was the alfa Crux - centered test image with your new stars that above gave the strong fps-drop by a factor of two. The large number of star pixels to be drawn here is evident.
alfcrux12.jpg



Fridger
Image

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

Re: Drawing a better star

#39by chris » 12.08.2010, 19:37

t00fri wrote:Chris,

my own interpretation of the lim.mag 12 drop matches yours perfectly. I also had tried lim.mag=10, 8
but displayed the one with the dramatic drop.

This was the alfa Crux - centered test image with your new stars that above gave the strong fps-drop by a factor of two. The large number of star pixels to be drawn here is evident.
alfcrux12.jpg


Yes, and it would be even worse with a wide field of view where there are many bright, large stars. A good reason to have auto mag enabled...

--Chris

Boux
Boux
Posts: 439
With us: 12 years 10 months
Location: Brittany, close to the Ocean

Re: Drawing a better star

#40by Boux » 14.08.2010, 09:02

I found something interesting running the MSI Afterburner monitoring tool.
The test has been done at the location Chris was using (9 light years from earth, stars rendering only, 45 FOV).
Here is the graph:
Image
You can see that GPU load starts dropping at Lim Mag 3 to reach a minimum at Lim Mag 10.
At Lim Mag 12, GPU load starts increasing again up to the maximum at Lim Mag 15.09.
There is something happening here. Could be CPU load reaching a peak and the GPUs starting waiting for data.
GPUs temperatures variations are consistent with the load.
This is a crossfire setup. Actual drop on a single GPU would likely be more in the 50-60% range.
Intel core i7 3770 Ivy Bridge @ 4.4 GHz -16 GB ram - 128 GB SSD cache - AMD Radeon 7970 3 GB o'clocked - Windows 7 64 Ultimate / Linux Kubuntu


Return to “Ideas & News”

Who is online (over the past 5 minutes)

Users browsing this forum: 1 guest