Somnath Sarkar

openntc

2026-08-31T00:00:00-07:00

Compressing textures by 95%+ with minimal loss of quality

In every major modern video game and engine, large sets of textures are used to drive rendering materials. Physically Based Rendering (PBR) materials can be defined by half a dozen or more high resolution textures defining properties like Albedo, Specular, Ambient Occlusion, etc. This means that a single material type may take up hundreds of MB at higher resolutions. In a world where games can contain tens of thousands of unique materials and VRAM is at an absolute premium, this is unviable. To overcome this game engines employ multiple methods; Typically, at least by applying BCn compression to the textures. BCn compression has the benefit of wide hardware support and efficient decode times, but are fixed to certain per-texture compression schemes with conservative compression factors [16]. Recent hardware and API changes have enabled more powerful compression algorithms, ones that take every channel in a PBR material into consideration [1][3][4][5].

We’ll walk through a new compression method in this article: Neural Texture Compression (NTC) [1] which is able to compress entire texture sets by 95%+ vs uncompressed and deliver substantially higher quality than BCn at lower bitrates. We’ll do this through the development of openntc, a source-available implementation of NTC from scratch that provides both API and GUI interfaces to its own compression utilities. We’ll go through a quick guide on how to use the library before discussing details. We’ll present the major ideas, then we’ll walk through an implementation from scratch. Finally, we’ll examine performance both at a per-material scale and in a more realistic game setting.

Table of Contents

Quick start and User guide

Feature Pyramids

Decoding

Compression

Optimizing Inference

Optimizing Compression

Sampling & Filtering

Performance

Tips and Tricks

Conclusions and Benefits

References

openntc: Quick start and User guide

Here’s a quick guide to testing out our implementation of NTC tools on your own textures:

Grab a copy of the latest release here. Currently, we support Windows/CUDA machines for compression, and DirectX 12 for the runtime (decoding).

Create a description of your material using a JSON manifest. The format generally matches those of other NTC tools [2]:

{
  "width": 4096,
  "height": 4096,
  "textures": [
    {
      "fileName": "BaseColor.png",
      "isSRGB": true,
      "semantics": { "Albedo": "RGB" }
    },
    {
      "fileName": "Normal.png",
      "semantics": { "Normal": "RGB" }
    },
    {
      "fileName": "RoughnessMetalness.png",
      "semantics": { "Roughness": "G", "Metallic": "B" }
    },
    {
      "fileName": "AmbientOcclusion.png",
      "semantics": { "Occlusion": "R" }
    }
  ]
}

Select a profile in the GUI. Each profile has a different compression scheme, each with different bytes-per-pixel channel and quality values. Here are example results on a 9-channel, 4096 x 4096 PBR texture set at openntc’s Ultra preset. Note that the uncompressed size of this texture set is 201.3 MB.

	openntc 0.2 bpp	openntc 0.5 bpp	openntc 1.0 bpp	openntc 2.25 bpp
Size	3.93 MB	9.52 MB	19.0 MB	42.5 MB
Quality (PSNR)	33.91 dB	36.66 dB	40.25 dB	43.87 dB

Select a training quality and hit train, progress is viewable via the training bar.
Compare reconstruction quality with the original by choosing one of the NTC options in the view panels, then Save Compressed via Ctrl-S.

Alternatively, we can use the libopenntc API via C++ as follows:

#include <libopenntc/libopenntc.h>
...
using namespace openntc;
Context ctx;
ContextInitInfo init = { .profile_ = Profile::Bpp_0_5 };
if (ctx.Init(init) == Result::Success)
{
  if (ctx.LoadManifest("manifest.json") == Result::Success)
  {
    TrainInfo train = { .quality_ = Quality::Medium, .grids_per_batch_ = 1 };
    ctx.BeginTraining(train);
    ctx.TrainUntilComplete();

    EvalResults eval = ctx.Eval();
    std::cout << "PSNR: " << eval.psnr_ << " dB";

    Dump("bricks.ntc", ctx.GetCompressedData());
  }
}

To sample openntc-compressed textures in your own engine or project, use the openntc-runtime library to load buffers from the .ntc file. Bind these buffers as HLSL descriptors to your shader:

#include <libopenntc/openntc_runtime.h>
...
openntc::FileData file;
if (openntc::Load("bricks.ntc", file) != openntc::Result::Success)
  return;
const openntc::CompressedData& cd = file.Data();

// Upload data to GPU, CreateBufferWithData is a placeholder helper function
// SRV: Buffer<uint>, Format: DXGI_FORMAT_R32_UINT
ID3D12Resource* g0_buf  = CreateBufferWithData(cd.g0_[0], cd.g0_total_size_);
// SRV: Buffer<uint>, Format: DXGI_FORMAT_R32_UINT
ID3D12Resource* g1_buf  = CreateBufferWithData(cd.g1_[0], cd.g1_total_size_);
// SRV: ByteAddressBuffer, Format: DXGI_FORMAT_R32_TYPELESS
ID3D12Resource* dec_buf = CreateBufferWithData(cd.decoder_, cd.decoder_size_);

// Constant buffer with texture-related information
openntc::NTCConstants consts;
openntc::FillNTCConstants(cd, consts);
ID3D12Resource* ntc_cb = CreateBufferWithData(&consts, sizeof(consts));

Include the ntc_decode.hlsli HLSL header and call our helper functions to retrieve your sample!

#define BPP_0_5
#include "ntc_decode.hlsli"

ConstantBuffer<NTC> NTCCBV : register(b1);   // NTCConstants from FillNTCConstants
Buffer<uint> g0 : register(t0);              // Feature pyramid 0
Buffer<uint> g1 : register(t1);              // Feature pyramid 1
ByteAddressBuffer decoder : register(t2);    // Decoder MLP weights

...

openntc::MaterialParams mat = openntc::SampleMaterial(g0, g1, decoder, NTCCBV, uv, lod);

// Now use material params mat.albedo_, mat.roughness_, etc. to perform lighting.

Let’s now go deeper into how this all works:

Feature Pyramids

We can think of a uncompressed 2D texture as a grid where each cell of the grid contains up to 4 channels or features and each channel takes up a number of bits, typically 8/16/32 depending on the texture format. In a game engine, downsampled versions of the full resolution texture are also used when distances between sample locations are larger. This forms a mip chain, which can resemble a pyramid of grids of features.

Neural compressed textures generalize this, where we have a pyramid of features, except each cell of each grid may have an arbitrary number of features each with an arbitrary number of bits. Instead of each cell containing actual texture data directly, they contain input features to a decoder, typically a small MLP. Instead of each mip representing a single LOD for one channel of a material, each level of a feature pyramid represents all of the channels for multiple LODs of a material. The compression ratio can be tweaked by changing of the number of bits per feature and features per cell.

Decoding

Decoding NTC textures can be done prior to their use in a shader, essentially creating an uncompressed version of the textures before sampling (Inference-on-Load), or in real-time as they are being sampled (Inference-on-Sample). Inference-on-Load can be followed by compressing the textures to BCn, which means we don’t actually get any VRAM savings for a NTC compressed texture at runtime over BCn, but this can still help with reducing download sizes and install footprints. A huge benefit of Inference-on-Load is that the graphics programmer doesn’t need to change his shaders or sampling behavior in any way. On the other hand, Inference-on-Sample allows us to only store the compressed NTC data at runtime. This means every sample requires a full inference step, which involves modifying shader code. This inference step is described below.

For openntc, similarly to RTXNTC [1], we use two separate feature pyramids. The first pyramid is higher resolution, and we draw four samples from it corresponding to the four closest cells to the sample location. The second feature pyramid uses a bilinear sample of the four nearest cells. This combination allows the network to learn its own filtering scheme for the first set of features. Since feature grids are coarser than the raw textures they compress, it is critical to provide additional positional information to distinguish between them. We supply triangle waves at multiple resolutions as a positional encoding [1]. Finally, a single normalized float provides LOD information.

These are input features fed into a simple neural network called a Multi-Layer Perceptron (MLP). Multiple decoder architectures have been proposed [1][3][4][5], for openntc I opted for a simple two layer network each with 64 neurons. This means that inference in the shader involves three matrix-vector multiplications, each separated by a non-linear activation function. The specific activation function we use is hardGELU, a piecewise approximation of GELU [11] which is relatively computationally efficient:

float hardgelu(float x)
{
  return x < -1.5 ? 0.0 : (x < 1.5 ? x * (x + 1.5) / 3.0 : x);
}

Compression

This diagram breaks down how openntc works, using a set of uncompressed textures as input, using our 0.5 bits-per-pixel-channel profile as reference. A similar process works for the other profiles.

First we generate any missing mips for the input textures using a high-quality edge preserving Lanczos filter [12].
We choose a profile. Each profile has a different bits-per-pixel-per-channel number, mainly due to the number of features and bits-per-feature of the feature grids.
For each training iteration, we draw an LOD at random and randomly sample a square grid from the mips corresponding to this LOD for each texture in the material. This forms our ground truth information for the current batch.
We then draw features from matching positions in the untrained feature pyramids, as well as the positional and LOD information laid out in the previous section. Through training we use 32-bit floats to represent weights, however the compressed weights will have far lower bit widths (generally 2-4 bits). To make the model robust to this quantization, we add an amount of noise to the sampled feature pyramids proportionate to the final bit width [1].
This forms a classic supervised learning pattern. We make a forward pass of the input features through the network to obtain the models prediction of the input at this time.
These predictions can be compared against the ground truth using the mean-squared error loss function. (L2 Loss)
We then backpropagate this loss through the network, updating decoder weights and feature pyramids to minimize the loss between predictions and ground truth.
Finally we lock the feature grid weights to their final quantized values, rounding to the nearest quantization bin matching the selected profile.
We let the decoder train for a short time longer (~5% of total training budget) at the settled grid weights.
The finished compressed feature grids are packed tightly into their profile bit-widths and the decoder is then quantized to 8-bit integers for efficient DP4A/Cooperative Vector decoding. Since we need to requantize inputs after each layer we must also measure the absolute maximum output of each layer as a calibration step.
The feature grids, decoder and certain NTC metadata specific to that material are distributed together as the final compressed texture.

