Particle systems revisited

[chris]

It would be a text file located in the models directory, and it would contain all of the particle system parameters.

Chris,

if there will be different "model" .cpart files placed in the models directory, editable using a text editor, I think that the parameters declared in the SSC should be fully customisable by the user, like what we currently do with the ScriptedOrbit method. So all the initial conditions (input data) could take any form, depending of what the user want to do with his/her .cpart file.

Is that possible ?

I guess I was thinking that all the parameters would be inside the cpart file. The SSC definition would just position and orient the particle system using the standard frames, trajectories, and rotation models used for other models. I don't see a need to have user-defined SSC parameters like we do for ScriptedOrbit. If you want the particle system to behave differently, just create a different cpart file. Can you envision a scenario in which this scheme falls apart?

EDIT : Hmmm, cross-posting.
How many **general** parameters need to be declared for a quadratic curve ? 10 ? Plus the particle's size, color and opacity parameters ?

[/quote]

Just 9 parameters in three dimensions. But keep in mind that we're not specifying the parameters of the quadratics directly: the particle system parameters describe pseudorandom distributions of the initial particle state. There are many more than 9 possibilities. For example in the ion thruster example, the starting position of the particles is a Gaussian disc; parameters describe the radius and variance. Also, there are emitter-global parameters: acceleration, particle lifetime, colors, etc.

--Chris

[Cham]

I guess I was thinking that all the parameters would be inside the cpart file. The SSC definition would just position and orient the particle system using the standard frames, trajectories, and rotation models used for other models. I don't see a need to have user-defined SSC parameters like we do for ScriptedOrbit. If you want the particle system to behave differently, just create a different cpart file. Can you envision a scenario in which this scheme falls apart?

Ok, I agree with this. So no new parameters in the SSC, and all the system's modelisation inside the .cpart file. This makes sense. This is the way to go.

[Fenerit]

Chris, BTW, your particles examples does use the common shaders, or have one dedicated?

[volcanopele]

One change that Chris and I have discussed and that I would like to see included in particle systems, is some sort of user-definable phase function. Currently by default, Celestia assumes that objects are either emitters of light (like stars) or if they reflect light, they are back-scattering, meaning the majority of the reflected photons that bounce off an object travel back in the same direction as the light source. Celestia does have the lunar-lambert function, but this mostly treats the macroscopic roughness of an object, which effects limb darkening. For particle systems, the user should be able to define if an object is mostly back-scattering or forward scattering, meaning most of the reflected photons travel in the direction away from the light source. 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. It can be used as a single number, or as a map of some kind representing changes in g across a surface. Bjorn Jonsson did just that with Io in his own animation set up and posted a movie over at UMSF, if you want to see an example of what that can do.

Read more on the Henyey-Greenstein Asymmetry function:
http://www-loa.univ-lille1.fr/~boucher/ ... node2.html

Other Hapke photometric functions might be useful as well.

[chris]

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

[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 isn't usable to be relied upon.

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