Nebulae in Celestia using sprites

[LukeCEL]

A note about color.

In astronomy, color is quite complicated. You can't just take many of the famous Hubble photos at face value, because they're false-color. This isn't because astronomers are trying to trick you - it's because using different filters and processing can bring out details so they can be more clearly observed.

Planetary nebulae emit light because of the central star ionizes the gas around it. In this case, there are only a few different colors a planetary nebula can take on, because there are just a few emission-lines visible. Hydrogen, for example, is visible as the H-alpha line which corresponds to a reddish color, and doubly ionized oxygen is a greenish-teal. Although I know the exact wavelengths of these lines, I am not sure of the exact RGB colors of them, the relative proportions (i.e. brightnesses) and how those combine. So while I want to say that my nebulae are natural-color, I can only say that I try my best to make them so.

Actually, the surface brightnesses of planetary nebulae are typically so low that they'd probably be completely invisible to the naked eye. So I am taking a little bit of a creative liberty here by increasing my models' surface brightnesses so they're quite vibrant, kind of like long-exposure photographs of them.

Defining color in sprite models.

With sprite models there are several ways to apply color to a white sprite texture:

1. Coloring the sprite texture itself. I suppose this works, but I've never used this method before, because the other two methods are far more versatile, in my opinion.

2. Coloring individual point sprites. To do this, I first added "color0 f3" to the vertex definition, like so:

Code: Select all

vertexdesc
position f3
pointsize f1
color0 f3
end_vertexdesc

