Ambient Occlusion Explained: SSAO vs HBAO vs GTAO (2026 Guide)

Introduction

Ambient occlusion is one of those rendering concepts that everyone has seen on screen for over fifteen years and almost nobody can define cleanly. Open a game settings menu and you will likely find an "Ambient Occlusion" toggle with options labelled SSAO, HBAO, or GTAO. Open Blender, Cinema 4D, or 3ds Max and you will find an AO pass buried in the render settings. The screenshots all look slightly different, the performance hit varies by an order of magnitude, and the documentation rarely explains the trade-off.

At Super Renders Farm we have been running distributed CPU and GPU rendering jobs since 2010, and ambient occlusion shows up in roughly half of the support tickets we see for archviz and product visualisation work. The pattern is consistent: artists either over-rely on AO as a shortcut for global illumination, or they switch it off and end up with floating geometry that looks unanchored from the ground. Both failure modes are fixable once you understand what AO is actually computing.

This guide explains ambient occlusion from first principles, walks through the three real-time algorithms most engines ship in 2026 (SSAO, HBAO, GTAO), and looks at when AO baking is fast enough to keep on a single workstation versus when it belongs on a render farm. Read the FAQ at the bottom for quick answers to the questions we get most often.

What Ambient Occlusion Actually Is

Ambient occlusion is a shading technique that approximates how much ambient light reaches each point on a surface by checking how much that point is "occluded" by nearby geometry. A corner where a wall meets a floor receives less ambient light than the open middle of the same floor, because the corner has more geometry blocking incoming rays from the upper hemisphere. AO darkens the corner. That is the whole effect.

The reason AO became ubiquitous is economic. A full global illumination solve — bouncing light off every surface and integrating it correctly — is expensive. AO captures one specific component of GI (the local self-shadowing of ambient/sky light) very cheaply by sampling rays only a short distance from the shaded point. In offline rendering you usually want full GI; AO is then either disabled or used as a subtle contact-shadow enhancer. In real-time rendering AO has historically been the only feasible approximation of indirect shadowing, which is why every game engine ships at least one AO algorithm.

A few common misconceptions are worth clearing up:

• AO is not a shadow from a light source. It darkens regardless of where the lights are placed, because it represents occlusion of the entire ambient hemisphere.
• AO is not global illumination. Real GI accounts for indirect light bouncing colour and brightness; AO only darkens. Using AO as a substitute for GI is a common cause of muddy archviz renders.
• AO is not automatically physically correct. The result depends entirely on the algorithm and the maximum ray distance you set. Crank the radius and a clean interior will turn into a dirty cave.

The Blender manual covers the offline AO node in its documentation on the Ambient Occlusion shader, which is a useful reference if you want to read the actual math behind the sampling.

SSAO vs HBAO vs GTAO: Three Algorithms, One Effect

The three algorithms you will see in 2026 game engines all aim at the same visual goal but trade differently between speed, quality, and view-direction stability.

NVIDIA's original Image-Space Horizon-Based Ambient Occlusion paper is still the canonical reference for the horizon-based family, and Activision's Practical Real-Time Strategies for Accurate Indirect Occlusion (GTAO whitepaper) covers the GTAO derivation that AMD and Intel later adopted.

A useful mental model: SSAO is a fast hack with visible artefacts; HBAO is a smarter hack that knows about geometry; GTAO is calibrated against an offline reference and is what you want when you can afford it. On any modern GPU released in the last three or four years, all three are essentially free at 1080p — the choice is about quality and motion stability, not frame rate.

A separate lineage exists for ray-traced AO (RTAO), which uses the GPU's hardware ray tracing units to fire actual rays per pixel. RTAO is what you switch to when you have ray-tracing budget left over after reflections and shadows; it is the closest thing to "ground truth" in real time, but it is not yet the default in most engines because of the cost on lower-tier GPUs.

Should You Turn Ambient Occlusion On or Off?

This is one of the most common search queries on the topic ("ambient occlusion on or off") and the answer depends on what you are doing.

