Thaumaturge
|
|
« on: May 31, 2017, 09:47:52 AM » |
|
For a while now, I've been using my chosen engine's internal antialiasing for my current game project. It seemed to work well, and there didn't seem to be a major performance impact. I believe that the specific antialiasing technique used is multi-sampling. The engine in question is Panda3D.
Recently, however, I discovered while doing some performance tuning that (A) antialiasing no longer seemed to toggle from within the game, and (B) that I did get a significant performance gain by disabling the request for the main window to be multi-sampled.
Issue (A) seems as though it may be a driver-related issue: If I request a multi-sampled buffer, and allow for antialiasing in the NVidia control panel, I get antialiasing--regardless of the engine-provided method that's supposed to toggle it. If I don't request such a buffer, or disallow antialiasing in the control panel, I (understandably) don't get antialiasing.
This might not be a major problem if not for issue (B): it seems to me that antialiasing is something that I want to be able to toggle in the graphics options, and I want that toggling to be effective in terms of performance gain (where appropriate).
As far as I see, changing whether or not the main window's buffer is multi-sampled would call for reopening the window--in this case, the main program window. This seems a little drastic, to my mind. Or am I mistaken, here?
Which brings me to my core question in this thread: How do modern games generally handle changes in antialiasing settings? Do they destroy and remake their windows? Is antialiasing usually handled by a shader operating on the output of an offscreen buffer, which can thus (I imagine) be more easily swapped out? Something else that hasn't occurred to me?
|
|
|
Logged
|
|
|
|
missionctrl
|
|
« Reply #1 on: May 31, 2017, 05:59:59 PM » |
|
Different drivers/cards/platforms handle internal AA differently so you are likely to see inconsistencies.
You are correct about the offscreen buffer. It's a pretty standard industry method. Create an offscreen buffer that is twice as big as your screen. Draw your scene into this buffer, and then use the output as a texture to draw a single fullscreen quad. The hardware will handle the resampling.
I can't speak to other hardware implementations, but the iPhone's internal AA never works as well for me. Plus, with this method, you can modify the shader to add post-effects.
|
|
|
Logged
|
|
|
|
GrumpyGiant
|
|
« Reply #2 on: May 31, 2017, 08:45:49 PM » |
|
Create an offscreen buffer that is twice as big as your screen. Draw your scene into this buffer, and then use the output as a texture to draw a single fullscreen quad. The hardware will handle the resampling.
Noooo never do that! OK it'll work fine if your game isn't doing much with the GPU, but for any graphic-intensive game you're just slowing the whole thing down by running the pixel shader several times more than you should.
|
|
|
Logged
|
|
|
|
missionctrl
|
|
« Reply #3 on: June 01, 2017, 02:43:31 AM » |
|
You have a point. My method is technically a form of SSAA, not MSAA. The difference being that SSAA will anti-alias every pixel on the entire screen, whereas MSAA is selective and will generally only anti-alias the pixels along edges.
Back to the original question - I think the problem might be in your implementation of the toggling. Are you trying to do a realtime toggle by creating 2 sets of FBOs and switching between them? I don't think this will work the way you'd expect. You probably need to restart your OpenGL context and recreate new FBOs.
|
|
|
Logged
|
|
|
|
Thaumaturge
|
|
« Reply #4 on: June 01, 2017, 10:22:40 AM » |
|
Back to the original question - I think the problem might be in your implementation of the toggling. Are you trying to do a realtime toggle by creating 2 sets of FBOs and switching between them? I don't think this will work the way you'd expect. You probably need to restart your OpenGL context and recreate new FBOs.
The toggling is a feature provided by the engine (Panda3D); I haven't looked into the underlying code, as far as I recall. That said, you say that recreating the frame-buffer is the way to go about this? That might be worth looking into; speculatively, it might be worth rendering to an off-screen buffer so that recreating the buffer doesn't call for recreating the main window--but that's something to research (or ask after), if I follow this route, I think.
|
|
« Last Edit: June 01, 2017, 10:32:20 AM by Thaumaturge »
|
Logged
|
|
|
|
powly
|
|
« Reply #5 on: June 07, 2017, 07:27:26 AM » |
|
That's most likely the best way forward. An offscreen buffer for geometry passes is quite standard, as you might want to shade or post process them after the fact. Create an offscreen buffer that is twice as big as your screen. Draw your scene into this buffer, and then use the output as a texture to draw a single fullscreen quad. The hardware will handle the resampling.
Noooo never do that! OK it'll work fine if your game isn't doing much with the GPU, but for any graphic-intensive game you're just slowing the whole thing down by running the pixel shader several times more than you should. Not "never"; this kind of brute force super sampling also supersamples your shader so if you can't prefilter properly it might be the only way to obtain temporal stability.
|
|
|
Logged
|
|
|
|
Thaumaturge
|
|
« Reply #6 on: June 07, 2017, 03:27:09 PM » |
|
That accords with the advice that I've been given elsewhere, I believe. Fair enough, then, and thanks! ^_^ (I'm not currently doing any post-processing, although I've given it some thought.) Not "never"; this kind of brute force super sampling also supersamples your shader so if you can't prefilter properly it might be the only way to obtain temporal stability.
"Prefilter"? Is this a step that's called for before use of multisampling...?
|
|
|
Logged
|
|
|
|
powly
|
|
« Reply #7 on: June 08, 2017, 10:55:43 PM » |
|
"Prefilter"? Is this a step that's called for before use of multisampling...?
No, it's more general and refers to removal of frequencies that are too high for the visibility sampling rate, like MIP mapping. If you have a black and white checkerboard pattern, without any prefiltering you'll get essentially random black and white pixels far away from the camera when the pattern is small compared to the pixel size, with prefiltering you'll get gray (the average) as you'd probably like to. For some procedural stuff this might be hard to do; then the only possibility is to increase the sampling rate instead. This is when you want supersampling (larger buffer and averaging) instead of multi sampling (only one shade per pixel per shader but multiple visibility samples to determine the weights for the shade values).
|
|
|
Logged
|
|
|
|
Thaumaturge
|
|
« Reply #8 on: June 09, 2017, 09:49:20 AM » |
|
Ah, I see--that makes sense, I believe! Thank you for the explanation! ^_^
|
|
|
Logged
|
|
|
|
|