then, the last three digits of each vertex (in this case, it's "1 1 1") will correspond to the R, G, and B color components of each vertex.

Code: Select all

0.786743 -3.15409 0.999953 1.2 1 1 1

3. Coloring the material definition. At the beginning of the CMOD, each material is defined, and you can add a color like this:

Code: Select all

material
   diffuse 1 1 1
   opacity 0.09
   texture0 "27px.png"
   blend normal
end_material

where again, "1 1 1" corresponds to the R, G, and B color component of the sprites. This is much more efficient if all the sprites are the same color. You don't have to define a color for each point, and then your CMOD will look something like this.

Vertex definition

Code: Select all

vertexdesc
position f3
pointsize f1
end_vertexdesc

Point definition

Code: Select all

0.786743 -3.15409 0.999953 1.2

Admittedly, I have used the second method to color many of my nebulae, even if all the points of the material were the same color. This is quite inefficient, because you are defining the same color for every point which can increase the file space by a lot. Therefore, I will be fixing my models so that they use the third method when applicable.

Best,
LukeCEL

[LukeCEL]

Update: I've optimized the CMOD models by coloring the material definitions instead of the points themselves, when possible. I also tweaked the appearances of some of the models. This means that the files are now slightly lighter than before. All of them are available in the Google Drive link in the first post.

[Trolligi 112477]

What about the fibonacci sphere?

[LukeCEL]

What about the fibonacci sphere?

The Fibonacci sphere (posted on Discord, by the way, for those lacking context) was created so I could fill a sphere evenly with points. I will release that once I'm done making final tweaks to it.

HD 163296

Sprites can also be used to make protoplanetary disks around stars. Unlike planar CMOD files, these have the advantage of being volumetric; they don't just disappear when viewed down the equator of the star. I chose to use HD 163296 because it's spatially resolved, so we know the physical extent as well as the orientation of the disk. I used Isella et al. (2016) as a reference.

Now, a big problem with using a singular model is that it doesn't rotate properly. The inner parts of a disk should rotate faster than the outer parts of a disk, but with a single model they all rotate at the same rate. I got around this by using multiple ring-shaped models. That way, you can set the size and rotation to an appropriate value.

To make each ring model, I first generated a bunch of random values (let's call it θ) between 0 and 2π radians. Then, I calculated the x-, and z- values using this formulae:

x = radius * sin(θ)
z = radius * cos(θ)

The radius is always 1, and the y-coordinate is always 0 in this case. The inner rings used fewer and larger sprites.

All the resources (the Excel file, ASCII CMODs, and finished add-on) are available in the Google Drive link in the first post.

[jujuapapa]

TY Luke !

[LukeCEL]

Kepler-1520 b (KIC 12557548 b)

A few exoplanets are known to have dust tails around them, because the planets' surfaces are literally evaporating away. KIC 12557548 b, now designated Kepler-1520 b, was the first known example of this.

These tails are actually pretty hard to model, even for professional astronomers. The paper I used was Rappaport et al. (2012), which made several assumptions to simplify the whole process. The results of their simulation are shown in Figures 6 and 7.

The first thing I did was to approximate the shape of the tail. I did this by taking Figure 6a (the diagram of the tail) and plotting it in Desmos, such that (0, 0) corresponded to the location of the planet and (-1, 0) the center of the star. (I also flipped the image vertically). What I found was that a logarithmic spiral of r = (θ^a)/b fit the image pretty well, with a = 2.8 and b = 4. The sprites would be then placed along this spiral.

The next thing to do was to figure out how big the sprites should be. The tail should spread apart as it gets farther away from the planet. So, at intervals of r = 0.25, I placed circles and approximated their radius so that they fit the diagram. Then, I plotted a graph of the circle radii as a function of r (r being the distance away from the center, not to be confused with the radii of the circles). I performed a linear fit, which seemed to work pretty well. Then, I could use that equation as a way to calculate the point size (as a function of r).

As for the opacity, the paper has a graph of the relative optical depth of the simulated dust tail, as a function of the distance across the parent star (Figure 7). Again, I plotted this image in Desmos, such that the peak (where the planet should be) had a height of 1. The authors stress that this is the relative optical depth, so I can't be sure of the absolute optical depth, but again, by finding a fit (mine was logarithmic + linear), I got a way to calculate the opacity as a function of the horizontal distance.

Unlike my other nebulae models which are supposed to model emission, this tail is supposed to model absorption. Therefore, while I could normally reduce the opacity by either darkening the color or reducing the actual opacity, that flexibility would not be possible for dark sprites. Therefore, every point had to have its own material definition with a specific opacity, calculated from the aforementioned formula.

To assemble the actual CMOD file, I wrote a Perl script. Unlike some other Perl scripts, this one has a while loop that increments the r value by 0.005 up to 1.3. Polar spirals tend to be written in terms of θ, but I chose to rearrange the formula, because incrementing the radius by a constant would lead to more evenly distributed point sprites. In the Perl script, I calculated θ from r, then x and y from θ and r using the polar to Cartesian conversion. Then, I calculated the point size from r, and the opacity from y.

I created a second set of points that was identical to the main tail. I rotated the coordinates by 180 degrees and made them invisible. This is to ensure that the tail is placed correctly.

Anyway, all the relevant resources (Perl script, ASCII CMOD, and finished add-on) are available in the Google Drive link in the first post. The Perl script has one preset that you can change, which is the color of the sprites. Currently it's set to (0.04, 0.03, 0.02) - pretty dark, but not so dark as to be completely invisible. You can change this to any arbitrary value, but an RGB color close to black is recommended. The finished add-on requires Sirius_Alpha's exoplanet catalogue as a base.

[jujuapapa]

Great !
Where can we download this addon (kepler 1520b) ?

[Trolligi 112477]

Probably in the google drive link in the 1st post.

[SVision]

Great job !
We have long dreamed of tails for exoplanets, but thanks to you it is implemented in Celestia
LukeCEL, bravo!

[jujuapapa]

I updated one of my addons with this !

[Trolligi 112477]

WOAH!! THAT LOOKS SICK AF

Where can I get that exact addon?

[LukeCEL]

GK Per (Firework Nebula)

GK Per has a very unique appearance, as its nova outburst in 1901 ejected a lot of mass. This mass is visible to us as numerous streaks of red, which I believe is H-alpha emission. Anyway, if you look at a picture of GK Persei, you can see how the nickname "Firework Nebula" is very well-fitting.

Credit: Adam Block/Mount Lemmon SkyCenter/University of Arizona, CC BY-SA 3.0

Actually, GK Persei has been studied extensively. One study (Harvey et al. (2016)) modelled the shape of the nova remnant, even deducing which knots were moving towards and away from us. Unfortunately, I came about this paper after I had made the model. So while the model generally fits the shape, it doesn't get the finer details right. Oh well.

The procedure to make the model was similar to the Abell 7 procedure, which I've written in detail in an earlier post. For Abell 7, I plotted a large number of points in GeoGebra, which corresponded to individual sprites. However, instead of starting off with a bunch of points at (0, 0), I created a bunch of points at (0, 0, 0).

I opened up a new, 3D graphics window by going to "View" -> "3D Graphics". This plotted all the points along a plane. To give them depth, I clicked on a point until a two-pointed arrow came up. Once that appeared, I could drag it up or down to the depth value I wanted.

What the GeoGebra setup looks like.

You can drag points up and down when these arrows appear.

click.png (18.72 KiB) Viewed 20138 times

Then, I copy-pasted the numerous rows I made into an Excel spreadsheet. From there, I could format the points into sprites however I wanted. A few notes:

1. I color-coded my points in GeoGebra so that they could get different appearance in my final model - for example, they could have a different color, size, or opacity.

2. To create the "streaks" radiating from the center, I simply copied the sprites, but multiplied the X-, Y-, and Z-coordinates by a number close to but less than 1. This "shrinks" them close to the center.

3. In the original photo by Adam Block, there are some blobs that are so bright that they appeared white. This is rather difficult to model in Celestia, so I just created a large pink sprite and smaller, more whitish sprite. It looks... alright, to be honest.

Anyway, all the resources (GeoGebra file, Excel file, ASCII CMOD, and finished add-on) are in the Google Drive link in the first post.

[Trolligi 112477]

noice

[Daly]

I made a color record for Estrella Tauri and Estrella Herbig

[jujuapapa]

Bravo Daly !

HD 6851 is very realistic.