For gaming, AO is almost always worth keeping on. The visual lift from grounded contact shadows under furniture, vegetation, and characters is significant, and on hardware released since the RTX 20-series the cost is low single-digit milliseconds. The only situation where switching it off helps is on a much older GPU running a high refresh-rate monitor, where every millisecond matters.

For real-time previews in DCC software (Eevee, Cinema 4D viewport, 3ds Max viewport), AO is useful for blocking and lighting decisions but should not be relied on for final image judgment. Viewport AO is usually a low-quality SSAO approximation. We have seen artists make lighting decisions based on viewport AO that disappear in the final render.

For final offline rendering (Cycles, V-Ray, Corona, Arnold, Redshift), the answer is more nuanced. If your scene uses a full GI solve — Cycles path tracing, V-Ray brute force or light cache, Corona's path tracer, Arnold's GI — then AO is already implicitly accounted for in the indirect lighting and adding an explicit AO pass usually makes the image darker than it should be. If you are working in a stylised or NPR pipeline where physically accurate GI is not the goal, an explicit AO pass can add useful contact darkening; bake it as a separate render element so you can tune the contribution in compositing rather than baking it into the beauty.

The short answer: leave it on in games, leave it off as a final-image effect when you have full GI, and bake it as a pass when you need stylised control.

Ambient Occlusion in Games vs Offline Rendering

There is a structural difference between AO in real-time engines and AO in offline renderers that is worth making explicit because it explains a lot of the confusion.

Real-time AO operates on the depth buffer. The engine has already rasterised the scene, has per-pixel depth (and usually normals), and the AO pass walks neighbouring pixels in screen space to estimate occlusion. This is fast but has two structural limitations: anything off-screen does not contribute to occlusion (so a wall just outside the camera frustum will not darken the corner of a visible object), and the sampling pattern has to be carefully tuned to avoid noise and view-direction flicker.

Offline AO operates on the actual scene geometry. The renderer fires rays from each shading point and measures occlusion in true 3D space. This is slower per sample but produces stable, ground-truth results that do not flicker when the camera moves and do not miss occluders that are off-screen. Most production renderers expose offline AO either as a node (Blender Cycles, Arnold) or as a render pass (V-Ray, Corona, Redshift).

When an artist asks "why does my AO look different in the viewport versus the final render?" the answer is almost always this: the viewport is running screen-space AO and the final render is computing it in world space. They are different algorithms producing different images.

For a deeper look at the GPU side of this, our GPU cloud render farm page covers how we configure RTX-class hardware for both real-time and offline GPU rendering workloads.

Why AO Baking Slows Down Production

The more interesting performance question for production teams is not real-time AO — that is essentially free in 2026 — but offline AO baking, which is where pipelines actually slow down.

Baking AO means precomputing the AO value for every texel of a UV map and storing it in a texture. It is widely used in game pipelines (where the baked AO map is sampled at runtime instead of computing AO live) and in some archviz workflows for static lighting. The cost depends on three things: scene complexity, texture resolution, and ray count.

Below is a representative bake-time table from jobs we have run for clients on the Super Renders Farm fleet. These numbers are CPU bakes in Blender Cycles on our standard CPU node (Dual Intel Xeon E5-2699 v4, 44 cores, 256 GB RAM); your numbers on a single workstation will be considerably longer.

The break-even point in our experience is around the 30-minute mark for a single bake. Below that, the overhead of packaging the scene, uploading, and downloading the result outweighs the time saved. Above that, especially when an artist is sitting idle waiting for the bake to finish, distributing the work across many machines wins easily. Tile-based bakers (Blender, V-Ray, Arnold) parallelise particularly well because each tile is an independent job.

We see this on Super Renders Farm most often during the asset-finalisation phase of a production: dozens of props need fresh AO bakes, the artists are blocked, and a render farm absorbs the queue overnight. For pricing context, see our render farm pricing guide, and for benchmark numbers across the fleet, the render farm hardware benchmark with Cinebench 2026 covers how our CPU nodes compare on parallel CPU workloads.

Ambient Occlusion in Major DCCs

