# GTAO Quality

## Resolution

Determines the resolution at which the effect is rendered. This parameter has the greatest impact on performance and visual output.

* **Full:** 100% of pixels are rendered. Achieves maximum quality.
* **Half:** 50% of pixels are rendered in a checkerboarded (non-temporal) pattern. A good balance between performance and quality.
* **Quarter:** 25% of pixels are rendered. The most performant of the three modes.

*Performance impact: most severe, consider carefully*

{% tabs %}
{% tab title="Full" %}

<figure><img src="/files/wY4xACIIYoDtMIhsyitk" alt=""><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Half" %}

<figure><img src="/files/rXIFmxC1E8QXkZw28LEi" alt=""><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Quarter" %}

<figure><img src="/files/MAmuUGG9pFfK6qAqxFPe" alt=""><figcaption></figcaption></figure>
{% endtab %}
{% endtabs %}

## Tracing Mode

Defines the algorithm used for occlusion calculation.

* **Horizon Search:** the default GTAO algorithm, introduced in the [original paper](https://www.activision.com/cdn/research/PracticalRealtimeStrategiesTRfinal.pdf) and refined over many iterations. Works fast, but struggles with object thickness at large radii. Strongly relies on falloff to avoid haloes.
* **Visibility Bitmasks:** a more [novel approach](https://arxiv.org/abs/2301.11376) that simulates rays passing behind objects, similar to traditional ray marchers, producing results closer to ray tracing — but at a performance cost.

*Performance impact: moderate*

{% tabs %}
{% tab title="Horizon Search, WS Radius 3" %}

<figure><img src="/files/VLvL9IFrueZHLAtPccDl" alt=""><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Visibility Bitmasks, WS Radius 3" %}

<figure><img src="/files/8st15kk5ULpJmRfgMUDM" alt=""><figcaption></figcaption></figure>
{% endtab %}
{% endtabs %}

## Slice Count

Specifies the number of directions (slices) used to evaluate occlusion. The final sample count is calculated as *"Slice Count × Step Count × 2"*. Therefore, each increment in the Slice Count significantly increases the number of samples. This parameter has the greatest impact on noise reduction (aside from the denoiser itself) but comes with a substantial performance cost.&#x20;

{% hint style="warning" %}

* **1 slice** is usually not enough, unless [Visibility Bitmasks](/htrace-ao/settings-and-properties/gtao-settings/gtao-quality.md#tracing-mode) are used (they hide undersampling issues better) and there is no fast motion. [Denoising](/htrace-ao/settings-and-properties/gtao-settings/gtao-denoising.md) is necessary.
* **2 slices** is good enough for most purposes and is widely considered the default for GTAO algorithms. Usually requires at least one form of denoising ([Temporal](/htrace-ao/settings-and-properties/rtao-settings/rtao-denoising/temporal-denoising.md) or [Spatial](/htrace-ao/settings-and-properties/gtao-settings/gtao-denoising/spatial-denoising.md)).
* **3–4 slices** with a moderate radius can provide enough samples to make denoising unnecessary.
  {% endhint %}

*Performance impact: severe, keep as low as possible*

{% tabs %}
{% tab title="Slice Count 1" %}

<figure><img src="/files/bsH0wgwEW66hQSsq5L9F" alt=""><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Slice Count 2" %}

<figure><img src="/files/b76NtUvy2KynJmI7ubzI" alt=""><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Slice Count 3" %}

<figure><img src="/files/BYvUQFqM6TwYEdxC1b25" alt=""><figcaption></figcaption></figure>
{% endtab %}
{% endtabs %}

## Step Count

Specifies the number of steps taken along each direction (Slice). This parameter determines the accuracy of occlusion and affects noise levels, although to a lesser extent than the [Slice Count](#slice-count).

*Performance impact: severe, keep as low as possible*

{% tabs %}
{% tab title="Step Count 8" %}

<figure><img src="/files/6T9A2LdtzBUskJzVhVz7" alt=""><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Step Count 32" %}

<figure><img src="/files/U61cbuQa80v810l9CEeq" alt=""><figcaption></figcaption></figure>
{% endtab %}
{% endtabs %}

## Thickness Mode <mark style="color:$info;">\[Visibility</mark> <mark style="color:$info;"></mark><mark style="color:$info;">**Bitmasks]**</mark>

Defines the method used for thickness calculation.

* **Uniform:** keeps thickness constant, producing more precise and stable intersections at the cost of reduced occlusion in the distance.
* **Linear:** increases thickness linearly with distance, keeping occlusion more visible on distant objects, but may over-occlude thin geometry.

*Performance impact: none*

{% tabs %}
{% tab title="Uniform Thickness 0.2" %}

<figure><img src="/files/jchf1sBVfdBqVjg6O2mA" alt=""><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Linear Thickness 0.2" %}

<figure><img src="/files/O28h7ielGAiL2zaVmF1V" alt=""><figcaption></figcaption></figure>
{% endtab %}
{% endtabs %}

## Thickness Value <mark style="color:$info;">\[Visibility</mark> <mark style="color:$info;"></mark><mark style="color:$info;">**Bitmasks]**</mark>

Controls the virtual thickness of objects. Since a screen-space algorithm uses the depth buffer to find intersections, it has no way of knowing the true thickness of objects. Instead, an arbitrary parameter is used - the higher this value, the stronger the occlusion cast by all objects.

*Performance impact: none*

{% tabs %}
{% tab title="Thickness Value 0.1" %}

<figure><img src="/files/tjVyniqIVnFO0oRzXrgz" alt=""><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Thickness Value 0.5" %}

<figure><img src="/files/gaK2PcqwvxlfhbNkmVkS" alt=""><figcaption></figcaption></figure>
{% endtab %}
{% endtabs %}

## Use Attenuation <mark style="color:$info;">\[Visibility</mark> <mark style="color:$info;"></mark><mark style="color:$info;">**Bitmasks]**</mark>

Specifies whether falloff should be applied during the occlusion evaluation. Visibility Bitmasks are originally designed to work without falloff. However, this can cause the occlusion appearance to deviate significantly from the non-bitmask variant, which has more contrast in crevices and quickly fades to pure white.

Enabling this option allows the bitmasked GTAO to more closely match the non-bitmask variant in terms of contrast distribution. Disabling it makes the bitmasked GTAO resemble RTAO more closely.

*Performance impact: small*

{% tabs %}
{% tab title="Use Attenuation ON" %}

<figure><img src="/files/F0F4FBxf8JnfOi1OamIE" alt=""><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Use Attenuation OFF" %}

<figure><img src="/files/8lrAJiqAjamnX6FTjbVu" alt=""><figcaption></figcaption></figure>
{% endtab %}
{% endtabs %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://ipgames.gitbook.io/htrace-ao/settings-and-properties/gtao-settings/gtao-quality.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.