Horde3D

I wondered why Horde shouldn't use point spites for rendering particles. This way you get bilboarding for free and you have all particle data as attributes in buffers, instead of those ugly indexed 64 element uniform batches.

By unsing the frameBufSize uniform you can compute the particle's screen size from its object size and write this into gl_PointSize in the vertex shader. By using the gl_PointCoord varying in the fragment shader you get the fragments texture coordinates in the screen aligned quad in a forward-compatible, non-deprecated way (as point sprites are supported even on the OpenGL 3/4 core profiles). The other attributes (color, rotation) are just passed through flat varyings.

One problem is that you always get screen aligned quads without rotation, but most times the rotation of the quad in VS can be compensated by rotation of the texture coordinates in FS.

Another problem is, that gl_PointCoord is first introduced in GLSL 1.20, but this can be overcome by increasing Horde3Ds requirements to OpenGL 2.1 hardware, which brings GLSL 1.20 as core (along with sRGB). This requirement increase is not that much of a problem, as Horde is targeted at "next-gen" hardware anyway and on a card that supports 2.0 and FBOs and float textures, supporting 2.1 is more of a driver question than a hardware problem. This way you also get PBOs, which could come in handy when later possibly doing the particle update on the GPU, now that all data lies in buffers.

This way you also do not need to transfer data to GPU, that has not changed, e.g. when particles have constant color, size or rotation, by separating the particle attributes into multiple buffers.

We were considering using point sprites a long time ago but although they looked tempting at first, they had several drawbacks at that time. For example, the whole sprite gets clipped when the center is outside the viewport and there is a hardware dependent maximum size (max size should be ok though in GL on current hardware).

Also note that they were completely dropped from D3D10/11. Another thing is that they are not very flexible. Some particles could heavily benefit from a non-quadratic shape (rectangle, hexagon) to save fillrate. If you rotate the texture in the FS, you will even get more wasted space and also pay on the fillrate for the added instructions.

Strange, that they are dropped from D3D and still existent in GL3 (~D3D10) and GL4 (~D3D11) (yet another feature of GL not in DX, yeah ).

Regarding the flexiblity: At the moment you cannot control the primitive type on the user level, Horde allways uses quads (but I see what you mean). Ok, the size could be a problem when using very large particles, like explosion sprites or something (not the usual dust-sized thingies). That would also be the cases where viewport clipping makes problems.

It was just a thought experiment, I understand your arguments. But the current framework looks just a bit odd, with those indexed uniform arrays and the corner array and this whole batchification. Perhaps sometime a texture buffer or a geometry shader based auto-quadification (perhaps the reason for dropping them from DX) could help make this whole framework a bit cleaner. Or maybe the use of instanced arrays (drawing many same quads and increasing the particle data buffer index per quad). But I think all this could set a bit high hardware requirements (although Horde3D considers itself a next-gen engine). Who knows.

Another feature not actually present in the hardware that your IHV/ISV OpenGL driver author is forced to emulate...