Hello!

I'm drawing many thousands of points to the screen using
glBegin(GL_POINTS), then drawing all the points, and firing glEnd.

I currently use glPointSize before the drawing, to set the size of the points.  But I'd like to set the size of individual points.

Naturally, I can't change the point size from inside of the glBegin section.  So to change the size, I fire glBegin before drawing _each individual point_.  This has a drastic negative effect on the performance of the application.

I'm trying to simulate 3d positioning of these points by changing the scale of each one, individually.  Essentially I want a fast way to draw many points in 3d, with some visual representation that the points are, in fact, 3d (i.e. scale)

I'm looking for a best-practice, or decent alternative, to the scenarios I mentioned above.  Does anyone here know of such a solution, and would you be willing to explain it?

As an aside, does anybody know if performance will increase by porting the application to C/C++ and using the raw OpenGL API?

Thanks in advance ladies and gents

Hi James, a few thoughts on the matter:
- you could keep all the points the same size and try using glColor to color the points with the further ones being closer to your background color (i.e. fog). This will also give the impression of 3D.

- VBO's are probably your best bet for best performance, nice info on them here http://www.ozone3d.net/tutorials/opengl_vbo.php

I can say even if you do optimize your java/processing app by whatever means, porting your app to C++ will probably make a massive difference. I ported this app http://www.memo.tv/psychedelic_fluids_and_particles_with_processing (which was using the openGL renderer, and already pretty optimized) to C++ and just with a simple port the framerate went from 22fps to 50fps. Likewise I've compared the framerates from the apps at http://www.memo.tv/radiohead_house_of_cards_openframeworks_templates and again the c++ versions are about double. So if you are trying to squeeze as much juice as possible, then C++ is definitely the way to go. But if you aren't fluent with C/C++ then be prepared for longer development time!
 
P.S. of course depending on your specific needs, most probably the fastest performance will come if you can write the app as vertex and/or fragment shaders to run on the GPU and use a pretty recent graphics card!

this is a very specific case where c++ will be noticeably faster than (the current implementation of) processing. the problem is that if you're changing the points every single time, that means you have to make a lot of glXxxxx() calls, and that's a lot of overhead. for instance, you'd probably get a similar framerate if you were calling glRectf or even a more complicated shape, because nearly all the time loss is in the overhead--not the drawing.

each glXxxxx() call that you make, there's some speed loss as it jumps from java to native. this is part of why vertex buffers and call lists speed things up so significantly--because there are less calls to over to opengl from java to draw them. (they speed up c++ code too, but the performance difference w/ processing is even more significant).

Quote:

That worked well, mission accomplished.

For others with a similar question, I used:

float attenuation[] = {1.0f, -0.01f, -.000001f};
gl.glPointParameterfv(gl.GL_POINT_DISTANCE_ATTENUATION, attenuation, 0);

I believe the actual formula used is similar to this:

s = p * sqrt(1 / (a + b * d + c * d ^ 2))

With default values of a = 1.0f, b = 0.0f, and c = 0.0f

Where,
 s is the size that the point will be drawn as.
 p is the size of the point set by glPointSize().  The default attenuation formula is essentially s = p
 d is the distance from the viewer.