Optimizing Inference

Running a forward pass multi-layer neural network for every pixel is extremely computationally intensive. Naive matrix multiplication on floats using sequential multiply and add instructions will be bound by loading weights. Inference-on-Sample models are especially incentivized to maximize performance in this area.

DP4A

Shader model 6.4 introduced Dot Product of 4 Elements and Accumulate (DP4A) instructions that are able to interpret a single 32-bit integer register as vector of 4 8-bit integers, and compute the dot product of two such vectors and storing the result in a single 32-bit integer, all in one instruction [6].

This was further supported by SM 6.6 (NVIDIA Pascal, AMD RDNA) which added helper functions to pack and clamp sets of integers into 8-bit slots of a single 32-bit integer [7]. This dramatically reduces the loads and instructions required, and brings the inference time into acceptable territory. Since matrix-vector multiplication involves taking the dot products of each row of the matrix with the vector, its a natural fit.

// Matrix multiplication using DP4A

// input and output are HIDDEN_DIM-element vectors with each 4 consecutive
//  8-bit elements packed into 32-bit uints
uint input[HIDDEN_DIM / 4];
uint output[HIDDEN_DIM / 4];

// Evaluate 4 rows at a time
for (int i = 0; i < HIDDEN_DIM; i += 4)
{
  int4 acc = int4(0, 0, 0, 0);
  [unroll]
  for (int j = 0; j < HIDDEN_DIM / 4; j += 4)
  {
    // MatrixLoad4: Placeholder to load 4x4 contiguous weights starting from column j in row i
    // Each row is also packed into 8-bits, meaning a uint4 contains 16 values.

    uint4 Wx = MatrixLoad4(i, j * 4);
    uint4 Wy = MatrixLoad4(i + 1, j * 4);
    uint4 Wz = MatrixLoad4(i + 2, j * 4);
    uint4 Ww = MatrixLoad4(i + 3, j * 4);
    [unroll]
    for (int c = 0; c < 4; c++)
    {
      // Requires Shader Model 6.4
      acc.x = dot4add_i8packed(Wx[c], input[j + c], acc.x);
      acc.y = dot4add_i8packed(Wy[c], input[j + c], acc.y);
      acc.z = dot4add_i8packed(Wz[c], input[j + c], acc.z);
      acc.w = dot4add_i8packed(Ww[c], input[j + c], acc.w);
    }
  }
  // When repacking into 8-bits, we need to provide scaling factors from the Calibration step
  //  to ensure best use of bits available. ScalingForRows is the factor for rows [i, i+3]
  float4 facc = float4(acc) * ScalingForRows(i);
  facc = hardGELU(facc) * ScalingForActivation();
  int4 unpacked = int4(round(facc));
  // Requires Shader Model 6.6
  output[i / 4] = pack_clamp_s8(unpacked);
}

Cooperative Vectors

The real benefit, however, comes with cooperative vector support. This refers to hardware-accelerated matrix multiplication using NVIDIA’s tensor cores and AMD’s matrix cores. The API for this hasn’t settled yet. DirectX 12 proposed a version of this called cooperative vectors in Shader Model 6.9 [8], then reworked it into a more general linear algebra library for Shader Model 6.10 [9]. At the time of writing, its still in preview, requiring beta drivers and a preview Agility SDK. As we’ll see in the performance section, however, this is by far the most performant approach since it executes all loads and and matrix-vector multiplications for a single warp in one step.

// Matrix multiplication using cooperative vectors
// Requires Shader Model 6.10
#include <dx/linalg.h>
using namespace dx::linalg;

// input and output are HIDDEN_DIM-element vectors with each 4 consecutive
//  8-bit elements packed into 32-bit uints
vector<uint, HIDDEN_DIM / 4> input;
vector<uint, HIDDEN_DIM / 4> output;

typedef Matrix<ComponentType::I8, HIDDEN_DIM, HIDDEN_DIM, MatrixUse::A, MatrixScope::Thread> W_t;
W_t W = W_t::Load<MatrixLayout::RowMajor>(decoder, MATRIX_OFFSET, /*row stride*/ HIDDEN_DIM);

// Tell the unit to read the packed uints as int8
InterpretedVector<uint, HIDDEN_DIM / 4, ComponentType::I8> x = MakeInterpretedVector<ComponentType::I8>(input);
vector<int32_t, HIDDEN_DIM> acc = MultiplyAdd<int32_t>(W, x, (vector<int32_t, HIDDEN_DIM>)0);

// When repacking into 8-bits, we need to provide scaling factors from the Calibration step
//  to ensure best use of bits available. ScalingForRows is the factor for all HIDDEN_DIM rows
vector<float, HIDDEN_DIM> facc = vector<float, HIDDEN_DIM>(acc) * ScalingForRows();
facc = hardGELU(facc) * ScalingForActivation();
vector<int32_t, HIDDEN_DIM> unpacked = vector<int32_t, HIDDEN_DIM>(round(facc));
[unroll]
for (int i = 0; i < HIDDEN_DIM; i += 4)
{
  // Requires Shader Model 6.6
  output[i / 4] = pack_clamp_s8(int4(unpacked[i], unpacked[i + 1], unpacked[i + 2], unpacked[i + 3]));
}

Optimizing Compression

While deep-learning frameworks like pytorch were helpful for the initial research/proof-of-concept period, I quickly grew tired of the longer iteration times for experiments and needed a faster approach. Switching to hand-written CUDA kernels offered tremendous speed-up oppurtunities:

Training involved dozens of hundreds of small operations per step with significant torch/python overhead and many intermediate tensors. Rolling our own allows us to be explicit about which operations map to a single kernal invocation, and eliminate dynamic memory allocation along the critical path.
Using CUBLAS for the large matrix multiplication operations involved in forward and backward passes over the network, allows us to benefit from hardware-accelerated tensor cores when available.
Because we train on contiguous grids of the input textures, the backward pass over feature pyramids updates the same features multiple times. Practically, this means we need atomic updates which increases compression time based on contention. We can exploit the fact that threads in the same warp are likely to share features (due to the way features are drawn, see the section on decoding). We can use warp-level synchronization [10] to reduce contention as follows:

__device__ void mask_aggregate_atomic_increment(float* grid_grad, int cell, float val)
{
  // Lanes in this warp (among the active ones) whose cell equals mine
  unsigned peers = __match_any_sync(__activemask(), cell);
  int lane = threadIdx.x % 32;
  int leader = __ffs(peers) - 1;          // lowest peer lane does the write

  // Pull each other peer's value with a shuffle
  float total = val;
  unsigned others = peers & ~(1u << lane);
  while (others)
  {
    int next = __ffs(others) - 1;
    total += __shfl_sync(peers, val, next);
    others &= ~(1u << next);
  }

  if (lane == leader)
    atomicAdd(&grid_grad[cell], total);
}

Sampling & Filtering

Since decoding neural compressed textures must be done in shader code vs. hardware support for BCn textures, we must take special care for how they are filtered. Moreover, since decoding a single sample is computationally expensive, taking multiple samples for trilinear or anisotropic sampling is unviable. We use stochastic filtering instead [1][13]. Here’s an example of how that works with trilinear sampling. Lets say we need to sample lod 2.4. In conventional hardware filtering, the sampler takes two bilinear samples at LOD 2 and 3, then lerps between them with parameter 0.4. For stochastic filtering, instead we just randomly sample a single LOD: we sample LOD 2 with probability 0.6, and LOD 3 with probability 0.4. Similarly for bilinear sampling, we can individually select an integral texel position based on the fractional value of the sample location.

Anisotropic filtering is trickier. We can think of the uv space spanned by a single sample to have two axes, measured by taking the derivatives along the x and y axis of the quad. At grazing angles, the uv space spanned along one axis (major axis) may be much larger than a perpendicular axis (minor axis). We use the minor axis for LOD selection, then take a sample at random along the major axis.

Making use of stochastic filtering means that some sort of temporal accumulation is necessary to avoid jittering. This is less of a drawback now that TAA is the most common form of anti-aliasing, but is worth mentioning. We use a simple TAA implementation with color clamping, more details here [14]

Performance

Analyzing performance of openntc requires being aware of the different axes along which members can be compared. There is the actual space the compressed texture takes on disk, the quality of the texture after decompression and the performance cost of the decoding process of the texture. These experiments were conducted on the public domain ambientCG PBR material set [17] at 4096x4096 resolution. We will compare them both against the uncompressed data and BCn compressed textures. Since there are many possible schemes to encode each texture using Block Compression, we use a reasonable batch of settings that resembles Unreal Engine 5’s default encoding scheme [19]. We use the open-source texconv package [15] to perform BCn compression.

