If you want to reduce fill you could use quads like everyone else does. In fact, I think that should cut it in half, and one more vertex per particle isn't the end of the world.
EDIT: And if your using glBegin and fillrate limited then you certainly aren't near the limit when it comes to vertices.
Large triangle/ slow fillrate?
Quote:Original post by RAZORUNREAL
If you want to reduce fill you could use quads like everyone else does. In fact, I think that should cut it in half, and one more vertex per particle isn't the end of the world.
erm, why would sending quads help?
he is still going to be filling the same screen space...
Hmmm, the biggest problem you can have with a particle system is fill-rate, if the system is to close to the camera you have massive fill-rate issues, you can see this even in big titles some times. As for things I see you can improve to just help with general performance.
For best performance you should use Varrays, or at least stop calling glbegin/glend for every single particle/poly, that can really hurt performance.
Also are you calling your gltexParameter every frame? Those are applied to textures, once done; you don’t have to keep doing them. So just do that when you load the texture, I might have misunderstood?
While on the note, if you are changing state on every polygon this can also cause slow downs
The most ideal way to do things would be to setup all states, create all geometry(given that its dynamic), give opengl all the geometry, and then move on, that way you spend the least amount of time on the transfer to opengl.
If you had static geometry you would want to move the create geometry to your loading routines.
Maybe that helped some.
For best performance you should use Varrays, or at least stop calling glbegin/glend for every single particle/poly, that can really hurt performance.
Also are you calling your gltexParameter every frame? Those are applied to textures, once done; you don’t have to keep doing them. So just do that when you load the texture, I might have misunderstood?
While on the note, if you are changing state on every polygon this can also cause slow downs
The most ideal way to do things would be to setup all states, create all geometry(given that its dynamic), give opengl all the geometry, and then move on, that way you spend the least amount of time on the transfer to opengl.
If you had static geometry you would want to move the create geometry to your loading routines.
Maybe that helped some.
Whats your z buffer set to? If its off I suppose its concievable that each triangle it filling the screen. Having it set to only draw triangles that are greater than whats in the zbuffer might help.
Jason
Jason
Quote:Original post by phantom
erm, why would sending quads help?
he is still going to be filling the same screen space...
Well, he said the particles are small triangles, so assuming he is using "round" particles and draws them on triangles, then quads would be a better fit and waste less fillrate. If my naive drawing of a sphere in a triangle and a square isn't too far off, then he is right about a triangle filling twice the area and wasting twice as much fillrate (without alpha testing, of which I hope it would at least terminate a bit earlier). I suddenly remembered another opportunity of someone using single triangles, thinking it would be very clever as it's using only half as many triangles, ignoring that polycount is the lesser problem and his "solution" to a non-existant problem just made the actual problem twice as bad.
Even I think the problem is with the fill rate. The rasterization process is taking too much time to redraw the particles at a bigger size compared to a smaller size. It makes logical sense when you have a low performance graphics card. The speed of the rasterization process totally depends on your graphics card. By what you are saying, if just increasing the size of the polygon is making an performance drop, then it could be a slow graphics card issue.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement