hello,
i’m rendering 200.000 points, with a single color.
I’m using a loop on a array and calls 200.000 times a glVertex3f. With that method, i get something like 3images/sec.
I’d like to have an idea about how faster it could be if using vertex arrays ?
thanks,
Adrien
Try first to put them inside display lists so that you can have a first overview about how much performance you can get. Generally, VA and display lists are almost the same, even if VA can be best (almost with VBO).
I could have said it will be twice faster or more, but it depends almost on your graphic card.
Finally, the best thing you can do is test that !
Hope that helps you.
Originally posted by adrien:
[b]hello,
i’m rendering 200.000 points, with a single color.
I’m using a loop on a array and calls 200.000 times a glVertex3f. With that method, i get something like 3images/sec.
I’d like to have an idea about how faster it could be if using vertex arrays ?
thanks,
Adrien[/b]
Thats a very low FPS even for handfeeding the verticies using glVertex(). Are you sure you have a hardware accelerated pixelformat? Sounds like you are stuck with the software emulation layer.
Try glGetString(GL_Vendor); and see what it says.
i’ll try it, but that’s good thing to have an idea of what i could gain with that.
i made a mistake on previous post, the algo i’m looking displays 1.500.000 points at 1.35 im/secs.
My computer is an athlon 3000+ with a Geforce FX 5700.
What’s your feeling about the speed ?
it gives :
NVIDIA Corporation
GeForce FX 5700/AGP/SSE2/3DNOW!
It will most likely be faster to render very small quads (or quads formed from a triangle strip) and use VBOs or Vertex arrays. I don’t think the hardware is optimized for points. Anyway, all those calls to glVertex are killing you.
i also have the same kind of problem when displaying many bitmaps.
For example, i’m rendering 5.000 time a little bitmap at different positions.
Yet, i have a loop, setting parameters and calling each time a glBitmap.
I’ll put that in a display list (I guess that’s a good idea).
But is there a way to use arrays to specify position of the bitmaps ?
Or wWould it be faster to use billboards (3d quads facing user that i must resize to always have the same screen size) ?
thanks much for advices
Always try and avoid loops altogether for sending data and changing parameters/states.
a state change to the OpenGL pipeline forces a flush of the pipeline (this could be bad, especially in a loop where you’re rendering several similar objects).
To move a whole bunch of quads in their own way and use Vertex arrays (VBOs would gain you nothing here because you’d need to update the vertex data each frame) you can’t use the modelview matrix because each quad would then undergo the same transformation.
you need to update the vertices of the quad yourself, update the vertex array and upload the array to the board again. This may seem like a lot of work, but it would be much faster than using a for loop that runs through 5,000 quads and rendering each one piecewise.
give it a go and see.
Originally posted by adrien:
[b]i’ll try it, but that’s good thing to have an idea of what i could gain with that.
i made a mistake on previous post, the algo i’m looking displays 1.500.000 points at 1.35 im/secs.
My computer is an athlon 3000+ with a Geforce FX 5700.
What’s your feeling about the speed ?[/b]
Just out of curiosity I hacked a simple test app together its basicly 3 nested loops that generate approx. 2.5 millions verticies on the fly in a cube style fashion and handfeed them using glVertex3f() calls and draw them as GL_POINTS. I get around 20 FPS at 1280x1024 on a GF5950 + P4 2.53 Ghz with no optimazations.
Probably the way you retrieve/compute the vertex data is slowing you down. Anyway using glVertex() calls is the slowest approach one can use. Depending if the data is static or not you should experiment with VBO’s, CVA’s or display lists.
Originally posted by adrien:
Or wWould it be faster to use billboards (3d quads facing user that i must resize to always have the same screen size) ?
Definitely, you should check out the POINT_SPRITE extension:
http://oss.sgi.com/projects/ogl-sample/registry/ARB/point_sprite.txt
thanks for the test, and you’re right, problem is coming from retrieving the points, that is done in a strange way…