Format	Texture Layout Description
Uncompressed	Albedo R8G8B8 (3), Normal R8G8B8 (3), AO / Rough / Disp R8 (1 each)
BCn	UE5 defaults* [19]: Albedo BC1 (0.5), Normal BC5 (1), AO / Rough / Disp BC4 (0.5 each)
openntc 2.25 bpp	G0 16 ch x 4 b at 2048², G1 12 ch x 4 b at 1024², 5 levels
openntc 1.0 bpp	G0 12 ch x 2 b at 2048², G1 10 ch x 4 b at 1024², 5 levels
openntc 0.5 bpp	G0 12 ch x 4 b at 1024², G1 20 ch x 4 b at 512², 5 levels
openntc 0.2 bpp	G0 8 ch x 2 b at 1024², G1 12 ch x 4 b at 512², 5 levels

*Single channel maps typically use the ‘Alpha’ setting in UE5, which uses BC4.

Size

This refers to the size of the textures on disk and in VRAM for the Inference-on-Sample path. Smaller values are better.

Format	Size with Mips (MB)	Compression ratio vs uncompressed	Compression ratio vs BCn
Uncompressed	201.3 MB	1:1	1:3
BCn	67.1 MB	3:1	1:1
openntc 2.25 bpp	42.5 MB	4.7:1	1.6:1
openntc 1.0 bpp	19.0 MB	10.6:1	3.5:1
openntc 0.5 bpp	9.52 MB	21:1	7:1
openntc 0.2 bpp	3.93 MB	51:1	17:1

Quality

Quality is measured by Peak Signal-to-Noise Ratio. (PSNR), where higher values are better:

\[\mathrm{PSNR} = 10 \log_{10} \frac{\mathrm{MAX}^2}{\mathrm{MSE}} = -10 \log_{10} \mathrm{MSE}, \qquad \mathrm{MSE} = \frac{1}{N} \sum_{i=1}^{N} \left( x_i - \hat{x}_i \right)^2\]

where $x_i$ are the ground truth 8-bit texel values scaled to $[0, 1]$, $\hat{x}_i$ are the decoded compressed values. Since the magnitude of PSNR can vary widely based on the source image, and the relevant quantity is just the relative PSNR between presets we present the values for a single material from the ambientCG PBR set, Tiles131. The same material is used for our header image in the introduction.

We can adjust the number of training loop steps to generate quality presets. For openntc, we use Low (30k), Medium (120k), High (240k) and Ultra (480k) to offer different compression time vs. quality tradeoffs.

Tiles131 (4096²)	Low (30k)	Medium (120k)	High (240k)	Ultra (480k)
BCn	39.92 dB	39.92 dB	39.92 dB	39.92 dB
openntc 0.2 bpp	31.82 dB	33.35 dB	33.58 dB	33.91 dB
openntc 0.5 bpp	33.21 dB	35.46 dB	35.79 dB	36.66 dB
openntc 1.0 bpp	35.84 dB	38.90 dB	39.64 dB	40.25 dB
openntc 2.25 bpp	38.20 dB	41.98 dB	43.17 dB	43.87 dB

Decoding speed

Finally, heres a full scene rendered entirely with openntc materials, the famous Sponza test scene [18]. This is a very simple deferred renderer with relatively simple lighting that is intended solely to measure the change in the performance of texture samples during the G-buffer write. All source materials use 4k texture sizes.

Since texture sampling performance is the main source of performance increase, writing out the (UV, LOD, Material) index to an intermediate buffer and then sample NTC materials to form the G-buffer, similar to deferred texturing. Since NTC converts entire materials to a single sample, ideally we want just one sample per-pixel which can be achieved this way.

For a full scene, at 1080p, the cooperative vector path is the only realistic Inference-on-Sample path at frame rates acceptable to a game engine. Here is the full table of render timings for comparison.

Material path	Direct, DP4A	Direct, Coop	Deferred texturing, DP4A	Deferred texturing, Coop	Deferred texturing, Coop + wave partition
Uncompressed textures (hardware filtering)	0.75 ms	–	0.84 ms	–	–
NTC 0.2 bpp	14.38 ms	4.80 ms	9.05 ms	1.74 ms	2.00 ms
NTC 0.5 bpp	16.81 ms	5.17 ms	10.20 ms	1.91 ms	2.20 ms
NTC 1.0 bpp	15.10 ms	5.02 ms	9.58 ms	1.89 ms	2.12 ms
NTC 2.25 bpp	17.42 ms	5.02 ms	10.64 ms	1.93 ms	2.17 ms

All times refer to G-buffer generation times on an RTX 4080 at 1080p. Deferred texturing times include both the uv-pass and material sampling step.

Tips and Tricks

While reference material [1][2] was very helpful for this project, there are several things to keep in mind when using or implementing your own Neural Texture Compression engine that were not obvious to me:

Training distribution

When comparing reconstruction quality of a NTC scheme against other implementations, ensure that your measured PSNR numbers are as close to an apples-to-apples comparison as possible. If you are weighting PSNR on the higher resolution mips more heavily, you should be providing more training samples from the high resolution LODs. One of the trickiest bugs I resolved took place because during training I was drawing grids from each mip level such that the grid never overlapped the boundary. This had the subtle effect of reducing reconstruction quality at the edges of each texture, which was most noticable at lower resolution mips.

Multiple materials

Cooperative Vectors are built to exploit wave-level cooperation, where optimal performance is typically achieved where every thread in a wave is performing multiplication with the same matrix at the same time. In our deferred texturing example in Sponza [18], this isn’t the case, and multiple threads in a wave will multiply with different matrices when they contain different materials.

The original RTXNTC paper [1] suggests a wave-synchronization step where we iterate over different materials one at a time or avoid using cooperative vectors entirely in this case:

Outputs runNetwork(Inputs x, uint paramOffsets) {
  // Check if all lanes are active.
  if (WaveActiveCountBits(true) == WaveGetLaneCount()) {
    uint mask = -1;
    uint lane = 0;
    // Iterate over unique network parameters in the SIMD group.
    for (; mask ;) {
      // Broadcast the parameter offset across SIMD lanes.
      uint offset = WaveReadLaneAt(paramOffsets, lane);
      bool matchingLanes = offset == paramOffsets;
      // Evaluate the MLP with matrix acceleration.
      Outputs y = MLP(x, offset);
      // Store the outputs for matching lanes.
      storeOutputs(y, matchingLanes);
      // Clear the evaluated lanes.
      mask -= WaveActiveBallot(matchingLanes).x;
      lane = firstbitlow(mask);
    }
  } else {
    // Fallback without matrix acceleration.
  }
}

However, the DirectX specification for this feature [8] does not enforce uniform control flow. In fact, omitting this wave synchronization improves performance by ~20% in our Sponza demo. This may change based on the average number of unique materials per wave.

Conclusions and Benefits

Neural Texture Compression is extremely promising as a future compression method, and I expect to see it in use more as cooperative vector support [8][9] matures and tensor cores become more widely adopted. In the interim DP4A [6] serves as a stopgap way to get your feet wet with this technology. In particular, I see NTC textures having the potential to have a profound impact on game engines in the following ways:

Asset streaming

Typically engines have systems to determine which mips to keep in memory, like Virtual Texturing or simple heuristics. It’s common to have the lowest resolution mip always resident in memory to avoid frame hitching to wait for a load, but this can cause the very common issue of texture pop-in when the better mip becomes available. An NTC compressed texture can deliver a much higher quality fallback option at a similar low memory footprint.

Scalability

Unlike BCn textures, which offer a small specific set of bits-per-pixel schemes, NTC is a lot more flexible. One can quickly tune the bits per feature, number of features per cell, or number of levels in the feature pyramid to offer a large degree of scalability in the compression ratio. Similarly, number of layers or sizes of intermediate layers of the decoder can be modified to affect inference speed. This means that we can choose an arbitrary scheme in the space of Compression Ratio vs Runtime Performance vs Quality that suits our needs, possibly even algorithmically. Trying to reduce VRAM use in a specific scene? Tune down the features per cell for materials by 10% and determine whether the matching quality reduction is acceptable. Having trouble making 60 FPS in a busy area of a level? Reduce decoder hidden states from 64 to 48 and re-evaluate.

References

[1] K. Vaidyanathan, M. Salvi, B. Wronski, T. Akenine-Möller, P. Ebelin, A. Lefohn, 2023. Random-Access Neural Compression of Material Textures

[2] NVIDIA, 2025. RTX Neural Texture Compression SDK (RTXNTC)

[3] S. Fujieda, T. Harada, 2024. Neural Texture Block Compression

[4] L. Belcour, A. Benyoub, 2025. Hardware Accelerated Neural Block Texture Compression with Cooperative Vectors

[5] C. Weinreich, L. De Oliveira, A. Houdard, G. Nader, 2024. Real-Time Neural Materials using Block-Compressed Features

[6] Microsoft, 2019. HLSL Shader Model 6.4: Packed Dot Product Intrinsics

[7] Microsoft, 2021. HLSL Shader Model 6.6: Pack/Unpack Math Intrinsics

[8] Microsoft, 2025. HLSL Specification 0029: Cooperative Vectors (Shader Model 6.9)

[9] A. Patel (Microsoft), 2026. Announcing Shader Model 6.10 Preview and AgilitySDK 720 Preview (LinAlg)

[10] NVIDIA, 2026. CUDA C++ Programming Guide: Warp Match and Warp Shuffle Functions

[11] D. Hendrycks, K. Gimpel, 2016. Gaussian Error Linear Units (GELUs)

[12] C. E. Duchon, 1979. Lanczos Filtering in One and Two Dimensions

[13] J. Jimenez, 2014. Next Generation Post Processing in Call of Duty: Advanced Warfare

[14] L. Yang, S. Liu, M. Salvi, 2020. A Survey of Temporal Antialiasing Techniques

[15] Microsoft, 2026. DirectXTex texture processing library

[16] N. Reed, 2012. Understanding BCn Texture Compression Formats

