Particle systems revisited

[Chuft-Captain]

Chris,

Have you modeled any explosions yet?...
Possible applications: ... novae, supernovae, meteor impacts, birth of the moon, ...etc...

[W0RLDBUILDER]

I think Celestia should have some kind of physics-like system and a set of variables that can be defined in an SSC file.
Direction defines what direction, relative to the surface of the planet, the particles should go.
Variance defines the radius of a (figurative) cone where the particles will come out, in degrees. 90=Ground explosion, 10-30 might make a nice volcano, 180 is a spherical explosion.
Color is simply the color of the particles, specified the usual way.
Mode uses 3 modes. 1 is emissive or additive, good for explosions or fireballs. 2 is illuminated. 3 is subtractive; the color specified is the opposite of the color that will filter through it.
Resistance defines how fast the particles will fall, from 0-100. 100 is like giant chunks of metal-density material. 0 is like smoke.
Speed is the speed of the particles, in km/s.
Mesh is the shape of the particles (individually, not collectively) and the default is none, or billboard.
Texture is the texture of the particles. For meshes it will be wrapped around the particle as the mesh dictates; for billboards it's the color/transparency map for the particles.
LatLong is just like normal; it specifies the location of the origin.
ParticleLife is the time each particle will last before fading out, in seconds. It doesn't apply if EllipticalOrbit is used.
Particles defines the number of particles that are created.
Beginning specifies the time and date the particles first come from the origin. It doesn't apply to orbit-based particles.
Ending specifies the time and date the particles stop coming out. It doesn't apply to orbit-based particles.
EllipticalOrbit can be used in place of the physics system to define an orbit for the particles instead of the Direction, Variance, Speed, and Resistance statements. Extra variables would be required:
Width is the amount of deviation from the original semimajor axis value in km.
Thickness is the amount of deviation from the original inclination.
SpeedVariance is the amount of speed difference there is from the inner edge to the outer edge of the particle system.
---
Physics-based particles bursting out of a volcano on Venus:

Code: Select all

Particles "Volcano" "Sol/Venus"
{
LatLong [ 20 35 0 ]
Direction [ 0 1 0 ]
Variance 20
Color [ 1 0.3 0.05 ]
Mode 1
ParticleLife 10
Speed 1
Resistance 3
}



Orbit-based particles around a black hole:

Code: Select all

Particles "Accretion Disk" "HD 226868/Cygnus X-1"
{
Color [ 0.5 0.45 0.4 ]
Mode 2
Particles 10000
EllipticalOrbit {
SemiMajorAxis 50
Inclination 0
Period 0.3
Width 20
Thickness 5
SpeedVariance 0.1
}

}


[duds26]

A few examples of well known forward-scattering particle systems include Enceladus' plume, Io's volcanic plumes, and Saturn's F, E, and G rings. In these cases, these features are much more visible when Enceladus, Io, or Saturn are visible as a crescent, and nearly invisible (particularly in the case of Enceladus' plume and many of Io's plumes) when the particle systems are viewed at low phase (sun behind the observer).

One function that could be adopted for use in the case is the Henyey-Greenstein Asymmetry function (g). Negative values for g represent back-scattering particles, and positive values for g represent forward-scattering particles. g=0 represents an isotropic surface that scatters the same amount of light at all phase angles. This setup could also be used for other objects to define how the reflectance of a surface varies with phase angle.

I did experiment with simulating forward scattering in particle systems. See this video which shows a volcanic plume rendered with g = 0.4:

http://www.youtube.com/watch?v=nJqkdbkOTLE

The phase dependence is obvious, but it still doesn't look quite 'right'... I suspect that the value of g needs to be higher. However the problem with high values of g is that we need some mapping to the range of intensities displayable on a monitor. Here are the values of the Henyey-Greenstein phase function for g = 0.75:

0: 14.0
45: 0.615
90: 0.112
135: 0.051
180: 0.0408

When rendering to an 8-bit/channel framebuffer, if particles at 0 degrees are rendered at full-brightness, particles at 90 degrees will almost disappear. In practice, what happens is that the particles with intermediate phase angles have pixel values that are near the lowest value representable with 8-bits. Drawing lots of these particles results in very ugly quantization artifacts. I'll try and provide some more examples that illustrate this.

--Chris

IT seems you need HDR (High Dynamic Range) rendering with tone mapping, or at least a HDR frame buffer.
Please add HDR, it will make Celestia a lot more realistic and solve these quantization problems you're dealing with.
Not only here but everywhere with large contrast areas. ( light sources and dark areas in the same image, frame )

As a side note, OpenGL 4 has double precision added in the rendering pipeline.
http://en.wikipedia.org/wiki/OpenGL#OpenGL_4.0
It's emulated and about 5 to 10 times slower to do.
Still respectable considering the resources of the cards that support it.

[t00fri]

Celestia does have (experimental) HDR! didn't you know? Just activate it, rebuild Celestia and play with it if you please.... DW implemented it before vanishing from the community.

Fridger

[duds26]

I know about it.

My point is, being experimental and not on by default, it's not reliable nor usable.
Things could still change and break.

If it was stable and on for default you could rely on it being there always fixing those problems.
It's such a pitty that HDR isn't stable and reliable (yet?).