Hey, it’s ya boy Shark here with some good news! Despite not feeling the greatest about it, I got 87% as my grade for my Game Engine Design coursework on Doom 3 modifications and Python bots! 😀 It was a pleasant surprise to start last week with to say the least!
Anyway on Friday night, I submitted my first Real-Time Rendering Techniques coursework! This module focuses on teaching us graphics programming in OpenGL (as a successor to last year’s Computer Graphics module) and DirectX without the aid of an engine like Unity or Unreal. This coursework was centered around implementing and comparing supersampling anti-aliasing (SSAA) and multisampling anti-aliasing (MSAA). So today I’m gonna be talking about what aliasing is, what those two things are, and the conclusions I drew!
Please note that there will be no code samples below due to this being a recently submitted coursework. This post assumes basic understanding of the topic (like knowing what anti-aliasing is as a game setting or something), but if you don’t have that this still might still be an interesting read!
The problem of aliasing
As defined, aliasing is when signals become distorted when they are sampled. In context for this post, graphical aliasing is the occurrence of image artifacts that produce a stair-like or jagged edge around objects rendered on screen. This is particularly a big problem for computer games since aliasing can make otherwise stunning scenes look too digitised and break the game’s immersive potential.
The easiest way to recreate this effect for yourself is by viewing an image with lower resolution than the computer’s display and stretching it out (so long as the image viewer itself doesn’t anti-aliase) or zooming in on it. Lines will become jagged and any quality of the image will be ruined. Unfortunately no perfect solution exists due to the fact that the detail on any given image will be represented on screen by pixels (which are just really small blocks of colour). However, we can at least mitigate this issue with anti-aliasing!
The assignment called for us to implement and compare two examples of anti-aliasing; supersampling anti-aliasing (SSAA) and multisampling anti-aliasing (MSAA). Both of these techniques are varied in age, implementation difficulty, and performance characteristics. As defined, anti-aliasing is literally the process of diminishing aliasing.
SSAA is perhaps the oldest and most primitive anti-aliasing technique, which has long been abandoned due to high performance requirements and lack of built-in implementation in frameworks such as OpenGL. Supersampling involves telling your code to render the scene (what you’re looking at whilst playing the game) at a higher resolution than the display and compressing it down into the display’s resolution. The latter process, known as downsampling, works by averaging the colour of each pixel with some of it’s neighbours in a ratio like X4. In a X4 scenario, the scene would be rendered four times bigger than the display’s resolution setting and then subsequently averaged in blocks of four pixels during downsampling. You’ve probably observed downsampling yourself when resizing an image or photo to be smaller than it originally was
MSAA is a newer technique that, whilst it is still not the best technique available, is relatively popular. Unlike SSAA, MSAA does not require the program to render the scene at a higher-than-display resolution. Instead, the algorithm behind it samples two or more adjacent pixels as it during runtime.
I produced some side-by-side screenshots to show the differences in performance and effect before and after enabling the respective techniques. The testbed was a university lab machine powered by an NVIDIA GeForce GTX 980 Ti. The scenario consisted of extremes, with a low resolution of 640×480 and an AA-on sample size of X16. The resolution was originally supposed to be 1920×1080, but attempting to use X16 SSAA at that size caused lots of issues relating to memory.
The SSAA scene is full of spheres, and the MSAA scene is full of pyramids. Ideally the scenes should have been the same, but the coursework demanded different scenes with one being FBO-powered and the other one on the default framebuffer (or a similar combination/configuration). In terms of vertex count though, both were similar (there were a lot more pyramids in the MSAA scene to compensate for the large meshes for the spheres).
The combination of rendering higher than the display’s resolution and downsampling the result was not very performant, as we see here. The 640×480 resolution (307,200 pixels) results in the scene being rendered at 10240×7680 (78,643,200 pixels)! The framerate drop from being capped at 60FPS (due to v-sync, whoops) to ~17.5!
MSAA fairs far better by a long margin with the FPS bound only by v-sync (I really should have turned that off). The anti-aliasing effect looks about as good as SSAA as well, so win-win?
And that’s the conclusion; summarising why MSAA is considered better! My cohort was however slightly divided on which one actually looked better. Personally I found that at X16, their effectiveness looks about the same but at X2, SSAA might look slightly better. The resources you save on using MSAA will compensate for this by allowing you to sample at a much higher rate anyway, however!
- “What is Aliasing?”
- Written by Techopedia
- “Anti Aliasing”
- Written by Learn OpenGL
Other blog updates
Whilst I’m at it, time for some blog updates!
I’ve postponed the planned post on the most unusual ThinkPads for the time being, pending posts about my new purchases! I’ll be showcasing my machines (and keyboards) in pairs, with the schedule being the following:
- 18th January: Ultrabooks: SN-X41 & SN-X220
- 25th January: Modern: SN-L430 & SN-T430
- 1st February: Classic: SN-T41 & SN-T42
- 8th February: Keyboards: SN-KBC Compact & SN-KBB Tablet 2 Bluetooth
- 15th February: Uniques: SN-A30p & SN-R60e
And that’s all for today! Shark out!