[17] ambientCG, 2026. PBR materials

[18] F. Meinl, Intel, 2022. GPU Research Samples

[19] Epic Games, 2026. Texture Properties in Unreal Engine

Optimizing text rendering

2026-07-28T00:00:00-07:00

While getting my text layout system, lexkit, ready for a public release I wanted to make sure performance was as fast as possible. This is a breakdown of the major steps we took to optimize performance and lay out the entire Project Gutenberg text of The Odyssey 6.5 times faster than the Unicode Consortium’s implementation ICU [1].

Table of Contents

Performance and Profiling

Memory Allocation

API Design and Caching

Efficient UTF-8 decoding

Fast Paths

Data structures: The Two-Step table

Baking Unicode Specification

SIMD instructions

Better Algorithms for BiDi reversals

Multithreading

Conclusions and Future Work

Performance and Profiling

Lexkit is a text layout framework capable of handling the following steps of the text rendering pipeline, divided into the stages we use to measure them:

Pre-processing

Reading a Unicode specification and transforming it into lookup tables.
Baking font data to a texture.

Per-text operations

Decoding UTF-8 data to 32-bit codepoints.
Identifying and splitting paragraphs.
Performing Bidirectional (BiDi) text handling.
Shaping text: Converting codepoints to glyph indices.
Identifying break opportunities at grapheme, word and line levels.

Per-layout operations

Fitting text into boxes with fixed width, performing hyphenation as appropriate.
Outputting vertex buffers for rendering.

We are primarily concerned with the last two categories, since the pre-processing steps can be baked offline and don’t incur a runtime cost. We measure this against the de-facto reference Unicode Implementation, ICU [1]. ICU is concerned with performing Unicode operations like BiDi and text breaking and doesn’t have any shaping utilities. To compare them, we use HarfBuzz functions to complete these stages of the pipeline. HarfBuzz [14] is the industry standard for text shaping and is used as part of lexkit as well, so this is a fair comparison.

Measurement setup

To measure performance, we use both CPU profiling tools and instrumenting our code. The Intel VTune Profiler [12] is a common tool that we’ll use to measure CPU utilization, memory bandwidth, L1/L2 cache hit rates and hotspots. We will use the Win32 QueryPerformanceCounter group of functions to compute timestamps and measure the execution times of individual functions.

We measure performance on example03 in the lexkit examples folder (Source), which lays out the entire text of The Odyssey from Project Gutenberg [15] (0.75 MB) at real-time rates. It uses our OpenGL renderer (Source) on a 64-bit Windows 11 machine using an Intel i7-12700K CPU and NVIDIA RTX 4080 GPU.

Memory Allocation

It is extremely difficult to handle arbitrary fonts and lay them out into dynamic dimensions without some degree of runtime memory allocation. Our best bet is to use a performant allocator and avoid using OS utilities like VirtualAlloc for every single minor allocation. For lexkit, we have additional constraints: the allocator should behave well with multiple threads and should accommodate allocations and deallocations at lifetimes that correspond to text rendering.

This is a good choice for a linear allocator, specifically an Arena [9]. Arena allocators work by grabbing a fixed amount of memory, then allocating and freeing blocks using stack-based lifetimes. In other words allocations are last-in, first-out (LIFO). Arenas expose allocation via the following API:

// Arena API
LkArena* lkArenaCreate(void);
void lkArenaDestroy(LkArena* arena);
void* lkArenaPush(LkArena* arena, uint64_t sz, uint64_t aln);         // Zero-initialized
void* lkArenaPushNZ(LkArena* arena, uint64_t sz, uint64_t aln);       // Uninitialized
uint64_t lkArenaGetPos(LkArena* arena);
void lkArenaRestore(LkArena* arena, uint64_t pos);                    // Free everything pushed since pos

// Helper macros
#define APush(arena, tp) (tp*)lkArenaPush((arena), sizeof(tp), _Alignof(tp))
#define APushArray(arena, tp, count) (tp*)lkArenaPushArray((arena), sizeof(tp), _Alignof(tp), (count))
#define APushNZ(arena, tp) (tp*)lkArenaPushNZ((arena), sizeof(tp), _Alignof(tp))
#define APushArrayNZ(arena, tp, count) (tp*)lkArenaPushArrayNZ((arena), sizeof(tp), _Alignof(tp), (count))

// Typical usage: scratch is an LkArena
uint64_t frame_pos = lkArenaGetPos(scratch);
LkLine* lines = APushArrayNZ(scratch, LkLine, max_lines);
int32_t* codepoint_orders = APushArrayNZ(scratch, int32_t, line_codepoint_count);
// Use variables in scratch
lkArenaRestore(scratch, frame_pos);

Managing memory ourselves using arenas is far more performant than relying on the CRT. For the below comparison, we replace all arena allocations with malloc, realloc and free CRT calls; the performance benefit is clear. Pure C libraries also typically use the convention that zero-initialized memory is a valid initial state for a struct instance since we don’t have access to constructors. However, if it can be avoided, it helps to clearly denote which objects require zero-initialization and which don’t. Expressly providing allocations that don’t set memory to zero instead of guaranteeing it gave us a small performance win.

We make the following modifications to arenas for our use in a text layout system.

One issue with the simplest form of arenas is that we have to preallocate the block of memory ahead of time or use a complex scheme every time we want to grow the arena. This may involve either reallocating the entire block of memory, or using a linked list of blocks to accommodate new data. A much easier approach is to use Win32’s VirtualAlloc [10] to reserve a large block of memory (say 16 GB) up front, and only commit when needed. This exploits the ability of MMUs to supply a large virtual address space up front which is mapped to actual memory only once needed.

#define LK_ARENA_RESERVE (1024llu * 1024llu * 1024llu * 16)   // 16 GB
#define LK_ARENA_CHUNK (1024llu * 1024llu)                    // 1 MB

static void* Reserve(uint64_t size)
{
  return VirtualAlloc(NULL, size, MEM_RESERVE, PAGE_NOACCESS);
}

static bool Commit(void* ptr, uint64_t size)
{
  return VirtualAlloc(ptr, size, MEM_COMMIT, PAGE_READWRITE) != NULL;
}

LkArena* lkArenaCreate(void)
{
  LkArena* arena = calloc(1, sizeof(LkArena));
  arena->reserved = LK_ARENA_RESERVE;
  arena->committed = 0;
  arena->data = Reserve(LK_ARENA_RESERVE);
  return arena;
}

static void ArenaCommit(LkArena* arena, uint64_t pos_required)
{
  uint64_t pos_target = LK_ARENA_CHUNK * ((pos_required + (LK_ARENA_CHUNK - 1)) / LK_ARENA_CHUNK);
  Commit((char*)arena->data + arena->committed, pos_target - arena->committed);
  arena->committed = pos_target;
}

static void* ArenaPushRaw(LkArena* arena, uint64_t sz, uint64_t aln)
{
  uint64_t pos_aln = ((arena->pos + aln - 1) / aln) * aln;
  uint64_t pos_target = pos_aln + sz;
  if (pos_target > arena->committed)
    ArenaCommit(arena, pos_target);
  arena->pos = pos_target;
  return (char*)arena->data + pos_aln;
}

Text rendering involves multiple disjoint data lifetimes:
- Fonts: data that belongs to a specific font family and styles, e.g. a font atlas, per-glyph dimensions, metadata, etc.
- Text: data that belongs to a piece of text, e.g. line break candidate locations, shaped glyph indices, etc.
- Layout: data that belongs to a piece of text that has been organized to be rendered on screen, e.g. actual line break locations.
These lifetimes can be individually managed by separate arenas. For example, we create an arena for a specific piece of text, then as we move through the text rendering pipeline, all allocations that belong to that lifetime (break candidates, BiDi run information, etc.) will simply be pushed onto the arena.
Following on from that, in multi-threading mode each worker thread has a thread-specific Arena. This allows us to avoid synchronization along the allocator path. To implement this, we have an array of arenas as part of our lexkit context, which is indexed into with the worker thread id.

// One arena per worker thread + one for the main thread
void lkCreateContext(const LkUnicodeData* ud, int num_workers, LkAllocator* alloc, LkContext* o_ctx)
{
  ...
  o_ctx->queue = lkJobQueueCreate(alloc, num_workers);
  o_ctx->worker_scratch = AAllocArray(o_ctx->alloc, LkArena*, num_workers + 1);
  for (int i = 0; i < num_workers + 1; i++)
    o_ctx->worker_scratch[i] = lkArenaCreateFrom(o_ctx->alloc);
}

// Jobs execute on worker threads and index into the arena array with their id
static void ShapeJob(int worker_id, void* data)
{
  ShapeJobData* sdata = data;
  LkArena* scratch = sdata->ctx->worker_scratch[worker_id + 1];
  ...
  LkGlyph* run_glyphs = APushArrayNZ(scratch, LkGlyph, glyph_count);
  ...
}

API Design and Caching

It helps to simply do less work rather than doing the same work faster. A text rendering system may have to operate under the following scenarios:

Rendering entirely pre-determined text in a pre-determined layout, e.g. static text in a game UI, closed captions, etc.
Rendering entirely pre-determined text in a layout that changes per-frame, e.g. static text in a resizable window.
Rendering text that changes per-frame in a layout that may or may not change per-frame, e.g. editable text in an editor.

Lexkit doesn’t cache any data by default, but exposes an API that allows applications to manage their own caches:

// Context: Cache this as long as we make calls to lexkit.
LkContext ctx;
lkCreateContext(&g_lk_unicode_data, num_workers, NULL, &ctx);

