Celestia Forums

A newly added feature to the cmod format are point sprites. These can be used for a variety of different volumetric rendering effects for phenomena such as nebula, accretion disks, volcanic plumes, or engine exhaust. To give a familiar example, Celestia's galaxies are rendered using point sprites (albeit with a level of detail feature not available for cmod point sprites.) First, some caveats:

- Sprites are only implemented in the OpenGL 2.0 path right now
- I don't know how 3D modeling programs handle sprites (or it they do at all); thus any cmods that use sprites will have to be hand-edited or generated by a custom program.

Here is example add-on featuring a nebula drawn with point sprites. The nebula isn't intended to be realistic--the add-on just shows how to achieve a volumetric effect with sprites.



The add-on can be found at http://www.shatters.net/~claurel/celestia/files/spriteneb.zip

The changes to the cmod format relevant to point sprites are very minor. There's a new primitive type (sprites), and a new vertex attribute type (pointsize). The sprite texture is texture0 from the material definition. Here is a very basic example of a sprite cmod with three red sprites:



For nebula meshes, it may be useful to specify additive blending in the material definition by adding the line 'blend add'. This is especially appropriate for emission nebula, definitely not to be used for dark nebula like the Horsehead. Additively blended objects have the advantage of not needing to be depth sorted with respect to each other. Here's a slightly more complex sprite cmod that uses additive blending and per vertex colors so that each sprite has a different color:



The program GLNebula uses additively blended point sprites to show nebula generated by the photoionization tool Cloudy-3D: http://132.248.1.102/Cloudy_3D/ An interesting project would be a tool to convert output from Cloudy 3D into a cmod file.

--Chris

I'll recompile Celestia tonight and test the helicoid (a nice example of a "minimal" surface, BTW). If it works very well, I think Mathematica will be crunching intensively for the next several months !

I do hope that Fridger's mass rendering for nebulas won't be based on this rendering because 1) all not config can handle point sprites 2) not all config can handle OGL2...

Now the main problem of this new stuff is how people are supposed to model things? (I would love to test for the stack smoke)

ElChristou wrote:I do hope that Fridger's mass rendering for nebulas won't be based on this rendering because 1) all not config can handle point sprites 2) not all config can handle OGL2...

Now the main problem of this new stuff is how people are supposed to model things? (I would love to test for the stack smoke)

Christophe,

certainly the present galaxy rendering was based on point sprites! You didn't have any problems with them did you?

The main concern with mass rendering of /diffuse/ nebulae is the lack of symmetry and/or morphological classification. Bipolar planetary nebulae look way more promising, since they do have an (approximate) axial symmetry along with certain characteristic patterns.

Bye Fridger

ElChristou wrote:Now the main problem of this new stuff is how people are supposed to model things? (I would love to test for the stack smoke)

Unless 3D applications can make distributions of dots with proper colors and size (formatted so they can be translated into a CMOD file), this is fundamentaly mathematical stuff.

I guess only peeps with mathematical knowledge could make such models, with apps like Mathematica, Maple and MathCad, or any compilers (using Fortran, etc...).

I don't think there's much hope to "democratise" this feature so more users could built their own custom models.

Currently, AFAIK, the only "well known" users on the forum who can built sprites models are Chris, Fridger, Selden and myself.

Well but Christophe (aka ElChristou) is a fast learner

Give him a few Laotian Pizzas, 'un ballon du rouge' ...and he will be in business as well ...

Bye Fridger

t00fri wrote:...certainly the present galaxy rendering was based on point sprites! You didn't have any problems with them did you? ...

Well I'm not the expert coder here, but seems that the sprites used with the galaxy rendering are not what is called "point sprites"; my config is one that cannot handle point sprites (-> spec of my video card)...

ElChristou wrote:

t00fri wrote:...certainly the present galaxy rendering was based on point sprites! You didn't have any problems with them did you? ...

Well I'm not the expert coder here, but seems that the sprites used with the galaxy rendering are not what is called "point sprites"; my config is one that cannot handle point sprites (-> spec of my video card)...

There's some confusion because sprites can refer to two related things: the technique of rendering textured screen facing rectangles, and the hardware feature that makes rendering sprites fast and simple (hereafter referred to as 'hardware sprites').

Galaxies are rendered using software-emulated sprites. Celestia computes four vertices for each 'blob' and submits it to the hardware. At some point, we will optimize the rendering of galaxies by changing the code to use hardware sprites if they are supported by the computer's graphics card. With hardware sprites, Celestia just sends a single vertex and the graphics card automatically computes the four vertices of the screen facing sprite rectangle. The star rendering code already uses hardware sprites when they are available, resulting in a measurable performance gain when lots of stars are visible.

Point sprites in cmod meshes are only rendered with hardware sprites. I could take the time to code a software emulated path, but I haven't taken the time to do so yet because most graphics cards support hardware sprites.

