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