// Font: Cache this as long as font remains relevant
LkFont font;
lkCreateFont(&ctx, "C:/Windows/Fonts/arial.ttf", 20, &font);

// Per-text operations: UTF-8 decode, BiDi, shaping, break computation, etc.
//  Cache this object if the text remains unchanged.
LkText text;
lkCreateText(&ctx, &font, utf8, utf8_len, &text);

// Per-layout operations: line fitting, reordering, positioning, etc.
//  Cache this object if the text AND rect it's laid out into remains unchanged.
LkVertexDescriptor_Text quads[MAX_QUADS];
int32_t quad_count = 0;
lkLayoutText(&ctx, &font, &text, width, height, scroll_y, MAX_QUADS, quads, &quad_count);

Efficient UTF-8 decoding

Lexkit accepts text in the UTF-8 encoding, and thankfully the process of decoding UTF-8 to 32-bit Unicode codepoints is well-covered with a variety of approaches [8]. We use the simple lookup table approach originally from Bjoern Höhrmann [7].

// "Flexible and Economical UTF-8 Decoder" by Bjoern Hoehrmann

#define UTF8_ACCEPT 0
#define UTF8_REJECT 1

static const uint8_t utf8d[] = {
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, // 00..1f
  ...
  0xb,0x6,0x6,0x6,0x5,0x8,0x8,0x8,0x8,0x8,0x8,0x8,0x8,0x8,0x8,0x8, // f0..ff
  0x0,0x1,0x2,0x3,0x5,0x8,0x7,0x1,0x1,0x1,0x4,0x6,0x1,0x1,0x1,0x1, // s0..s0
  ...
  1,3,1,1,1,1,1,3,1,3,1,1,1,1,1,1,1,3,1,1,1,1,1,1,1,1,1,1,1,1,1,1, // s7..s8
};

static inline uint32_t Utf8DecodeStep(uint32_t* state, uint32_t* codep, uint32_t byte)
{
  uint32_t type = utf8d[byte];

  *codep = (*state != UTF8_ACCEPT) ?
    (byte & 0x3fu) | (*codep << 6) :
    (0xff >> type) & (byte);

  *state = utf8d[256 + *state*16 + type];
  return *state;
}

Additionally, we have a fast path for ASCII characters that can decode 8 codepoints at the same time, shown below. These two optimizations together bring The Odyssey decode times down from 19 ms to 0.8 ms.

static uint64_t Utf8Decode(const uint8_t* s, uint64_t n, uint32_t* o_codepoints)
{
  ...
  while (i < n)
  {
    if (state == UTF8_ACCEPT)
    {
      // Fast path for ASCII characters
      while (i + 8 <= n)
      {
        uint64_t chunk;
        memcpy(&chunk, s + i, 8);
        if (chunk & 0x8080808080808080llu)
          break;
        if (o_codepoints)
          for (int k = 0; k < 8; k++)
            o_codepoints[count + k] = s[i + k];
        count += 8;
        i += 8;
      }
      if (i >= n)
        break;
      start = i;
    }
    // Lookup table that supports longer codepoints
    Utf8DecodeStep(&state, &cp, s[i]);
    ...
  }
  return count;
}

Fast Paths

On the subject of fast paths, it is extremely beneficial to identify the most common case for each stage of the pipeline and have a specialized code path to deal with it. While this can be dependent on the language, locale and script you expect to deal with most commonly, at the absolute minimum including special code paths for the simplest case is almost always a huge win. All of these results are measured using single-threaded mode.

Pipeline Stage	Fast Path	Before	After
UTF-8 Decoding	Load 8 consecutive bytes in a 64-bit integer, test for ASCII and copy over if test passed	19 ms	0.8 ms
BiDi Classes	Look up bracket pairs only for codepoints of class `Other Neutral`. Every other class is never a bracket.	31.9 ms	5.0 ms
BiDi Level Runs	Skip the majority of rules if the paragraph contains no RTL or numeric characters	14.5 ms	2.5 ms
Break Analysis	Between two ASCII letters there is never a line, word or grapheme break.	24.2 ms	20.7 ms
Reordering & Positioning	Emit quads only for lines inside the viewport and stop at the first line below it	3.1 ms per frame	0.02 ms per frame

Data structures: The Two-Step table

Most Unicode algorithms (Line breaking [5] [6], BiDi handling [4], etc.) involve classifying codepoints into Unicode classes. This is given by specification files [3] that map ranges of codepoints to classes. Each specification file contains these mappings for a specific property, for example here’s what some of these files look like:

# LineBreak-16.0.0.txt
# @missing: 0000..10FFFF; XX

0020           ; SP # Zs         SPACE
0028           ; OP # Ps         LEFT PARENTHESIS
0029           ; CP # Pe         RIGHT PARENTHESIS
002D           ; HY # Pd         HYPHEN-MINUS
0041..005A     ; AL # Lu    [26] LATIN CAPITAL LETTER A..LATIN CAPITAL LETTER Z
...
05D0..05EA     ; HL # Lo    [27] HEBREW LETTER ALEF..HEBREW LETTER TAV
...
4E00..9FFF     ; ID # Lo [20992] CJK UNIFIED IDEOGRAPH-4E00..CJK UNIFIED IDEOGRAPH-9FFF

Of course, looking up all these codepoints naively results in a totally unacceptable runtime. The typical strategy is to compress the mapping into a data structure called a Two-Step table [2] [16]. To construct a Two-Step table, we first divide the overall codepoint range, $U = 1,114,112$ into blocks of size $N=256$ resulting in $K=\lceil U/N\rceil =4352 $ blocks. The specification contains a mapping to Unicode classes for these $N$ consecutive codepoints. If we look at all $K$ sequences of $N$ consecutive mappings, we note that there are $M$ unique sequences with $M \ll K$. This is because there are large sequences of codepoints that belong to the same class.

Two-Step tables exploit this property. A Two-Step table consists of two lookup tables. The upper level table translates codepoints into indices of the second table. The second table contains $M$ unique sequences of mappings described above. For Unicode classes, this is far more runtime and memory efficient than an off-the-shelf hashmap.

We can see the impact of Two-Step tables on lookup performance for our Odyssey example by cumulatively switching each individual property from a linear lookup to a Two-Step table, as the chart below shows:

Baking Unicode Specification

Lexkit exposes the ability to load arbitrary specification files, essentially future-proofing against new Unicode versions. This allows us to build the Two-Step tables for any version of Unicode at runtime.

LkUnicodeSpecInfo spec = {0};
spec.str_path_lb     = "ucd/LineBreak.txt";
spec.str_path_wb     = "ucd/auxiliary/WordBreakProperty.txt";
spec.str_path_gb     = "ucd/auxiliary/GraphemeBreakProperty.txt";
spec.str_path_gc     = "ucd/UnicodeData.txt";
spec.str_path_eaw    = "ucd/EastAsianWidth.txt";
spec.str_path_incb   = "ucd/DerivedCoreProperties.txt";
spec.str_path_ep     = "ucd/emoji/emoji-data.txt";
spec.str_path_bidi   = "ucd/extracted/DerivedBidiClass.txt";
spec.str_path_bidipb = "ucd/BidiBrackets.txt";

LkUnicodeData ud = {0};
if (lkTryLoadUnicodeDataFromSpec(arena, &spec, &ud))
{
  LkContext ctx;
  lkCreateContext(&ud, num_workers, NULL, &ctx);
}

Realistically though, it’s preferable to select the latest Unicode version and build against that. To avoid paying the Two-Step construction time at startup, we bake all the data to a header. When I started work on lexkit, this was Unicode 16, so adding it as a header here skips this cost entirely while increasing the source code size by ~650 KB, and the linked binary by 1 MB.

SIMD instructions

Using the microarchitecture exploration report from Intel VTune, we observed that one of the hotspots for our Odyssey example was in performing Two-Step table lookups over the text data. VTune indicates that the retirement rate is high:

which indicates that reducing the number of instructions is a natural way to proceed. These lookups are independent of each other and so can be easily split up to multithreaded jobs. To improve single-threaded performance (which also helps with multithreaded performance), we can use SIMD instructions instead. Here’s an example with AVX2 [11]:

#define BLOCK_P2 8
#define BLOCK_SIZE (1 << BLOCK_P2)
#define BLOCK_MASK ((1 << BLOCK_P2) - 1)

int32_t LkTwoStepLookup(LkTwoStep* ts, uint32_t ch)
{
  uint32_t block0_i = ch / BLOCK_SIZE;
  uint32_t block1_i = ts->block0[block0_i] * BLOCK_SIZE + (ch % BLOCK_SIZE);
  return ts->block1[block1_i];
}

__m128i LkTwoStepLookupAvx2(LkTwoStep* ts, __m128i ch)
{
  const __m128i block_mask = _mm_set1_epi32(BLOCK_MASK);
  __m128i block0_i = _mm_srli_epi32(ch, BLOCK_P2);
  __m128i block1_idx = _mm_i32gather_epi32(ts->block0, block0_i, 4);
  __m128i block1_start = _mm_slli_epi32(block1_idx, BLOCK_P2);
  __m128i block1_offset = _mm_and_epi32(ch, block_mask);
  __m128i block1_i = _mm_add_epi32(block1_start, block1_offset);
  __m128i lk_result = _mm_i32gather_epi32(ts->block1, block1_i, 4);
  return lk_result;
}

