Re: Particles


<jukka@xxxxxxxxxxxx> wrote in message
news:1156746866.979396.168880@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I have recently been writing some particle systems using OpenGL (2.0)
and have come to a conclusion that the facilities could need little
improvement in this regard. In Direct3D there is "vertex stream
frequency" which eliminates some need for duplicating per vertex
attributes as the frequency can be set to 1/4 (four vertices per
particle). There is no equivalent functionality in OpenGL as far as I
am aware of.

The closest boost is point sprites, or ARB_point_parameters, both of
which are useless for my purposes. The point sprites have fixed size
(not useful for scaling the particles with projection transformation
like rest of the primitives in a scene). The ARB_point_parameters use
attenuation formula, which is also useless for the same purpose!

The ideal approach is:

Each particle has a position. Then we can parametrically compute any
attribute we need for rendering (color, size, rotation, etc.)

How I propose this would work:

First a vertex program,

-- begin vertex program

uniform mat4 modelview;
uniform mat4 projection;
attribute vec3 position;
attribute float halfsize;
attribute float angle;

void main()
{
vec4 p = modelview * vec4(position, 1.0);
float dx = sin(angle) * gl_ParticleCoord.x - cos(angle) *
gl_ParticleCoord.y;
float dy = cos(angle) * gl_ParticleCoord.y + sin(angle) *
gl_ParticleCoord.y;
p.x += dx * halfsize;
p.y += dx * halfsize;
gl_Position = projection * p;
}

-- end vertex program

In above vertex program, first we transform the particle position. Then
we compute the rotation and scale of the particle into (dx,dy) and
rotate the particle in view coordinates (facing the viewer!), then
transform with perspective projection, which is (hopefully, fingers
crossed ;) the same as used for rest of the scene.

This way the particles can have size in model coordinates (or any
coordinate system the programmer desires, ofcourse!)

The extension would work like this:

When we draw primitives of type, say, GL_PARTICLE_EXT (!?) the
following would take place:

Particle primitive would be generated per vertex (just like GL_POINTS!
generates point per vertex). With the exception that the hardware
generates FOUR actual vertices for the vertex program to process and
every fourth vertex would render two triangles (or quad, or whatever is
most appropriate within the implementation!)

This would be visible to the vertex program as a built-in uniform:

uniform vec2 gl_ParticleCoord;

This would classify the corners of the particle primitive. For example,
top left corner could be (-1.0, -1,0), top right (1.0, 1.0) and so on.
The rotation and scaling were just examples, imagination would be more
practical limit. :)

Why?

Currently I am having FOUR vertices per particle. The position is
duplicated for four consequtive vertices. Same for halfsize and
rotation angle. It is four times the amount of memory burned for VBO.
It begins to add up when turning around 2+ million particles. Updating
the particle positions also becomes interesting as have to write each
value four times (!).

More than this, there is no way to set vertex attribute frequency like
in D3D and/or use separate vertex streams for different attributes. For
instance the "class" of vertex (which corner, aka. gl_ParticleCoord)
needs to be stored on each particle system separately, I used to store
those in unique vertex stream of their own with D3D). At best, can
separate the data into own chunk within the VBO (non-interleaved vertex
data). Still not optimal and still need the same data over and over
again for each VBO. =)

The thing is, since the latest NV and ATI hardware already *are*
DirectX 9.0 compatible, this *should* be supported in hardware as it
were, all we really need is an extension to expose the functionality.

I cannot be the first person alive to want more efficient particle
system rendering can I, so why isn't extension like this already
proposed? If have, why has it been rejected, and why inferior
point_parameters, point_sprite etc. nonsensa have PASSED!? :)

I'm at a loss to understand your requirement of 4 vertices per particle.

I guess it boils down to why you can't use the point attenuation as a
function of projection (it almost always is ...)

http://www.codesampler.com/oglsrc/oglsrc_6.htm

"This sample demonstrates how to use the OpenGL's ARB_point_sprite
extensions to create point sprites. Point sprites are hardware-accelerated
billboards, which are capable of being textured. Point sprites are ideal for
creating high-performance particle systems because you only have to send a
single vertex point or point sprite for each particle instead of four
vertices for a regular billboarded quad. Point sprites also do all the math
involved in view aligning the final quad on the GPU instead of the CPU. See
the Particle System sample on this page for a more complex example of their
usage"

-jbw







.

Relevant Pages

  • Re: particle fx
    ... smoke, fire, clouds, water, blood, ... ... may also use common "generic" sprites ... maybe one might also have a color for each particle. ...
    (comp.graphics.api.opengl)
  • Re: Particles
    ... How are point sprites clipped? ... standard ... per-fragment clipping operations (scissoring, window ownership ... broadcast the particle "corner" class as uniform vec2 ...
    (comp.graphics.api.opengl)
  • Re: "quantum mechanics and experience"--non separability
    ... > going on in the other particle)? ... > state of the two particle system, ... > So B, at the time of measuring of A, is still undetermined, but there ... > circumstances non-separability of two particle systems obtains. ...
    (sci.physics.relativity)
  • non-separability of 2 particle systems in quantum mechanics
    ... going on in the other particle)? ... is the quantum state of the two particle system, ... So B, at the time of measuring of A, is still undetermined, but there ... I raise this question because this non-separability seems to me to be ...
    (sci.physics)
  • "quantum mechanics and experience"--non separability
    ... going on in the other particle)? ... state of the two particle system, ... So B, at the time of measuring of A, is still undetermined, but there ... I raise this question because this non-separability seems to me to be ...
    (sci.physics.relativity)