View Full Version : glPointParamter coefficients

08-05-2010, 11:03 AM

I am trying to use glPointParamterf to have a nice points-get-smaller-further-away effect, and it is actually working -- however it seems to clobber my point size to a large extent.


I am using GL_POINT_DISTANCE_ATTENUATION , and I want to know if there is any more documentation anywhere on what the array of coefficients actually means.

I end up doing something like

const float glPointParams[3] = { 1.0, 0.5, 0.0 };
#ifdef GL_VERSION_1_4
glPointParameterfv(GL_DISTANCE_ATTENUATION_EXT, glPointParams);

for(unsigned int ui=0; ui<pts.size(); ui++)

But it seems that size has very little influence on the actual point size if I don't comment out the glPointParameterfv call.

Any suggestions?

Serge K
08-05-2010, 06:12 PM
glPointParams[3] = { a, b, c };
// distance in eye coordinates
size = point_size / sqrt(a + b·distance + c·distance²)
GL_EXT_point_parameters (http://www.opengl.org/registry/specs/EXT/point_parameters.txt)

08-06-2010, 08:15 AM
Another factor influencing this may be the max point size supported by your implementation (glGetIntegerv with GL_POINT_SIZE_MAX). To be honest I would use textured primitives instead of point parameters these days for a number of reasons: Point parameters are not guaranteed to be implemented in hardware. Using point parameters, when you hit the max point size points will actually appear to shrink (they don't, they just get capped) as they get closer to the camera). You don't have control over what the implementation is doing behind the scenes, and - even if supported in hardware - it may not be taking an optimal path.In one test I ran, a direct head-to-head comparison showed that textured primitives (triangles, via an indexed vertex array) ran twice as fast as point parameters. This is not the case on all hardware of course, and your own mileage probably will vary, but for the other factors - especially the absense of an upper size limit - I would still recommend textured primitives.