Anti-Aliasing comparison tool, MK2

3 years or so back, I wrote a tool to compare anti-aliasing methods. It was designed to accompany my Beyond3D article on the topic.

The tool is still useful, but it has a few issues:

  • It’s based on raw OpenGL code, which means that it’s hard to extend, and somewhat likely to break on driver updates.
  • For the same reason, it’s slightly more difficult to ship without dependencies.
  • It doesn’t offer any temporal anti-aliasing technology, which is currently where much of the most interesting research is happening.
  • Its user interface is terrible, and it doesn’t guide people in any way in terms of interpreting what they see.

To solve these issues, I implemented a very similar tool in Unity.

You can get it here.

It features a whole lot of information about the various AA types it supports in tool-tips, and also includes the currently-in-development Unity temporal anti aliasing.

aatest_2016_10_08_21_22_34_955 aatest_2016_10_08_21_23_02_960 aatest_2016_10_08_21_22_48_516If anyone is interested in the sources I can release them, it’s pretty basic and mostly boring UI stuff.

Article on “Optimization” for PC Gamer — Bonus Content

I wrote an article about “optimization” for PC Gamer. It doesn’t actually talk about the process of optimization all that much (it’s supposed to be understandable for a general audience), but it does touch on topics that I consider really important, like the fact that a game should never be considered “less optimized” for including higher-end settings.

It also gave me an opportunity to get some feedback on various topics from Croteam and Q-LOC, which was great. I couldn’t put all of it into the article, so here are a few more tidbits that stuck with me — not nearly in as organized a presentation as they should be:

  • Croteam’s Dean Sekulic talking about driver optimization as “pure magic”, and cautioning people to think twice before complaining about driver quality. I’ve said before that I imagine GPU drivers to easily be amongst the most complex software projects out there these days, between the strict performance requirements, massive feature sets, and compatibility/regression nightmare in both hardware and software.
  • He also told me that he’s prefer a single-core 10 GHz processor to anything else out there these days, and that multi-core parallelization is a “necessary evil”. It’s also a major part of my day job, and I agree with him.
  • One topic I originally wanted to include in the article but omitted was dynamic image quality scaling. QLOC had considered it before, but both them and Croteam seemed concerned about player feedback and potential controversy. It also seems like both only really conceptualized it so far for scaling down to prevent framedrops on lower-end hardware, but not really for scaling up. IMHO it’s a bit of a shame that something as potentially useful as this is being held back at least partially due to fear of controversy — an optional feature should never be controversial.
    That said, both seemed open to experimenting more with it.
  • I also talked shortly to Dean about forward vs. deferred rendering, and the fact that the former seems to be making a bit of a comeback especially in the VR space due to MSAA. He is a huge fan of MSAA and considers it great bang for the buck as far as AA techniques go – their engine is based on forward rendering.
  • A topic QLOC mentioned was the difficulty of porting games designed for 6-7 cores (even if they are slower) to a dual core CPU (as those are still frequently targeted as minimum specs. We didn’t go into further detail on this but I wonder if they think SMT helps in that case.
  • Another interesting point they raised about ports is console games assuming the same deterministic math behavior across systems. This can obviously lead to desynchronization issues in online games when identical behavior is not a given. I’d have thought that modern physics engines — probably being multithreaded — couldn’t assume 100% deterministic results anyway, but then again, another issue they brought up is outdated middleware.
  • Talking about long-term software maintenance, Dean mentioned that their last full recode was in 2004 — and that he’d never want to do that again. I can empathize with that, having been more or less in charge of a decent scale software project (a few 100k LOC) for some years now, and pushing through a complete rewrite of just one major component in that timeframe.
  • A great point which I found amusing that he brought up was categorizing graphics effects into “game effects” and “screenshot effects“. This is based on their cost/benefit ratio, and he tells me that at Croteam they try to focus on actually usable game effects while circumventing anything too expensive a priori.
    I think that’s a good approach, though I’d add that yesterday’s screenshot effects can be today’s game effects.
  • In addition to dynamic quality scaling, another topic originally planned for the article was GPU vendor specific features, APIs and effects. While quick to point out that a good relationship with the GPU vendors is extremely helpful for their technical expertise, everyone also seems apprehensive about using such technology directly, especially so as not to annoy gamers with different hardware.
    Dean told me however that he will use this type of technology if it has a significant advantage and ideally exists on both sides of the fence, and specifically mentioned VRWorks and LiquidVR as a good example of that.

Finally, a concept that QLOC referred to indirectly and Dean brought up on his own is fluidity, and that it is still harder to attain than it should be. Croteam have been working on that topic for a long time, and still wish there was more support from the APIs on that. I’ve written a bit about frametime consistency before, but maybe it would be a nice topic for an entire article.

Aliasing and Anti-aliasing Comparison Tool

ss_2013-12-24_20-32-42This is a tool for illustrating the various types of aliasing which can occur in computer graphics, and how many common methods of anti-aliasing interact with them. I wrote it to accompany an article which will be published some time in the future, and which contains a rather detailed treatment of the topics of aliasing and anti-aliasing.

A main point is to also show aliasing (that is, flickering and image instability) in motion, which is insufficiently captured by the common screenshot or (compressed) video comparisons.

There are 6 types of aliasing shown (transparency aliasing, geometry aliasing (2D and 3D), sub-pixel aliasing, texture aliasing and shader aliasing), and many methods of anti-aliasing are available.

ss_2013-12-24_20-44-07The 1-8 keys are mapped to presets which show some common anti-aliasing methods:

  1.  none
  2. 4x MSAA
    multisampling, generally sparse grid
  3. 2×2 OGSSAA
    ordered grid supersampling with 4 samples
  4. 4x SSAA
    turns the 4 multisamples into supersamples, thus 4x SGSSAA on most HW
  5. FXAA
    just post-processing, see sub-pixel effects
  6. SMAA
    as above (note better motion stability)
  7. 1.5×1.5 OGSSAA + SMAA
    similar to what can be achieved via injection in most games, often decently playable
  8. best
    maximum number of SGSSAA samples plus 2×2 OGSSAA. Close to the “ground truth”, that is the perfect representation of the scene on the pixel grid

Let me know if anything breaks. I do know that the PXAA and TPXAA PPAA methods don’t work on AMD, if anyone wants to help fix it (and has the time) contact me and provide some means of synchronous communication (e.g. Steam ID).

Source code release soon.

Download here!

(If you encounter an error about missing some .dll when running the program, get the Microsoft C++ redistributable here)

(Edit 2014-1-14: updated to fix an issue which could occur with some AMD drivers)