static void GetGlyphAtIndexAvx2(const uint32_t* codepoints, int32_t len_codepoints, int32_t idx, const LkUnicodeData* ud, Glyph* o_glyphs)
{
  ...
  // Get codepoint

  __m128i idx_vec = _mm_loadu_epi32(idx_arr);
  __m128i codepoint_vec = _mm_i32gather_epi32(codepoints, idx_vec, 4);

  __m128i lbc_vec = LkTwoStepLookupAvx2(ud->ts_lb, codepoint_vec);
  __m128i wbc_vec = LkTwoStepLookupAvx2(ud->ts_wb, codepoint_vec);
  __m128i gbc_vec = LkTwoStepLookupAvx2(ud->ts_gb, codepoint_vec);
  __m128i gc_vec = LkTwoStepLookupAvx2(ud->ts_gc, codepoint_vec);
  __m128i eaw_vec = LkTwoStepLookupAvx2(ud->ts_eaw, codepoint_vec);
  __m128i incb_vec = LkTwoStepLookupAvx2(ud->ts_incb, codepoint_vec);
  __m128i extended_pictographic_vec = LkTwoStepLookupAvx2(ud->ts_ep, codepoint_vec);
  ...
}

This improves performance significantly, reducing break computations in single-threaded mode by 12.7 ms.

Better Algorithms for BiDi reversals

The BiDi reordering step of the pipeline involves successively reversing large sections of text. See my description in the previous article here A trip through the text rendering pipeline. The Unicode standard [4] allows for $K=125$ maximum levels of BiDi nestedness, so this is $O(NK)$ by default, far above what’s ideal in a real-time setting. By preprocessing the BiDi levels, we can get a far faster algorithm where each codepoint is moved at most once:

This has a powerful effect on The Odyssey example’s performance, reducing it by 32 ms per frame, or 4.3 times faster than the naive BiDi reordering stage.

Multithreading

As we explained in the previous article, text layout can be divided into a number of hierarchical steps: Paragraphs, BiDi runs, lines, codepoints, etc. As a result, converting optimized single-threaded code into multithreaded code quickly becomes a no-brainer. By default, lexkit operates in single-threaded mode; however, you can specify the num_workers parameter at context creation time to create a multithreaded context.

We use a lockless job queue in lexkit. This means that there are no mutexes or locks used to synchronize threads, in favor of a simplified architecture that only uses atomics and semaphores. The benefit of this format is that it’s guaranteed to make progress without the possibility of deadlocks. Here’s what the job API looks like:

typedef void (*LkJobFunc)(int worker_id, void* data);

typedef struct
{
  LkJobFunc func;
  void* data;
} LkJob;

LkJobQueue* lkJobQueueCreate(LkAllocator* alloc, int num_workers);
void lkJobQueuePush(LkJobQueue* queue, LkJob job);
void lkJobQueueWait(LkJobQueue* queue);
void lkJobQueueDestroy(LkJobQueue* queue);

For example, this is how BiDi classes are computed for every codepoint:

typedef struct
{
  int i;
  int sz;
  const LkUnicodeData* ud;
  const uint32_t* codepoints;
  BidiUnit* o_units;
} ComputeBidiUnitData;

static void ComputeBidiUnitJob(int worker_id, void* data)
{
  ComputeBidiUnitData* cdata = data;
  for (int i = cdata->i; i < cdata->i + cdata->sz; i++)
  {
    cdata->o_units[i] = BidiUnitCreate(cdata->codepoints[i], cdata->ud);
  }
}

void lkComputeBidiUnits(
    LkContext* ctx,
    LkArena* arena,
    const uint32_t* codepoints,
    int32_t len_codepoints,
    BidiUnit** o_units)
{
  ...
  int32_t work_chunk = len_codepoints / ((ctx->queue->num_workers + 1) * 4);
  if (work_chunk < 16384) work_chunk = 16384;
  int32_t num_chunks = (len_codepoints / work_chunk) + (len_codepoints % work_chunk > 0);
  ComputeBidiUnitData* job_data = APushArrayNZ(scratch, ComputeBidiUnitData, num_chunks);
  int chunk_i = 0;
  for (int32_t i = 0; i < len_codepoints; i += work_chunk)
  {
    job_data[chunk_i].i = i;
    job_data[chunk_i].sz = (i + work_chunk > len_codepoints) ? (len_codepoints - i) : work_chunk;
    job_data[chunk_i].ud = ctx->ud;
    job_data[chunk_i].codepoints = codepoints;
    job_data[chunk_i].o_units = *o_units;
    LkJob job;
    job.func = ComputeBidiUnitJob;
    job.data = &job_data[chunk_i];
    chunk_i++;
    lkJobQueuePush(ctx->queue, job);
  }
  lkJobQueueWait(ctx->queue);
  ...
}

Splitting up the work among jobs is simple. For trivially parallel tasks like looking up Unicode classes from codepoints, this is a simple matter of dividing the entire text corpus into blocks then submitting the ranges into the job queue. For tasks that involve variable output, such as converting a list of codepoints into BiDi runs, we need two passes. The first outputs the results for each job to a worker-local arena. Then we perform a prefix sum on the main thread and dispatch the second stage that copies the results to a shared central array.

Of course, multithreading represents the biggest potential for performance improvement. Our single-threaded performance is already superior to Unicode’s reference implementation which is entirely single-threaded by design. At num_workers >= 1, we handily beat them:

We notice that num_workers over 8 does not help with performance further on this text corpus for our machine. The Intel i7-12700K has 8 Performance cores and 4 Efficiency cores, which support 20 threads in total. At each multithreaded stage, the total input data is divided into chunks which are assigned to jobs. The number of workers and chunks is related by the formula: chunk_size = max(len / ((num_workers + 1) * 4), 16384). As chunk size increases, the number of jobs decreases and work done as part of an individual job increases. There’s a tradeoff between the overhead associated with a job and the parallel speedup offered by multiple workers [13], so increasing num_workers beyond a certain threshold will likely lead to performance degradation rather than improvement. Our formula for chunk size limits the maximum number of jobs so instead of degradation we see stagnation at higher worker counts.

Conclusions and Future Work

This covers the major steps along the way of getting lexkit to where it is today, but there were many smaller steps that helped bring runtimes down and many things that could still be improved. I encourage readers to take a look at the project on GitHub.

Here are some things that I would like to look at in the future, given time:

SIMD instructions could be extended to far more areas than just Two-Step table lookup. It’s likely that Line Breaking and the Bidirectional Text Algorithm could also be accelerated by vectorized instructions. Currently codepoints and their associated data are stored in an Array-of-Structs (AoS) format. It’s likely that moving to a Structure-of-Arrays format would be necessary for further progress in this area.
This optimization process was entirely contained to the CPU since the GPU side of rendering quads offers little opportunity for significant performance wins. However, it’s clear that large sections of the text rendering pipeline could be ported to compute shaders. As far as I know this isn’t done by any major text layout library and would be interesting to pursue.

References

[1] Unicode Consortium. ICU - International Components for Unicode

[2] Unicode Consortium. The Unicode Standard, Core Specification, Chapter 5: Implementation Guidelines

[3] Unicode Consortium. Unicode Standard Annex #44: Unicode Character Database

[4] Unicode Consortium. Unicode Standard Annex #9: Unicode Bidirectional Algorithm

[5] Unicode Consortium. Unicode Standard Annex #14: Unicode Line Breaking Algorithm

[6] Unicode Consortium. Unicode Standard Annex #29: Unicode Text Segmentation

[7] Bjoern Hoehrmann, 2010. Flexible and Economical UTF-8 Decoder

[8] John Keiser and Daniel Lemire, 2021. Validating UTF-8 In Less Than One Instruction Per Byte

[9] Ryan Fleury, 2022. Untangling Lifetimes: The Arena Allocator

[10] Microsoft. VirtualAlloc function (memoryapi.h)

[11] Intel. Intel Intrinsics Guide

[12] Intel. Intel VTune Profiler User Guide

[13] Gene M. Amdahl, 1967. Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities

[14] HarfBuzz Manual

[15] Homer, translated by Alexander Pope. The Odyssey, Project Gutenberg eBook #3160

[16] Peter Kankowski, 2006. Two-stage tables for storing Unicode character properties

A trip through the text rendering pipeline

2025-04-30T00:00:00-07:00

Text rendering is a major pain point while developing UIs or editors for graphics applications. Moving beyond simple monospaced, single-line ASCII text can be incredibly complicated. This article attempts to document the sequence of steps to go from an array of Unicode text data to letter shapes on screen as simply as possible. I’ll use lexkit, a text layout library I wrote, as a point of reference throughout. We’ll cover different encoding schemes, Bidirectional (BiDi) text, Unicode-compliant line and word breaking algorithms, hyphenation schemes and more.

Table of Contents

Rendering Text

Text Encodings

Paragraph Splitting

Bidirectional Text

Text Shaping

Line, Word and Grapheme Breaks

Hyphenation

Text Layout

Rendering Text

Fonts can be thought of as collections of Glyphs: symbols that represent the letters, numbers and other symbols in the font’s typeface. Glyphs are typically described as vectors, i.e. lists of resizable shapes and lines that can losslessly scale to arbitrary sizes. They also contain important metrics about the dimensions they occupy on screen, key of which is the x-advance or amount by which a cursor should move forward after displaying the glyph at its current location. [1]

The problem we are going to solve in this post is of the following form. We have as input:

A buffer containing text data.
A font, style (bold, italic, etc.) and size we want to use.
The language the text is written in, which a few later stages depend on.
A window or subregion of a window we want to render that text into.

The desired output of this text layout system is a list of glyph indices along with the coordinates, height and width they occupy on screen.

There are three primary ways to draw a glyph to screen:

