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

Here's what I think is happening...

* When the limiting magnitude is low (i.e. few stars are drawn), there's not much work for the CPU to do. The GPU is kept busy repeatedly clearing the framebuffer at an extremely high rame rate.

* As the limiting magnitude increases, the CPU has to process more and more stars. The GPU has only slightly more work to do, as the number of stars drawn isn't that large and they only cover a few pixels.

* When the limiting magnitude gets very large, the stars become bright and cover a lot of pixels. This requires a lot of pixel shader processing and graphics memory bandwidth, and the GPU becomes the bottleneck again.

It's important not to get too caught up about performance now; correctness is more important at this stage. Also, the performance of the new star rendering is already faster except when very large stars are rendered. With the new code, more work is offloaded from the CPU to the GPU. This is desirable because the shaders always run in parallel on GPU cores, and the typical GPU has a lot more cores than a CPU. It's not too hard to modify the code so that the CPU is doing less work. Another very useful optimization would be switching the star rendering to use vertex buffers so that the CPU and GPU can better operate in parallel with each other.

I've created a .exe with diffraction spikes enabled if anyone wants to play around with it. For windows only. Just replace your current celestia.exe with the one below, back up your old one first! The fantasy picture above had a limiting magnitude of ~9.5. Use "[" and "]" to adjust the limiting magnitude.

I've created a .exe with diffraction spikes enabled if anyone wants to play around with it. For windows only. Just replace your current celestia.exe with the one below, back up your old one first! The fantasy picture above had a limiting magnitude of ~9.5. Use "[" and "]" to adjust the limiting magnitude.

Like Reiko, I was trying to produce with your builts the stars with spikes, wondering what was I did wrong. Thanks for the clarification Abramson. Any clue to modify the source to get the spike stars? I tried but failed

You can also download the whole VESTA library from ASTOS (after registration), which I did. Since the licence of VESTA is a bit tricky, I don't think they would allow copying just their star shaders and related code into Celestia. Unlike Celestia, the entire 3D rendering of Cosmographia is done by means of VESTA.

Since ChrisL did work for ASTOS, it is best if he specifies which star code was first and how it may now be used in other software, including Celestia(.Sci). Since meanwhile, I developed the star rendering of Celestia.Sci quite a bit further, along with the rendering of all globular cluster stars with the same star shaders, I would appreciate knowing more precisely how the correct quotations go here....

ajtribick wrote:Since ChrisL did work for ASTOS, it is best if he specifies which star code was first and how it may now be used in other software, including Celestia(.Sci). Since meanwhile, I developed the star rendering of Celestia.Sci quite a bit further, along with the rendering of all globular cluster stars with the same star shaders, I would appreciate knowing more precisely how the correct quotations go here....

The work for ASTOS was first, but the two implementations were developed separately albeit using largely the same technique and equations. There are some important differences... The shader from VESTA uses precalculated apparent magnitudes for the stars and assumes that all stars lie on a sphere of radius 1; the Celestia shader uses the full 3D position of stars and computes apparent brightness from intrinsic brightness and distance.

t00fri wrote:Since ChrisL did work for ASTOS, it is best if he specifies which star code was first and how it may now be used in other software, including Celestia(.Sci). Since meanwhile, I developed the star rendering of Celestia.Sci quite a bit further, along with the rendering of all globular cluster stars with the same star shaders, I would appreciate knowing more precisely how the correct quotations go here....

The work for ASTOS was first, but the two implementations were developed separately albeit using largely the same technique and equations. There are some important differences... The shader from VESTA uses precalculated apparent magnitudes for the stars and assumes that all stars lie on a sphere of radius 1; the Celestia shader uses the full 3D position of stars and computes apparent brightness from intrinsic brightness and distance.

--Chris

Chris,

firstly, you mixed up Andrew's and my post in your above quote.

Second: I am not sure whether my English is adequate to disentangle correctly the implications from your reply. Were you saying that you independently developed BOTH, the star shader code for VESTA and the almost identical code distributed in your better_star patch? Except that you had submitted the code to VESTA@ASTOS already before you sent me and others the star patch (that largely was under the Copyright@ASTOS by then?).

I think you will agree that the differences you mentioned are really minor. Like the evaluation of the z_coordinate via

in case of the "spherical" sky (VESTA). There, the appMag value is transferred in the unused z-coordinate slot, while in the Celestia patch case, it's a vertex attribute (what else?) and the z-coordinate is a regular entry in the vertex array.

The far less trivial aspects are almost totally identical, notably also the linearToSRGB(vec3 color) part!

Incidentally, the vertex shader can be massively simplified analytically and thus requires considerably fewer arithmetic operations than the VESTA or your patch code. As to the magnitude dependence, one easily finds for example that the vertex shader code only depends on the ratio.

relMag = (saturationMag - appMag)/(saturationMag - faintestMag)

with the denominator now being traded as a constant (e.g. -4.5).

Furthermore, both (vertex and fragment) shaders only depend on the product of b * exposure rather than on both quantities separately. So your two transfers as separate uniform variables b and exposure are reluctant as well. Etc.

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??