--Chris

Well,

my good old FX5900 Ultra does NOT render Chris' above point sprite nebula test. The add-on name is displayed on the top left, but it's not rendered when I type G(OTO).

I used OpenGL2 rendering path.

So that ws it for me.

Bye Fridger

chris wrote:...I could take the time to code a software emulated path, but I haven't taken the time to do so yet because most graphics cards support hardware sprites.

What do you mean by "most"? the past 2 years hardwares? Don't forget not everyone on this planet is working in software creation or is a hardcore gamer who will always update his hardware to stay tuned with the last technologies.

My card is 4 years old and already Celestia propose features that this card cannot handle. Most of the educative establisments have much worst config...

What do you mean by software emulated path? a whole software emulated path for all Celestia calculation or something just for this specific feature? DW recently test some fully software rendering on osX, it works (I have been able to use OGL2 path with for first time on my config, shadow rings on Saturn, the fantastic atmosphere of Titan by Fridger and so on), but the FPS is so terrible that it's not usable...

t00fri wrote:Well,

my good old FX5900 Ultra does NOT render Chris' above point sprite nebula test. The add-on name is displayed on the top left, but it's not rendered when I type G(OTO).

I used OpenGL2 rendering path.

So that ws it for me.

Bye Fridger

Is there any message in the console or shaders.log indicating what the problem may be? Your FX5900 should be able to easily handle this test.

--Chris

t00fri wrote:Well,

my good old FX5900 Ultra does NOT render Chris' above point sprite nebula test. The add-on name is displayed on the top left, but it's not rendered when I type G(OTO).

I used OpenGL2 rendering path.

So that ws it for me.

And you do have nebulae enabled? I had an panicked unnecessarily when testing sprite-based nebulae because I'd forgotten to turn on nebulae in the view options menu.

--Chris

chris wrote:

t00fri wrote:Well,

my good old FX5900 Ultra does NOT render Chris' above point sprite nebula test. The add-on name is displayed on the top left, but it's not rendered when I type G(OTO).

I used OpenGL2 rendering path.

So that ws it for me.

Bye Fridger

Is there any message in the console or shaders.log indicating what the problem may be? Your FX5900 should be able to easily handle this test.

--Chris

Sorry, nothing. I get the label and the location displayed (red diamond), the distance is like in your example, but nothing is visible. My opengl info says I should see point sprites. No console complaints under Linux.

I checked that I have activated everything that might be relevant...Another nebula add-on (M42) is correctly displayed with the same settings.

How again do I provoke shaders.log? I forgot. After it polluted every directory , Pat turned it off and I forgot how to turn it on again ...

Bye Fridger

I also checked celestia-gtk besides celestia-kde. I made sure that nebula rendering is turned on. Nothing.

I guess I should activate my notebook (windows)?

Bye Fridger

Stop...I just noticed that there is a bunch of new commits in CVS

Just compiling...

Bye Fridger

OK, relax

everything works fine...I thought I had implemented your latest CVS commits already, but actually I had NOT.

Bye Fridger

It seems that this stuff slows down my display quite significantly. Zooming in and out is not entirely smooth as usual...

Bye Fridger

t00fri wrote:It seems that this stuff slows down my display quite significantly. Zooming in and out is not entirely smooth as usual...

There are a lot of overlapping alpha blended sprites in the model, which will use a lot of memory bandwidth when they fill a large area of the screen. Drawing an alpha blended pixel requires at least double the bandwidth of normal pixel, because the pixel in the image must be read, blended with the sprite color, then written out again. The readback isn't necessary for opaque rendering. Opaque rendering can also use early Z optimization strategies that don't work when rendering transparent objects.

A more memory bandwidth efficient method for rendering volumes ray marching in 3D textures. With this approach, the color of each nebula pixel is accumulated in a shader loop rather than with multiple reads and writes to the frame buffer. It would be quite a lot of work to implement true volume rendering, and I'm not sure how much of a demand for it. There are not to my knowledge a lot of astronomical volume data sets waiting to be imported into Celestia. Of course, I'd be happy if that assumption of mine was demonstrated to be wrong.

--Chris

chris wrote:...
There are not to my knowledge a lot of astronomical volume data sets waiting to be imported into Celestia. Of course, I'd be happy if that assumption of mine was demonstrated to be wrong.

--Chris

I completely agree.

I consider /efficient/ "mass rendering" of DSO's very important. Much more so than individually "handicrafted" renderings of nebulae in add-ons.

I see little hope to render diffuse nebulae in a volumetric manner merely from catalog data.

Bye Fridger

Chris,

you wrote in CVS that you fixed point sprite nebula rendering and did quite a few respective commits. But when I try your spriteneb add-on now, it is overbright and VERY slow, indeed.

Bye Fridger