テキストは、GPUに描くようになってから、意外と簡単ではないことに気づきます。グリフはビットマップではなく、閉じたベクトル輪郭——2次または3次ベジエ曲線と直線セグメントの集合——であり、巻き数規則で塗りつぶされます。CPUではターゲットサイズで1回ラスタライズして完了しますが、GPUでは任意のスケールで1フレームに数千のグリフを、再ラスタライズを必要としない状態で描きたい。その制約が、すべての手法がトレードオフを行う場所です。
本稿は、グリフはビットマップではなく、巻き数規則で塗りつぶされた閉じたベクトル輪郭の集合であることを説明して始める。この図は、on-curve点とoff-curve点をマークして、その根本的概念を示している。
**1. テクスチャアトラス（ビットマップグリフ）** 最古で、現在も最も一般的なアプローチです。各グリフを1つのサイズで1回、共有テクスチャアトラスにラスタライズし、その後各文字をテクスチャ付きクアッドとして描画します。高速で超ポータブルで、テクスチャユニットを持つ任意のデバイスでは動作します。問題はスケールする瞬間から現れます：焼き付けたサイズより拡大するとグリフがぼけ、縮小するとストロクがきらきらと揺らめいたり消えたりする（mipレベルを焼き付けていない場合）。鮮やかなサイズごとに別のアトラスが必要です。中国語・日本語・韓国語では数万のグリフがあり、複数サイズを焼き付けるとメモリの災難です。そしてビットマップはペルスペクティブの概念がなく、3D面上のテキストはぼけたように見えます。
**2. 符号付き距離フィールド（SDF）** ValveのChris GreenがSIGGRAPH 2007でSDFを紹介しました。ピクセルの代わりに、各テクセルは最近辺への符号付き距離（内側正、外側負）を格納します。シェーダではフィールドをサンプリングし、0で閾値をかけます。距離は滑らかに補間されるため、小さいSDFテクスチャは大きな拡大でもクリーンなエッジでスケールアップし、閾値を柔らかにすることで安価なアンチエイリアスが得られます。10年間、これはクリーンなUIとHUDテキストのデフォルトでした。
しかしSDFは依然として固定解像度で焼き付けられたテクスチャであり、角の部分で間違った情報を提供する。鋭い角は距離フィールドにおける不連続点で、双線形補間によって丸められる。すべての硬い角——「A」の先端や「K」の切り込みなど——は柔らかくなる。拡大を極端にかけたり、グリフをフィールドが数テクセル程度の幅になるまで縮しすぎたりすると、細いストロクが崩れ、詳細がにじむ。
**3. マルチチャンネルSDF（MSDF）** Viktor Chlumskyの2015年の論文と2018年の論文が角の問題を解決しました。1つの距離チャンネルの代わりに、MSDFは3つ（赤、緑、青）を格納し、それぞれ鋭い角が生き残るように選ばれた異なる辺の部分集合への距離を符号化します。シェーダは3つのチャンネルの中央値をとり、角をほぼ完全に再構築します。MSDFは現在、多くのチームのスイートスポットです。Chlumskyの`msdfgen`はMITライセンスで広く採用されています。
しかし、依然としてアトラスです。各グリフをあらかじめ選んだ解像度で焼き付けるため、動的またはユーザー提供のテキスト、CJKのような巨大なグリフセットも、焼き付けパイプラインとメモリ予算を意味します。生成はプレーンSDFより高価です。非常に小さいサイズでは、細かい詳細を保持できるだけのテクセルサンプルが足りず、極端に縮小しても依然としてエイリアスと闘う。3チャンネルのルックアップはより多くの帯域を消費します。MSDFは品質の天井を引き上げますが、アトラスの制約はそのままです。
**4. テセレーションとカバレッジ（Loop–Blinn、NV_path_rendering、Pathfinder、Rive）** このファミリーはテクスチャを完全にスキップし、輪郭をGPUがラスタライズできるジオメトリに変換します。Loop–Blinnは、ピクセルごとのdiscardシェーダとステンシルの巻き数で、曲面三角形をGPUに送ります。NV_path_renderingは2パスのステンシル→カバー方式を使います。Pathfinderは辺をマイクロ三角形にテセレーションし、コンピューパスでカバレッジを蓄積します。Riveのレンダラー（2024年にオープンソース化）はアンチエイリアス済ベクトルパスをユニークな三角形パッチに減らし、ピクセルローカルストレージを持つ大規模並列パイプラインでラスタライズし、アニメーションベクトルアートで120fpsを達成します。
これらの方法は本当に解像度独立であり、アニメーション設計済ベクトルグラフィックスにはoften正しい答えです。コストはテセレーション自体（ジオメトリが変更されるとやり直し）、複雑なグリフでのジオメトリの爆発、クリーンな解析的アンチエイリアスの難しさ、および一部の場合は特定の機能や拡張への依存です。Rive特に2Dアフィン変換のみを受け入れます；ペルスペクティブ投影はアフィンではないため、最良の近似は中央では正確だが端に向かってずれていく。
**5. Slug：輪郭から直接レンダリング** Eric Lengyelは2017年にSlugを発表し、2019年に特許化し、2026年3月17日にその特許をパブリックドメインに寄付しました。Slugはアトラスと毎フレームのテセレーションをスキップします。グリフを、小さいGPUバッファ内の2次ベジエ曲線と線分のリストとして保持し、伴随に、グリフを水平帯に分割することであるピクセルが近いごく少数の曲線だけを考慮できるようにする、軽量なグリフごとの加速構造を添えます。
カバレッジはフラグメントシェーダで直接解決されます。各ピクセルごとに、シェーダは実質的に光線を投げ、その光線が近いベジエ曲線とどこで交差するかを見つけるし、交差数をカウントして巻き数を計算し、結果としてカバレッジを出します。Lengyelの主要なイノベーションは*root-eligibility*テストです：どの曲線-光線交差をカウントすべきかの正確な規則であり、曲線が接する共有エンドポイントで巻き数計算が正確になり、素朴なアプローチではひび割れや二重カウントが発生するのを防ぎます。シェーダが焼き付けたフィールドをサンプリングする代わりに曲線方程式を解析的に解くため、任意のスケールで正確なカバレッジとクリーンなアンチエイリアスが生成されます。
焼き付け解像度がないため、同じグリフは6ピクセルでも6,000ピクセルでも鋭く、変換*p後*にピクセルごとにカバレッジを計算するため、任意の2D・3D変換——ペルスペクティブを含む——下でも鮮やかに保たれます。アトラスがないため、10万のCJKグリフは、ビデオサイズのアトラスではなく、フォント1つ分の輪郭データで済みます。テキストは焼き付けコストゼロで毎フレーム変更でき——ライブデータ、ユーザー入力、ローカライズ済みコンテンツにぴたりです。これは通常のフラグメントシェーダで1回の描画で完結し、ベンダー拡張は不要です。
これは、テキストがどう視されるか予測できない場合に重要です。アトラス、SDF、MSDFはすべて、あらかじめ固定解像度を焼き付け、画面サイズと視点角度の範囲が限定されていると黙って仮定します。テキストプレーンとカメラの関係が事前にわからない——自由な3Dカメラ、任意ズーム、クローズアップ、または急なオフ軸グレイジング角度——場合、それらの焼き付け近似は崩壊します：焼き付け解像度以上に拡大するとアトラスはぼけ、SDFとMSDFは丸みとじみを出します；斜め角度ではサンプルされたフィールドがエイリアスします。すべての視点に対して十分な解像度を事前に確保することは、ストレージが爆発するまで不可能です。Slugは変換後、ピクセルごとに解析的にカバレッジを計算するため、視点がどの程度近い、遠い、斜めでも正確です。テセレーションはこの性質を共有する唯一の他のファミリーで、その代わりにテセレーション費用と難しいアンチエイリアスを支払います。
**違いを見てみよう** AlphaPixelは、単チャンネルSDF、MSDF、Rive、`osgText`ビットマップ（および由此派生したSDF）の横に、`osgSlug`統合（Slughorn）で同じ大文字**R**をレンダリングしました。すべてのテクスチャベースのパネルは同じ予算：1emあたり64テクセル。
本稿の「違いを見てみよう」セクションでは、まず、6つのレンダラーのうち5つが実質的に同一で、ビットマップのみが拡大時に限界を示す、焼き付けサイズでの正面比較が説明される。
*焼き付けサイズで正面から：* 6つのうち5つは実質的に同一——Slughorn、Rive、MSDFが輪郭を再現する；単チャンネルSDFは脚の根元の少し丸い角の違いのみ。外れ値はビットマップで、約4×拡大された、かつてストレージしなかった詳細を回復できない。
本稿は、斜め3D視点下では、アトラス系の手法はぼけ、SDF/MSDFはよく耐えるが、Riveのアフィン専用変換によりグリフが端に向かってずれ、Slugの解析的アプローチは正確なままであることを説明する。
*グレイジング視点に傾けた：* Slughornと3つの距離フィールドパネルは、グリフ自身のプレーン内でピクセルごとにカバレッジを計算するため、クリーンなエッジで**R**を維持します。ビットマップは遠ざかるにしたがってぼけます。Riveの**R**は正しい形状ではない——そのレンダラーは2Dアフィン変換のみを受け入れるため、ペルスペクティブ投影は端に向かってずれていく。
本稿は、極端な拡大時、解析的曲線評価（Slug、Rive）は完全に鋭いのに対し、サンプルされた距離フィールドはnotchアーティファクトを出し、ビットマップは構造をすべて失うことを説明する。
*極端な拡大で単一のエッジにズーム：* カーベースのレンダラー（SlughornとRive）のみが、依然としてまっすぐでクリーンなエッジを生成する。距離フィールドパネルは、ストアされたサンプル間の補間が真の曲線と一致しないnotchが発生する。ビットマップは単一のグレー勾配に溶けた。
**ヘッドトゥヘッド要約**
| 項目 | ビットマップアトラス | SDF | MSDF | テセレーション / Rive | Slug | |---|---|---|---|---|---| | 任意スケールでの鋭さ | いいえ | 一部 | ほぼ | はい | はい | | 鋭い角 | 焼き付け時のみ | いいえ | はい | はい | はい | | 小さいサイズ | サイズごとに焼き付け | 弱い | よい | よい | よい | | CJK用メモリ | 非常に高い | 高い | 高い | 低い | 適度 | | 動的／変化するテキスト | 再焼き付け | 再焼き付け | 再焼き付け | 再テセレーション | 無料 | | 3Dとペルスペクティブ | ぼけ | 可 | 可 | よい | 優れる | | 重いアニメーションベクトルアート | いいえ | いいえ | いいえ | 優れる（Rive） | よい | | 低性能GPUで動作 | 優れる | 優れる | よい | 環境による | 能力のあるシェーダが必要 | | 実装の複雑さ | 低い | 低い | 中 | 高い | 中～高い |
**では、どちらを使えばよいのか？** 単一の勝者はおらず、作業内容に応じた正しいツールがあります。
*Slug（Slughornまたは他の実装）を選びます*：すべてのスケールと3D・ペルスペクティブ（VR/AR/XR）下で鮮やかなテキストが必要な場合、巨大または動的なグリフセットがある場合、テキストが絶えず変化する場合、または3Dシーンで混合ベクトルUIをレンダリングする場合。
*MSDFを選ぶ場合*：クリーンでスケーラブルな2D UIテキストが必要で、アトラス焼き付けパイプラインを受け入れられ、広い範囲のハードウェアで現在の品質・性能・ポータビリティの最良のバランスを求めます。
*Riveまたは他のテセレーションレンダラーを選ぶ場合*：主要内容が動きのある設計済ベクトルアート——Riveのパイプラインはそれのために設計されている。
*ビットマップアトラスやSDFを続ける場合*：制約された／旧式的なハードウェアで動いており、テキストサイズと視点角度が限定され、事前に分かっている、または最も簡単な統合が必要な場合。
**ヒンティングに関する注意** FreeTypeのような従来のCPUレンダラーは、特定のサイズで曲線をピクスグリッドに吸い付ける（バイトコードヒンティング）。Slugの主張は、サイズごとのグリフ準備を不要にすることであり、その出力は実質的にヒンティングなしになります。モニターが高密度になるにつれ、主要レンダラーはオートヒンティング（バイトコードを無視し、輪郭からヒントを導出）またはヒンティングなしに移行している。Zigポートの*Snail*などの実装は、この挙動を再現するためGPUオートヒンティングを追加しているが、Slugの採用者たち来讲まだ検討の余地がある領域です。
**シェーダエフェクトのトレードオフ** SDF/MSDFは、距離値がエッジから「どの距離」であるかを教えてくれるため、数行のシェーダコードで輪郭・発光・柔らか化を追加するのを非常に簡単にする。Slugの解析的巻き数テストは「内側か外側か」しか教えてくれない。非常に高解像度ディスプレイと大きなサイズでは、これは強み——距離フィールドアーティファクトなしの正確なカバレッジ——だが、安価な距離ベースのエフェクトを失い、アンチエイリアスを別途処理する必要がある。
**Slughorn：実用級のSlug実装** AlphaPixelの`slughorn`は、パブリックドメインのSlugテクノロジーを実装したモダンなC++20ライブラリです。グラフィック環境（OpenGL、Vulkan、WebGL、WebGPU、DirectX、Metal）について仮定せず、複数バックエンド——FreeType、NanoSVG、Skia、Cairo、Blend2D——からのベクトルデータ取り込みの簡略化に焦点を当て、さらにネイティブなCanvas風APIもサポートします。COLRv0/COLv1絵文字合成、PBR/IBLマテリアル、グラデーション、マスキング、HUD要素、2D正射影と3Dペルスペクティブ投影の両方をサポートします。`osgSlug`などのコンパニオンプロジェクトは、OpenSceneGraph/VulkanSceneGraphの統合を支援します。