I’m having a problem with the GL_MULTISAMPLE_FILTER_HINT_NV in my application. When I enable it, my text output looks fuzzy, so I want to disable it during the text output. My attempt at this is done something like so:
However, this doesn’t turn off the filtering. It does turn off the other part of the AA, as far as I can tell. Is this a bug? Note that I would have expected glDisable(GL_MULTISAMPLE_ARB) to have disabled the filter hint as well. I only tried doing so manually because it didn’t. Based on the documentation of the GL_ARB_multisample extension, I originally assumed that disabling it would also disable the filter.
Is this a limitation of the hardware? Is it a driver bug? It appears to me that this value is only used during SwapBuffers, since I can disable it and it does correctly disable for subsequent frames, just not for part of a frame.
When drawing text (and other high-crispness bitmaps) you want your texture to be in GL_NEAREST interpolation mode. If that’s the case and you line vertex coordinates, texture coordinates and bitmap size up correctly, presumably the multisample locations for one pixel will all map to the same texel, and no smudging will happen.
Originally posted by jwatte: When drawing text (and other high-crispness bitmaps) you want your texture to be in GL_NEAREST interpolation mode. If that’s the case and you line vertex coordinates, texture coordinates and bitmap size up correctly, presumably the multisample locations for one pixel will all map to the same texel, and no smudging will happen.
This is true for most Multisample AA, but the nVidia advanced filter (AKA Quincunx in 2x FSAA mode, and rarely mentioned as working in 4x FSAA mode also) averages colors from adjoining pixels, which results in fuzzy text. I am using GL_NEAREST for my font drawing (as well as drawing quads that have a 1-1 pixel to texel ratio in ortho mode), but thanks for the hint.
I’m interpreting Matt’s reply as meaning that I have no real choice but to live with it.
I haven’t tried drawing the text directly to the front buffer, though (it’s only 5-20 characters or so per frame). I wonder if this would solve the problem.
Well, I checked what would happen drawing to the front buffer, and it draws like I want as long I disable multisampling and set the filter to GL_FASTEST. I do have to call glFlush() after drawing the text. With vsync turned off, it flickers rather obnoxiously, but with vsync turned on it looks fine.
I guess I’ll be looking at the WGL_EXT_swap_control extension. Now I have to decide whether I should artifically turn vsync on when the user has turned it off in the control panel or just check the value and let the text be fuzzy if vsync is turned off. I’m leaning toward the latter.
If you disanble multisample (glDisable (GL_MUTISAMPLE)) but have activate GL_MULTISAMPLE_FILTER_HINT_NV it do a litele bluring. Because disable Mutisample only make the distance between the “Pixels” to Zero the Hint make it bigger then Zero, so you have a litle Mutisampling with activate Hint but Disabled Multisampling.
With Disable Mutisample he also draw the Samples but all in the same Point. So you must alse disable the hint.
An Qestion: In all the journal there are 3 AA Methods: 2x, 2x with Quincunx , and 4x.
But 4x with Quincunx also works and look real Good, very good. In the Paper of Nvidia (Mutisample and Pixelformats) it is describe that it works. It is not offical or to slow? Why is it not promoted?
mcraighead: almost forgot: thanks for the prompt reply. It wasn’t really the reply I had hoped for, but wasn’t unexpected. Given the descriptions I’ve seen of the filter, I can well understand how it would be impossible to disable for only some primitives on the back buffer.
wedge: as I indicated in my original post in the included code sample, I am disabling the hint (setting it to fastest). The problem is that this doesn’t work on-the-fly. It only seems to work for whole frames (which is not really all that surprising).
As for the 4x + filter, I imagine that they believe the quality improvement is minimal enough to not usually justify the speed hit. Since my app is geometry bound, there isn’t really much of a speed hit, so I have it there as an option. And for what it’s worth, from the screenshots I’ve seen of the new GF4 4XS mode, it does look better than the 4x + filter on the GF3.
Shag: I actually do give the user the choice between no AA, 2x, 2x+filter (Quincunx), 4x, and 4x+filter. I just wanted the two filtered modes to look better.
I just added in code to draw the text to the front buffer when using a filtered AA mode as long as vsync is enabled. It produces crisp text with no flicker.
The problem is that this doesn’t work on-the-fly. It only seems to work for whole frames
are you sure, i never tryed to disable, but this is could make problems by us.
As for the 4x + filter, I imagine that they believe the quality improvement is minimal enough to not usually justify the speed hit.
In my opinion is a big quality difference between 4x and 4x + filter. Especially if you have geometric APS. OK in colorful games it can be minimal. g
wedge
Here is a part from the spec, that could clear things up, about on the fly switching:
When does changing the multisampling filter hint take effect?
RESOLUTION: It may not be until the next swap buffers or glClear
operation that the multisample hint actually takes effect.
This may be implementation dependent.
The 2-sampling (glEnable(GL_MULTISAMPLE_ARB)) controls trinagle rasterization behaviour. Quincunx (sample averaging from neighbourhood pixels) is implemented as a full window 2d post-process (done when you swap buffers). This is the reason you cannot turn off the second for parts of the scene.
While on the subject…
swap-buffers really does two operations here: sample averaging (even without Quincunx), and buffer swap (back-buffer to visible buffer copy). But the correct sequence relative to vsync, is to split it in two – sample averaging should be done before the vsync, and the copy should be done immediately after it (so it is ‘hidden’ in the vertical blanking period).
I tried to do it myself, without success. Calling glFinish() (before the vsync) indeed averages the samples, but a swap-buffers immediately following it averages the samples again! (before the copy). (even a glFinish immediately following a glFinish does this…).
I cannot find a way to work around this with the current driver. I have two solutions in my mind (for nVidia to implement, not me…):
Have some kind of ‘dirty bit’ on the window, so a glFinish will average the samples, and an immediately following swap-buffers will know not to repeat the operation. (this doesn’t require new extension)
expose a “completely resolve” function. This is quite similar to glFinish, except that it doesn’t block the caller
And here is another part from the spec (although at this stage, it doesn’t add any new information…)
While not quite consistent with the way ARB_multisample is specified, NVIDIA uses the SwapBuffers operation as a trigger for downsampling multisample sample buffers (other operations such as glReadPixels also trigger downsampling).
Originally posted by la_chose: tcobbs:
Have you thought about rendering your text to a pbuffer?
No, but I’m not sure how that would help things. I’d still have to transfer it to the main rendering context at some point, and it would then be filtered, just like it is now. Unless you mean rendering to a pbuffer before the SwapBuffers and then transfering it to the front buffer afterwards?