We can preprocess the font to a texture that contains all glyphs in the font sizes and styles we desire. This texture is typically called a font atlas, and resembles other texture atlases common in graphics programming, e.g. the shadow map atlas. Then, we can translate a glyph index to the texture space rectangle (uv-extent of the glyph in the atlas), and blit it to the screen-space rect outputted by our text layout system. This is typically referred to as bitmap text rendering.
We can store a signed distance field in the atlas instead of the rasterized glyph. In this scenario, each texel in the atlas stores how far it lies from the nearest glyph edge, and whether it falls inside or outside the glyph by its sign. This can be rendered by applying a threshold to this distance in a shader, which lets an atlas serve multiple font sizes. [2]
Finally, we can just render the text to screen directly by drawing the vector shapes in the size and position described by the text layout system. The Slug algorithm is a popular choice for this method. [3]

Text Encodings

ASCII text is easily represented in C as an array of 8-bit integers or chars. But what happens when we need to describe characters that don’t belong to the English language, emoji or other complex symbols? Unicode 16.0 defines over 150,000 unique characters, far beyond the maximum that can be represented by 8 bits. To represent this large space of potential symbols or codepoints in a byte-efficient manner we need an encoding scheme.

A simple way to extend out of ASCII into codepoints that require more than 8 bits is through the use of a variable-size encoding scheme, where a single codepoint is represented by one or more chars. We split the bit sequence between multiple bytes and use a special header in the first byte indicating how long the sequence is. Finally we mark up the trailing bytes with the 10 prefix so that we know which bytes are part of the same codepoint. This is called UTF-8.

Codepoint range	Bytes	Encoding
U+0000 - U+007F	1	`0xxxxxxx`
U+0080 - U+07FF	2	`110xxxxx` `10xxxxxx`
U+0800 - U+FFFF	3	`1110xxxx` `10xxxxxx` `10xxxxxx`
U+10000 - U+10FFFF	4	`11110xxx` `10xxxxxx` `10xxxxxx` `10xxxxxx`

We’re going to proceed with the assumption that we’re working with text encoded using UTF-8, which is by far the most common encoding scheme out there these days. It’s crucial to be aware of what input scheme you’re working with however, there are other common encodings out there and assuming the wrong encoding scheme can lead to unexpected results. For example, the Win32 API decided to use a 16-bit scheme decades ago, and has been stuck with that ever since. You can learn more about text encodings at [4]. Luckily, most OSes and text libraries provide API functions to translate between encodings.

Paragraph Splitting

Laying out a body of text can be thought of as a hierarchy where the top is your entire piece of encoded bytes and the bottom are the individual glyphs that make it up. Sequentially, we split the body into small chunks, each of which can be split into smaller chunks independently. The first level of this hierarchy is the paragraph level. While it may seem obvious that paragraphs can be split via typical line breaking characters like CR and LF, Unicode specifies a whole class of codepoints that break paragraphs, aptly named the Paragraph_Separator class. [5]

Bidirectional Text

English, Spanish, French and most other Western languages flow from Left-to-Right (LTR). This means that successive glyphs typically flow in that direction for text segments that are part of these languages. In contrast, languages like Arabic and Hebrew flow from Right-to-Left (RTL). Handling both directions, possibly mixed in a single text corpus, is called BiDi handling.

BiDi handling begins by assigning each codepoint a BiDi class: a Unicode property describing how that codepoint behaves directionally. [6] Codepoints can be strongly LTR, strongly RTL, a neutral character like a space or a bracket, and so on. The Unicode Bidirectional Algorithm [5] resolves these classes into an embedding level for every codepoint, an integer where even values run LTR and odd values run RTL. The paragraph then decomposes into BiDi runs: maximal sequences of consecutive codepoints that share a level.

Why isn’t this as simple as assigning each codepoint a direction and reordering them as such? Let’s look at a tricky sentence where an English phrase is quoted within a Hebrew sentence, and there is another RTL sequence within the English phrase.

The naive approach ends up placing them in the wrong position. Correct reordering works from the deepest nesting level outward and is described in the Unicode Bidirectional Algorithm [5], under “Reordering Resolved Levels”. At each step we reverse every contiguous span of codepoints at that BiDi level or deeper, so a BiDi run at level i will be reversed i times.

Text Shaping

Text shaping refers to the process of converting a list of codepoints to a list of glyphs. This is a relatively complicated operation since the mapping runs in both directions: multiple codepoints may collapse into a single glyph (combining characters, ligatures, emoji sequences, etc.), and a single codepoint may expand into several glyphs. Additionally fonts may contain multiple glyph options for a single codepoint and the shaping engine needs to figure out which one from context. A font file’s Character to Glyph Index mapping table (cmap) supplies a default glyph for each codepoint. After that, two additional tables are used to perform contextual decisions. GSUB substitutes glyphs based on context (e.g. substituting consecutive glyphs with a ligature), and GPOS adjusts their positions relative to one another (e.g. for kerning). [7] HarfBuzz is generally recognized as the standard for text shaping engines and we use it for the shaping stage in lexkit. [8] We run it over each BiDi run individually since HarfBuzz exclusively handles shaping and isn’t able to perform other tasks in the pipeline such as BiDi handling or Line breaking.

This article is mainly concerned with rendering a single text block with a single font and style that is known ahead of time, which is more relevant for game UIs and graphics demos. It’s worth mentioning that applications like Web browsers and rich text editors have another level of hierarchy that we need to consider before shaping. Shaping engines work on a single script at a time, so a run spanning more than one script has to be split further. This means, for example, that English (Latin script) and Russian (Cyrillic script) can’t be part of the same shaping run despite both being left-to-right languages.

Additionally, shaping engines only work on a single font at a time, which means rich text editors must segment their text input according to font family, style and size. A robust application should also switch between fonts when the initial font is missing glyphs for some of the codepoints in the run, using a fallback font for that section of text. This additional decomposition before shaping is called itemization and is sufficiently complex to demand an article on its own. For our UI purposes, we can generally accept that we are dealing with a fixed number of fonts and styles and can assume that the text input is well-behaved, but for use cases where this isn’t true [9] is a good starting point for itemization.

Line, Word and Grapheme Breaks

Once we have our glyphs from the text shaping stage, we can work out how much space a piece of text occupies.

The shaping engine returns an x-advance and an offset for each glyph, which we accumulate to find how far the cursor travels along the line. The font atlas stores the dimensions of each glyph’s rasterized bitmap, describing the rendered symbol that actually appears on screen, which can extend past the glyph’s advance. Vertically, glyphs can be thought of as lying on a baseline, with a maximum extent above (the ascent of the font) and below (descent) which are specified in the font file and can be recorded as part of the Font Atlas. Additionally, a recommended distance between successive baselines is also recorded. Together, these metrics tell us the width and height a piece of text would occupy as a single line. Very useful in a UI setting where we might want to center it within another element, or grow a container to the size of text.

However, the most common way to render text is to a fixed-width container or window. In this case, we must automatically determine where to move on to the next line. This is called a Line break [10]. Following our hierarchical model of text rendering described earlier, we can think of each paragraph being decomposed into lines.

Unfortunately, this is not as easy as writing out glyphs until we exceed the line size for many reasons:

It is difficult to read text that is broken up at a glyph level.
Certain glyphs only read correctly when present consecutively, so they must not be broken between lines.
It’s common to insert a hyphen to indicate a word is broken up between two lines, so we need to reserve space for the hyphen if we choose to break up a word.
The cursor must change from LTR to RTL depending on the glyphs being rendered.
There are certain glyphs that enforce a line break immediately after them.

The Unicode Line Breaking Algorithm [10] describes this process. The input to this algorithm is a single paragraph of codepoints and the output is a list of positions where a line break is required, optional or prohibited. It does this by mapping every codepoint in Unicode to a Line Breaking Class, then defines a set of rules about which kinds of breaks are permitted between which groups of classes. We will describe an efficient way of implementing this algorithm in a future optimization article.

We can then group glyphs into lines as follows:

Use the Unicode Line Breaking Algorithm to determine a set of valid line break positions for the paragraph.
Accumulate consecutive glyphs, adding up their x-advances until the sum exceeds the line width.
Wind back to the previous valid line break position, and break there.

This is a greedy algorithm: every line is filled as far as it can be before we move on. To improve the evenness of line lengths, line breaking can additionally be performed on an entire paragraph at once, where candidate break locations are scored based on the gaps left behind. The Knuth-Plass line breaking algorithm used in TeX is the best example of this. [11]

Lines can be further broken down into words, and words can be similarly broken down into sequences of one or more codepoints called grapheme clusters [12].

While grapheme clusters may look like a single character in most cases, they do not always map to a single codepoint. For example, an accented letter may be composed of a base letter codepoint followed by a combining mark codepoint representing the accent. Flag symbols are represented by pairs of regional indicator codepoints and complex emoji can be divided into multiple codepoints connected by special codepoints called zero width joiners.

It makes no sense to break these codepoints up for line breaking or selection purposes. Grapheme clusters represent the lowest logical level of separation. Each of the above examples is a single grapheme cluster spanning several codepoints. The boundaries described by grapheme breaks are what a text editor uses to decide how far the cursor travels when you press an arrow key, or how much text a single backspace removes. Similar to line breaks, grapheme break locations are described by classifying codepoints into Grapheme Break Classes and specifying rules for legal breaks between them. [12]

Word breaks should be more intuitive. Pressing Ctrl + an arrow key advances the cursor forward or backward across word boundaries. In English, words are typically separated by spaces or other punctuation. Unicode’s Word Break Specification [12] again describes legal word break locations using a set of rules between Word Break Classes, where every Unicode codepoint maps to a class. If hyphenation is disabled, line break locations are also word break locations.

