Hello everybody,
I want to draw lines and points on a mesh using primitive Point and Lines.
I also want that the drawn points and lines overlay the mesh upon which they are drawn. (Points have the coordinates of a vertex of the mesh, lines are made of a series of vertices from the mesh)
And finally I still want that the culling works, in this case, when the lines are hidden behind a part of the mesh.
I would like to make something that looks like this :
(This was made using spheres instead of simple points, which is not the solution I want because then the points have a fixed size in the environment and not in pixels)
I am using OSG
Any advice on what may work to create this effect?
Draw the overlay last with a depth function of GL_LEQUAL. Use glEnable(GL_POLYGON_OFFSET_{FILL,LINE,POINT}) and glPolygonOffset to force the overlay to be slightly in front of the mesh. If you’re using a perspective projection, don’t use too small a value for the near plane.
1 Like
Hey, thanks for your answer, I’ll try it out tomorrow.
I remember reading in a few places that glPolygonOffset doesn’t apply to overlay that are defined as purely POINT or LINE. Did I misunderstand?
It’s all quite new to me, though I find it very interesting!
Right. If you’re directly rendering points or lines (rather than using glPolygonMode), you need to apply the offset yourself.
This can be done either in the vertex shader or by modifying the projection matrix. In terms of the math, you want to add a negative constant to the Z coordinate in NDC. With the fixed-function pipeline, this corresponds to calling glTranslatef(0,0,-d) before calling glFrustum/gluPerspective/etc (while glMatrixMode(GL_PROJECTION) is in effect). The magnitude of the offset d should be of the order of 1/2n-1, where n is the number of bits in the depth buffer. With user-defined matrices, apply a translation to the projection matrix, with the translation on the left.
1 Like
One caveat: drawing “large” points is going to be problematic. Point sprites have a constant depth, so they’re likely to be clipped against the mesh if depth testing is enabled. To move the point far enough forward that it doesn’t get clipped requires calculating the slope of the polygons which are immediately behind it. A similar issue applies to “wide” lines, where the depth is constant along the line perpendicular to the rendering direction.
This can be avoided by disabling depth testing and sorting the polygons in depth order, but that’s a rather involved (and computationally expensive) process for an arbitrary mesh. A less expensive (but potentially just as complex) option is to enable depth tests and depth writes for polygons which don’t have points or lines attached to them, while depth-sorting the polygons with attached points and lines and rendering those (along with the points and lines) in depth order (from back to front) with depth testing enabled but depth writes disabled.
1 Like
