Rendering lots of pixels 1 by 1 ?

Started by
14 comments, last by vNeeki 12 years ago

I'd use the vertex shader to position the particles (just draw each particle as a triangle or a quad). Then if post processing was needed I'd use the fragment shader.


This is more or less the way I'd do it too (the only thing I might change would be to add a geometry shader for the initial positioning and expand to a quad from there, but admittedly this won't fit with the requirement to move to GL ES).

The way I'd then set it up would be to calculate a bunch of properties for each particle in an emitter when the emitter is spawned; these might include initial position, velocity, direction, gravity, etc. They're stored out as vertex attributes one-time only here. Then for each emitter you would send a delta between the time now and the time when it was spawned as a uniform, using a combination of this delta and the properties (i.e. vertex attribs) to determine the particles current position. That should work well enough if you're not doing anything too fancy with them.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

Advertisement
I have implemented the buffer texture and it improved speed by over 40.00% which is great.There is a little flickering though but
i think that i will improve it over with a shader effect;)


I'm kind-of wondering why this parameter needs to be a uniform at all. Perhaps it could be an element in your or a vertex stream?
[/quote]



But of course, I might be drawing a different particle effect than you. So far you haven't described what kind of particle effect you're implementing, and some effects may be better implemented in different ways than other effects.
[/quote]

Some particle effects that i need , are :

-Building explosions
-Power up type that follow the player
-Item pick up type that follow the player

And i don't think that using a shader is a good idea , unless of course if its possible to texture map points(gl_points) since then i would
need 1point/particle and my vertice array would have 1/6 or 1/4 the size of my old implementation(1quad or 2tris / texture) (Would work with GLES too!) or not use vertices at all and use a client side array if that's possible?
Instancing might help. At least it will cut down the number of draw calls. Have a google for it.

Instancing might help. At least it will cut down the number of draw calls. Have a google for it.


Very interesting but won't work with GLES unless there are portable implementations.
There's a GL_OES_point_sprite extension which may be available, and looks like it can coexist relatively peacefully with regular point sprites. Personally I'd still just use textured quads, at least initially, and not worry too much about size of geometry and/or vertex shader ops until such a time as I had determined for certain that it would be a problem. Reason why is because in a particle system your primary bottleneck is far more likely to be fillrate, so focussing on the other stuff is a case of micro-optimizing something that probably isn't even a huge problem to begin with.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.


There's a GL_OES_point_sprite extension which may be available, and looks like it can coexist relatively peacefully with regular point sprites. Personally I'd still just use textured quads, at least initially, and not worry too much about size of geometry and/or vertex shader ops until such a time as I had determined for certain that it would be a problem. Reason why is because in a particle system your primary bottleneck is far more likely to be fillrate, so focussing on the other stuff is a case of micro-optimizing something that probably isn't even a huge problem to begin with.


Thanks i'll have a look.
smile.png

This topic is closed to new replies.

Advertisement