Point sprites are good because you don’t have to calculate the vertex coords relative to the camera angle. Now only do you save time by not calculating the vertex coords, but you can make copies of the same emitter, and place them in different spots.
How do I specify texture coords for point sprites? I want to have the texture spread across the sprite, like…well, you know, like a normal particle.
I know I can use quads or whatever, but that means updating the entire buffer to face the camera every frame, and you can’t render extra copies of the emitter without updating it.
It would be nice if I could rotate the texture per sprite, but if that is impossible, I can live with just having fast particles.
Because it is a point, it can’t have anything but a solid color.
Is there any way to make quads automatically face the camera, but still stay in their same world position? The really slow part is updating the coordinates of the quads.
if you need bigger sprites you can use quads without updating them when the camera moves by using a vertex program and some additional vertex data… for example you can pass the same vertex position to all four points of the quads and then something like (-1,-1) (1,-1) (1,1) (-1,1) as another vertex attribute. then simply add this attribute to the eye space vertex position in the vertex program. then do the final perspective transformation.
But is this going to break on all non-NVidia cards?[/b]
No. That thread is fairly old. In the meantime, a cross vendor point sprite extension has been created, and it’s supported on ATI cards, too .
Note that Intel, Matrox and XGI are missing from the list. S3 is in though.
So does ARB_POINT_SPRITE actually draw sprites bigger than 64x64? This is probably what I was reading about on the front page of this site.
I believe the maximum size is a querable parameter. The issues section (which is often a great resource) for ARB_point_sprite says:
How do point sizes for point sprites work?
RESOLVED: This specification treats point sprite sizes like antialiased point sizes, but with more leniency. Implementations may choose to not clamp the point size to the antialiased point size range. The set of point sprite sizes available must be a superset of the antialiased point sizes. However, whereas antialiased point sizes are all evenly spaced by the point size granularity, point sprites can have an arbitrary set of sizes. This lets implementations use, e.g., floating-point sizes.
Based on that, I would say that you need to query GL_SMOOTH_POINT_SIZE_RANGE to know what the valid size range is.
