Hi all,
I want to render points using a specific size with OpenGL 3.1 / GLSL 1.4. If I enable GL_POINT_SPRITE and using backward compatibility, gl_PointCoord gives me valid values. But, as enabling point sprites is deprecated, how do I get valid values in gl_PointCoord? Is there a bug in the driver (latest NVIDIA): The spec says “Point rasterization is always performed as though POINT_SPRITE were enabled.”. But it doesn’t seem so …
Any help?
Regards Norbert
Try enabling GL_VERTEX_PROGRAM_POINT_SIZE, set gl_PointSize in your vertex shader, then specify your points normally. Works just dandy for me (Vista32/G80-190.38).
Thanks for your help.
I already enabled GL_VERTEX_PROGRAM_POINT_SIZE and this is not the problem. The points do have the wanted size. The problem is, that gl_PointCoord is not correctly set, which I need e.g. for texture mapping.
Any more help or any solutions?
Did you specify
#version 140
in your fragment shader?
Yes.
I can’t seem to reproduce the problem you are having. You do realize that gl_PointCoord in strictly a FS input? I’m sure you do but it wasn’t entirely clear from your first post.
Just so we’re on the same page, you enable both GL_POINT_SPRITE (for texture coordinate generation) and GL_VERTEX_PROGRAM_POINT_SIZE (so that gl_PointSize is respected). Otherwise I’m at something of a loss for recommendations. Could there be trouble with your textures?
Incidentally, you can verify that your texture coordinates are being generated correctly by setting your output FragColor to vec4(gl_PointCoord.st, 0, 1); This should produce black in the top left corner and yellow in the bottom right (unless POINT_SPRITE_COORD_ORIGIN is set to LOWER_LEFT).
Well, everything is working fine (if I enable GL_POINT_SPRITE) with a backward(!) compatible context. Then gl_PointCoord delivers me correct values. But if I do have a forward(!) compatible context, then glEnable(GL_POINT_SPRITE) is deprecated:
“Non-sprite points - Enable/Disable targets POINT SMOOTH
and POINT SPRITE, and all associated state. Point rasterization is always
performed as though POINT SPRITE were enabled.”
So in this case, I can not enable point sprites and I expect, that they are already enabled, right?
Right now, I am pretty sure this is a bug in the driver.
That could very well be. I haven’t done any testing with forward compatible contexts. Are you getting any errors?
Well, if I try to enable point sprites in the forward context, it does report an invalid enum (which is ok). I guess, what is missing, that when creating the forward compatible context, the point sprites are not “enabled” by default. I have posted this issue also on the NVIDIA developer site. Let’s see what they respond …
For what it’s worth I can confirm what you’re seeing in forward-compatible mode. (On a hunch that it’s texture related I discovered that TexParameterf with TEXTURE_LOD_BIAS is generating an INVALID_ENUM, unrelated though that may be).
> I guess, what is missing, that when creating the forward compatible context, the point sprites are not “enabled” by default.
Thanks McNopper. We’ve confirmed that this is a driver bug indeed. It’ll get fixed.
Regards,
Barthold
(with my NVIDIA hat on)
Do you get that error in a forward compatibility context? If so, that is correct. TEXTURE_LOD_BIAS has been deprecated and removed. See appendix E in the OpenGL 3.1 specification.
Regards,
Barthold
(With my ARB hat on)
My apologies. That was in a FC context.
looks like i’m a bit late to the party, but i’m seeing this bug too in a fairly recent Linux driver:
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 460/PCI/SSE2
OpenGL version string: 4.1.0 NVIDIA 260.19.06
OpenGL shading language version string: 4.10 NVIDIA via Cg compiler
so far i’ve only been working in a 3.2 core context, but i’ll try the compatability context workaround. barthold, any idea if the fix should have made it to the Linux drivers by now? it’s possible i’m just doing something dumb, but this code worked just fine on the ATI Catalyst drivers…