You may notice we described both line breaking and BiDi as operating on paragraphs instead of at two different levels in the hierarchy. This is because a single line can contain more than one directionality of text. So when accumulating x-advances for a line, we can do so freely across BiDi runs.

Hyphenation

What if we need to line break inside a word? In typical text layouts, this split is accompanied by a hyphen, and choosing an optimal break position within a word is called Hyphenation.

This can be a language-specific problem. TeX uses a dictionary of patterns per language to score every position in a word using Liang’s Algorithm. [13] This requires knowledge of the language used per section of text corpus as well as reliance on a fixed dictionary.

We use a simpler, greedy algorithm for lexkit. Since grapheme breaks already indicate which positions a word can be broken at without breaking things like emoji sequences, we call any break at a grapheme cluster boundary legal. Then we sweep over grapheme boundaries such that both the first half of the word and a hyphen fit on the original line, accounting for the kerning advance between the last glyph and the hyphen itself.

This approach needs no language-specific data at all, at the cost of breaking words at slightly less legible positions. For example, TeX implementations may favor breaking the word talking as talk- + ing, while our algorithm wouldn’t favor any specific position for that word.

Text Layout

Finally, we have a list of lines composed of glyphs, with each glyph belonging to a BiDi run. It’s here that we can apply the BiDi reordering algorithm described in the Bidirectional Text section, reorganizing the glyphs of a line into a left-to-right ordering regardless of the actual BiDi orientation.

Now we have the list of glyphs in visual order for this line and can lay them out. The cursor starts at the left edge of the line and moves forward by each glyph’s x-advance. Glyph metrics from the shaping stage specify the offset at which the glyph’s bitmap should be positioned relative to that cursor. Vertically, the first baseline of a text corpus sits one ascent below the top of our container, and each successive line moves the baseline down by the recommended distance between baselines. A glyph is then placed relative to its baseline using the extents recorded in the atlas. This gives us screen-space rects for every glyph, parameterized by x, y, height and width. From the font atlas, we retrieve a similar rect in UV space. Now text rendering reduces to a simple alpha-blended blit operation, highly efficient on the GPU.

References

[1] FreeType Glyph Conventions

[2] Chris Green, 2007. Improved Alpha-Tested Magnification for Vector Textures and Special Effects

[3] Eric Lengyel, 2017. GPU-Centered Font Rendering Directly from Glyph Outlines

[4] Joel Spolsky, 2003. The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

[5] Unicode Consortium. Unicode Standard Annex #9: Unicode Bidirectional Algorithm

[6] Unicode Consortium. Unicode Standard Annex #44: Unicode Character Database

[7] Microsoft. OpenType Specification

[8] HarfBuzz Manual

[9] Raph Levien, 2020. Text layout is a loose hierarchy of segmentation

[10] Unicode Consortium. Unicode Standard Annex #14: Unicode Line Breaking Algorithm

[11] Donald E. Knuth and Michael F. Plass, 1981. Breaking Paragraphs into Lines

[12] Unicode Consortium. Unicode Standard Annex #29: Unicode Text Segmentation

[13] Franklin Mark Liang, 1983. Word Hy-phen-a-tion by Com-put-er

Catalyst

2022-06-15T00:00:00-07:00

A real-time rendering engine built in Vulkan and Modern C++

Example Scene	Scene open in Editor

The next-generation of graphics APIs, Vulkan and DirectX 12, are quickly becoming the new foundation for games on PC. I wanted to build a rendering engine that allows me to easily explore and experiment with some of the most important features of modern real-time graphics systems found in games today. The result of this work was Catalyst - a physically-based real-time renderer built in Vulkan and modern C++. This post will demonstrate what goes into rendering a simple scene using Catalyst with all effects turned on, with comments on the implementation details in Vulkan. For the project source code and full list of graphics and editor features, a public repository is available here.

Table of Contents

Overview

Shadow mapping

Z-Prepass

Screen-Space Ambient Occlusion

Screen-Space Reflections

Skybox

Main render pass

HDR/Tone mapping

Debug Draw

Editor

Overview

Catalyst is a fully-forward renderer that uses bindless resources. This is a flowchart of a single frame:

Shadow mapping

For every directional light, a shadowmap is generated. The Catalyst editor has options to tweak the width and height of the directional lights effect, ideally this should be as small as possible to make maximum use of the Shadow Map’s limited resolution. There are a number of additional parameters relating to shadows that are exposed to the user via Global Settings. Shadowmap bias can be increased or decreased according to the scene, and the size of the PCF smoothing kernel can be modified for performance as well. The shadowmap render pass is a simple depth-only pass that applies all vertex transformations and renders to a single depth/stencil texture. The entire scene is rendered from the lights point of view. For directional lights this involves an orthographic projection.


Two shadowmaps from directional lights in the scene

Z-Prepass

Similar to the shadowmap pass, the Z-Prepass is a depth only render pass. This time the entire scene is rendered from the main camera’s perspective. Also, to enable MSAA for the main render pass, the depth image that we write here is multisampled. A single sample texture is generated at the end of this pass by resolving this depth image. The single sample texture is passed as input to the SSAO and SSR passes, while the multisampled texture is forwarded directly to the main render pass.


Resolved z-prepass depth texture

Screen-Space Ambient Occlusion (SSAO)

SSAO is implemented in a relatively straightforward manner, but there are some additional considerations for a fully-forward renderer. At the start of the scene a noise texture is generated to provide a random permutation for the SSAO kernel. The kernel consists of a variable number of rays in the hemisphere of the surface, with most rays concentrated close to the normal. Unlike a deferred renderer, we do not have a normal G-buffer to refer to and thus the normals must be reconstructed from the depthmap generated by the Z-Prepass. This can cause artifacts at the borders of objects, an example of the normal map generated by such an approach is shown below.


Example depth buffer input	Reconstructed normal data, note discontinuities at edges	Resulting SSAO Map

Overall, SSAO is a nice way to improve the scene for a relatively cheap cost. Reducing the number of rays from 64 to 16 reduces frame time significantly without degrading the final result too heavily. The SSAO map is generated in half-resolution and composited during the main render pass. Click to enlarge the below images to compare results easier.


SSAO On	SSAO Off

Screen-Space Reflections (SSR)

The inputs to this stage include the resolved depth image from the Z-prepass and the resolved previous frame. The previous frame used here is just after the main render pass and before the HDR/Tone-mapping stage. Since this is a fully forward renderer, we don’t have access to a specular G-buffer, so the previous frame is our best bet for reflection data. Getting SSR to look good depends on a number of scene-dependant parameters. Thus, many options are presented to the user to tweak their appearance. Similarly to SSAO, normals are reconstructed from the depth image and are used to find the reflection vector along the view direction. Raymarching is performed until a matching object is found in the previous frame.


SSR Map

SSR is tricky to get right, and is the most expensive step of the pipeline as of now due to heavy branching. If a reflection ray is not found, the environment cubemap is used as a fallback for reflection information.


SSR On	SSR Off

Skybox

Environmental mapping is performed using a skybox with two cubemaps. One is used to provide the specular lighting component to scene geometry, while the other is an irradiance map used for the diffuse lighting component. There are several tools available to generate these maps. One skybox is included with the editor for convenience. The first draw of every main renderpass involves drawing the skybox to the empty frame.

Main render pass

This is where everything comes together. SSAO and SSR maps and all shadow maps are inputs to this stage as textures. All material parameters and render settings are exposed in a uniform buffer, and the multisampled depthmap is attached for depth testing with the compare operation set to VK_COMPARE_OP_EQUAL. The output of this stage is a multisampled High Dynamic Range (HDR) color attachment which is resolved to a single sample texture for use in the HDR pass, compute shaders and the next frames’ SSR calculation.


HDR buffer before and after scene geometry is rendered. To display these images, the HDR values across each image were normalized independently.

HDR/Tone mapping

First a series of compute shaders is used to calculate the geometric average of the illuminance for the frame. The frame is reduced by a factor of the subgroup size each iteration. Vulkan’s subgroup extension (now part of the core Vulkan specification) is very handy for performing these reduce operations. The end result is the log-average illuminance which is fed into the Tonemapping pass as a Uniform Buffer. The tonemapping pass takes the resolved HDR output of the main render pass and maps it to a Low Dynamic Resolution (LDR) color attachment suitable for presentation. The geometric mean of the illuminance, together with a user-modifiable exposure adjustment is used to perform this mapping. The effects of the exposure setting on the final result is shown below.


Exp. = 0.5	Exp. = 1.0	Exp. = 2.0	Exp. = 4.0	Exp. = 8.0

Debug Draw

It can be helpful to draw 3D structures like bounding boxes or billboards to aid debugging during development. The Catalyst editor makes use of this feature to render icons for scene objects with no geometry such as Directional Lights, and to indicate which meshes the user has selected in the scene hierarchy by displaying a bounding box that holds all of them. This stage writes directly to the resolved color output attachment from the main render pass. This means that output from this stage is not used to compute tonemapping information or generate SSR maps for future stages, which is ideal. The downside of this approach is that MSAA is not available for this stage, which is less important for a feature that is disabled when building for release mode.


An AABB is drawn around selected meshes in the editor	Screen-aligned billboards are used to indicate selected directional lights

Editor


Modifying material properties in the Catalyst editor

The Catalyst repository on Github includes a user-friendly editor built on Qt 6 that allows you to import models and textures, edit material parameters and arrange meshes in a scene hierarchy. It comes with a number of sample assets to easily experiment with many of the engines features. Qt is not necessary to build the rendering engine itself. If you’d like to try it out, the repository is available here.