The 4.5 version was here for a while, but it seems like nVidia does not hassle to support it in a variety of it’s hardware. I have a GeForce GT 520 videocard and OpenGL 4.4 is still a top-version supported with the newest drivers (version 344.75). What bothers me most is that the GL_ARB_clip_control is not supported (the other extensions brought by OpenGL 4.5 are awesome to have as well, but this particular one is mostly critical for me). I know it shouldn’t matter for a cross-platform library like OpenGL, but “just in case” I will mention that I sit on WinXP32. So what should I do? Wait some more time (but how long and is there a guarantee?..) or buy a new videocard?[/QUOTE]
Thank you, [b]Aleksandar[/b]. So, there are no release drivers supporting OpenGL 4.5 at all or is it just a WinXP specific problem? Any ideas why is it so and if there is a chance the 4.5 will widespread in near future?
Is it bad to use beta drivers? I’m sure the majority of the users installs the release versions of drivers - does it mean that writing app that requires features from OGL4.5 is senseless?
No, it is not a WinXP specific problem. NVIDIA releases beta drivers with the latest OpenGL at the same time a new specification is announced. It is really great for enthusiasts wanting to try new features. But usually it requires some time for thorough testing and implementation polishing, inducing certain latency for the inclusion in the release version of the drivers. For other vendors the time could pass until the support is brought to users.
It is not bad to use beta drivers. At least on your own computer.
But don’t force others to use them, since they can be unstable or miss some functionality.
Also, it is not useless to write an application based on new features. If it runs on your computer it is just fine.
If it runs on other people computers and you can control how they manage drivers, have NV cards, presumably post-Fermi, etc., you should wait at least a year to have a proper functioning. If you write application for wider audience, well … many years could pass until many of them could try your application.
Thank you very much, Aleksandar. It is very sad to hear how long it may take for the 4.5 features to become released to users. I remember the 4.4 version took no more than a few month to replace the 4.3 version. There wasn’t much in it comparing to the 4.5 features, though. Will wait then…
[QUOTE=Aleksandar;1262755]May I ask why you are so excited with ARB_clip_control? This extension could slightly improve precision, but I can still live quite good without it.[/QUOTE]I see this extension as part of the solution of the depth-fighting problem. Here is my plan that involves this extension:
Using glClipControl(GL_LOWER_LEFT,GL_ZERO_TO_ONE) we set the clipping volume to be:
0<=Zc<=Wc
It is important that the range is not -Wc<=Zc<=Wc for the approach described below. Or it is not?.. I am confused… Somewhy I was sure it is, but now… Hm… Maybe I just confused myself…
Configure the projection matrix like this:
| f/aspect 0 0 0 |
| |
| 0 f 0 0 |
P = | |
| 0 0 0 zNear |
| |
| 0 0 -1 0 |
f = ctan(View_Angle_Vertical / 2);
aspect = Viewport.x / Viewport.y;
zNear: distance to the near clipping plane (tiny constant, like 0.0000...1).
Therefore, the depth value (assuming default direct mapping of depth values) is calculated as follows:
Depth = zNear / -z
As a result, all pixels behind the clipping plane have their depth values laying outside [0…1] region, so those are culled; for the fragments sitting on the clipping plane the depth is 1.0, for all further fragments the depth approaches positive zero.
As depth is reversed (the further the fragment the smaller the depth) we must set glDepthFunc(GL_GREATER) to make the depth test working properly.
And the final part, which brings sense to all that: we must use the floating-point z-buffer. Most values of the depth will be concentrated in near-zero region, that is why we need the help of exponential part of FP to prevent the loss of precision for near-zero values.
Using glClipControl(GL_LOWER_LEFT,GL_ZERO_TO_ONE) we set the clipping volume to be:
0<=Zc<=Wc
It is important that the range is not -Wc<=Zc<=Wc for the approach described below. Or it is not?.. I am confused… Somewhy I was sure it is, but now… Hm… Maybe I just confused myself…[/QUOTE]Oh, I finally remembered why it was so important! In the setup described above the clipping volume is limited by the area in front of the camera plane only (-z>=zNear). As the result, all clipped z values lay in [1…0) range. So there are no z values in [-1…0] range - those fragments behind the projection plane are all culled. But without ARB_clip_control the mapping of z to depth values converts [-1…1] range to [0…1] range, so depth will range from 0.5 to 1.0 in our case. This indirect mapping will result in loss of FP precision because 0.5 will be added to near-zero values of upcoming fragment’s depth, which will vanish the trick. To make it work properly we need to enforce the direct mapping, which becomes available with glClipControl(GL_LOWER_LEFT,GL_ZERO_TO_ONE).
Alternatively, the trick could be made with glDepthRange(-1,1), but unfortunately the specs says that far and near values are clamped to [0…1] range, so no hope here.
I remember the 4.4 version took no more than a few month to replace the 4.3 version. There wasn’t much in it comparing to the 4.5 features, though. Will wait then…
In the setup described above the clipping volume is limited by the area in front of the camera plane only (-z>=zNear). As the result, all clipped z values lay in [1…0) range. So there are no z values in [-1…0] range - those fragments behind the projection plane are all culled. But without ARB_clip_control the mapping of z to depth values converts [-1…1] range to [0…1] range, so depth will range from 0.5 to 1.0 in our case. This indirect mapping will result in loss of FP precision because 0.5 will be added to near-zero values of upcoming fragment’s depth, which will vanish the trick. To make it work properly we need to enforce the direct mapping, which becomes available with glClipControl(GL_LOWER_LEFT,GL_ZERO_TO_ONE).