Each major DCC implements AO slightly differently, and the practical advice changes per package.

Blender exposes AO in three places: the Eevee viewport AO toggle (a fast SSAO/HBAO-style approximation), the Cycles AO node (for shader-level use, e.g. dirt masks in materials), and the Cycles AO render pass (a true ray-traced AO pass output alongside the beauty). Cycles AO baking via the Bake panel is the workflow most teams use; the bake-time table above was measured in Cycles. For artists running Blender on a single workstation, our Blender cloud render farm page covers how Cycles AO bakes scale across our fleet.

Cinema 4D offers AO in both the Standard/Physical renderer and Redshift. In Redshift, AO is typically used as a shader effect or as a compositing pass rather than as a substitute for GI. The Cinema 4D cloud render farm page covers Redshift-specific configuration. We see most C4D + Redshift users compute AO as a render element and combine it in After Effects rather than baking it into the beauty.

3ds Max with V-Ray has a dedicated VRayDirt material and a VRayExtraTex AO render element. The Dirt approach is more flexible because it lets you control falloff, blur, and inverted occlusion (cavity) per material; the render element approach is faster to set up but less tunable. For Corona users in 3ds Max, the equivalent is the CoronaAO map.

Arnold (in Maya, Houdini, or 3ds Max) treats AO as just another sampling problem and exposes it via the aiAmbientOcclusion shader and the ambient_occlusion AOV. Because Arnold is a unidirectional path tracer with strong importance sampling, AO bakes converge faster than in some other renderers at equivalent sample counts.

The common thread: in any DCC, treat AO as a separate pass that you composite, not as a replacement for GI in the beauty render. This keeps the workflow flexible and lets you change the AO contribution in post without re-rendering.

FAQ

Q: What is ambient occlusion in simple terms? A: Ambient occlusion is a shading technique that darkens areas where geometry blocks ambient light from reaching a surface — like the corner where a wall meets a floor. It approximates one specific component of global illumination cheaply, which is why every game engine and offline renderer ships an implementation.

Q: Should ambient occlusion be on or off in games? A: On, in almost all cases. The visual improvement from contact shadows under furniture, characters, and vegetation is significant, and on any GPU released in the last few years the cost is well under 2 ms per frame. The only time switching it off helps is on older hardware where you are fighting for every millisecond.

Q: What is the difference between SSAO, HBAO, and GTAO? A: SSAO is the original screen-space algorithm from 2007 — fast but noisy with visible halos. HBAO marches rays through the depth buffer to find the horizon angle and produces smoother results. GTAO is the most recent of the three; it is calibrated to match offline ray-traced AO and is the most stable in motion. All three operate in screen space and have similar cost on modern GPUs.

Q: Is ambient occlusion the same as global illumination? A: No. Global illumination accounts for indirect light bouncing colour and brightness between surfaces. Ambient occlusion only darkens areas based on local geometry occlusion, with no light-source colour or intensity involved. Using AO as a substitute for GI is a common reason archviz renders look muddy or flat.

Q: When does ambient occlusion baking actually need a render farm? A: When the bake takes more than about thirty minutes per asset, when you have many assets to process in parallel, or when the artist is blocked waiting for the result. On the Super Renders Farm fleet we see most production teams move bakes to a farm at the asset-finalisation stage — typically a queue of dozens of props that would take days to bake sequentially on one workstation but completes overnight when distributed.

Q: Why does my ambient occlusion look different in the viewport versus the final render? A: The viewport almost always uses a screen-space approximation (a fast SSAO or HBAO variant), while the final offline render computes AO in world space using actual geometry rays. They are different algorithms producing different images. For final lighting decisions, do a low-sample preview render rather than trusting the viewport AO.

Q: Can I use ambient occlusion as a render pass in offline rendering? A: Yes, and this is the recommended workflow when you need stylised control. All major renderers (Cycles, V-Ray, Corona, Arnold, Redshift) expose AO as a separate render element or AOV. Output it alongside the beauty render and combine the two in compositing — that way you can adjust the AO contribution without re-rendering the scene.