   Particle system - Alternate Intensities
  So, I'm making a little particle system.  I did it what I imagine is the standard way, with little textured, colored, alpha-transparent quads.  Naturally, if a bunch of them are on top of each other, they approach white, and where there aren't any, the screen's just black.I was wondering about how I would change how rendering is done so that brighter things wouldn't necessarily be brighter.  For instance, in a brightness range of 0-255, maybe 0-50 would be blue, 51-100 would be red, 101-150 would be green, etc.  Or maybe it'd be ever stranger.To do this, would I need to look into shaders, or is there another way?   
  If I fully understand your desire, that would typically best be handled by a shader. And further, since the effect of the "whitening" is a blending effect that occurs after the pixels leave the pixel shader, you would need to render the particles alternately to 2 textures and use those textures, one as a rendertarget the other as a source, draw a particle and use a shader that sums the output with the source texture. Then swap the texture roles, use the other as the rendertarget the former as the source and repeat with the next particle. Repeat process for each particle. Then finally, draw the texture last used as a rendertarget to the backbuffer, but use a different shader that remaps the colors.Our you could simply render all the particles to the backbuffer, then capture it, and stuff it in a texture and then draw that texture to the backbuffer with the shader that remaps the colors. In fact this might be the best option as it uses far fewer state changes than the previous method. [grin]Or instead of using a shader you could simply capture the backbuffer and process it with the cpu. Though that is surely bound to be much slower.   ;  Yes, that makes sense.  Render them in black and white, and then use a shader to figure out color from their intensities.Forgetting that whole idea, I've been seeing a lot of mention of point sprites.  Right now, the way I render particles is by creating two triangles that make a single 1x1 square, then rendering it with a seperate material and view matrix for each particle.  I'm beginning to suspect this is not the fastest way to accomplish this.  I've seen some mention of point sprites, and as long as I can position them in 3D and possibly resize them, they're probably fine.  Still, I wonder what other options ther emight be.   ;Quote:Original post by Ozymandias42... Right now, the way I render particles is by creating two triangles that make a single 1x1 square, then rendering it with a seperate material and view matrix for each particle. ...You can speed it up a lot by putting all the particles in a single vertex buffer and updating the vertex buffer every frame with the new locations of the vertexes in world space. Then, then you use the same view matrix for all the particles and draw them all in one draw call. However, that won't work if you still set a material for each particle. You should aim for drawing all the particles in one draw call.;Quote:You can speed it up a lot by putting all the particles in a single vertex buffer and updating the vertex buffer every frame with the new locations of the vertexes in world space.Yeah, I tried turning off material switching and using point sprites instead of quads, and it put increased how many particles I could draw in a frame by an order of magnitude.  I can do at least 20,000 or so now in a single frame, which is awesome.I'd like to get away from point sprites, though.  They're a bit inflexible, and I'd like to occasionally do things like stretch particles or rotate them that're not possible with point sprites.  The problem is that I've been handling billboarding by using a single -1,-1,0 to 1,1,0 quad and updating the view matrix to get it into the right location and facing the camera.What would the math look that that would, given an input of the center of the quad and its size, generate a quad that faced the camera?   ;  Okay, I think I've almost got the math for this.  To billboard, I'll start with:a.) the center of the particle, Pb.) the position of the camera.c.) the camera's up and right vectorsand my goal is:z.) 4 points that make up the square.Now, B-C is the vector from the camera to the particle.  So I'll take the cross product of it and the up vector, and also it and the right vector, and that'll give me two vectors, X, and Y.  now, P+X+Y, P+X-Y, P-X-Y, and P-X+Y should, presumably, be the 4 points of my quad.So to implement billboarding without point sprites and without adjusting the view matrix for every quad I render, I'll have to solve this for every particle?  Is that an acceptable billboarding solution, or is this a really naive approach?   ;  There is a faster way of doing billboarding. Rather than have the quad face the camera, you have the quad face in the same direction (actually the opposite direction) as the camera. Using this method, you use the up and right vectors of the camera directly to determine the locations of the vertexes. It looks a little different especially near the edges of the screen, but most people don't care.Since you are probably CPU bound, you can increase throughput by putting more information into the vertex (such as the size of the particle, amount of rotation, and the offset from the center of the sprite), and moving more computation to the GPU.   ;  Hey, that's a really good idea.  I can see how it could have some real issues, especially if the field of view gets pretty big or a lot of rotation is going on, but I'll keep it in mind in case I need another speed boost.  Thanks a lot!   