
2026/09/30 22:50
SDF と MSDF と Slug:GPU テキストレンダリング
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
まとめ:
Slughorn は、VR、AR、インタラクティブ 3D などリアルタイムアプリケーションで高解像度のベクターグラフィックスをレンダリングするための、画期的な無料 C++20 ライブラリです。その核心的な革新は、Eric Lengyel の「Slug」アルゴリズムの実装であり、1 ピクセルごとに解析的にカバレッジを計算し、「ルート適合性(root eligibility)」テストを用いることで、あらゆるスケール(6 から 6,000 ピクセル)および任意の 3D 変換(透视投影を含む)において完璧に鋭いエッジを提供します。2026 年 3 月、Eric Lengyel は Slug の特許をパブリックドメインへ寄贈し、ライセンス障壁を取り除き、広範な採用を可能にしました。従来のテクスチャアトラスでは拡大時にぼやけたりキラキラしたりし、標準的な SDF/MSDF メソッドでは補間によって角が柔らかくなってしまうのに対し、Slughorn は高価なランタイムテッセレーションやテクスチャーのリベークを必要とせずにクリップした幾何形状を維持します。これは大規模なグリフセット(例:CJK 文字)、動的なテキスト変化、フル SVG レンダリングでグラデーション付きの地図カルトグラフィラベルなどの複雑なシナリオに最適です。MIT ライセンスに基づいた Slughorn は、Vulkan、WebGPU、DirectX、OpenGL の複数のグラフィックス API をサポートし、SVG、FreeType フォント、Blend2D、Cairo、Skia から供給されるパスなど、様々な入力形式を受け入れます。Head-to-head 比較により、Slug(Slughorn を通じて)は拡大倍数が極端な場合や透视の下でもクリーンなエッジと正確な形状を生成するのに対し、他の方法はアーティファクトや制限を示すことが確認されました。ライセンス費用やベンダー拡張の必要性を取り除くことで、Slughorn は高忠実度の動的ベクター幾何形状パフォーマンスにおける新たな基準を確立します。
本文
テキストレンダリングアルゴリズム選定ガイド:SDF、MSDF、Slug、テクスチャアトラス、Rive の比較
文字描画は一見すると単純ですが、CPU でビットマップに変換することは既に解決済みです。問題は GPU 上で「任意のサイズ変更」や「3D 変形」を行いながら、フレーム単位で鮮明に描画することにあります。多くのエンジンではこれを避けるため、glyph(文字字形)を事前にテクスチャとして焼き付ける(Baking)という妥協点を選んできました。
2017 年、Eric Lengyel がSlug アルゴリズムを発表し、この脱却を実現しました。フラグメントシェーダ内で線分データそのものから glyph を描画するため、テクスチャアトラスやフレームごとの Tessellation は不要です。Lengyel は特許権を 2026 年 3 月 17 日にパブリックドメインへ献呈したため、我々は C++20 実装である**「Slughorn」**を開発・公開しました。
本稿では、ビットマップアトラスから Slug までの GPU テキストレンダリング手法の現状と利点を解説します。
なぜ glyph の描画は難しいのか?
すべてのスケーラブルなフォントは、glyph をベクトル的な輪郭データ(二次または三次曲線)として格納しています。文字の内部領域とは、「巻き回し数則(Winding Rule)」によって判定される塗りつぶされた領域です。
レンダラーには以下の 3 つのタスクを高速かつ正確に行う必要があります。
- 正しく内部領域を塗りつぶすこと
- クリーンでアンチエイリアシング(AA)されたエッジを生成すること
- サイズや 3D 変形に関わらず、常に鮮明さを維持すること
CPU では目標サイズでのレンダライズで済みますが、GPU では数千の glyph を任意のスケールで描画する必要があります。これに対し「再レンダライズなし」で理想とするのは困難であり、各手法は妥協点(トレードオフ)を迫られるのが実情です。
手法比較と特徴
1. テクスチャアトラス (Bitmap Glyphs)
- 概要: 最も古く一般的。glyph を固定サイズでレンダライズして「アトラス」に焼き付け、画面の文字をテクスチャ付き四角形(Quad)として描画します。
- 長所:
- 高速かつ極めて移植性が高い。
- テクスチャユニットを持つあらゆるハードウェアで動作。
- 短所:
- 拡大縮小不可。拡大するとぼやけ、縮小させるとチカチカしたり細部が消えたりする。
- メモリ消費大。CJK 文字など数万 glyph を持つ場合、複数のサイズで焼き付けるのはメモリ上の大惨事です。
- 3D パースペクティブ下では文字が柔らかく見え、曲面に載せるのに不向き。
2. 符号付き距離場 (Signed Distance Fields, SDF)
- 概要: Valve の Chris Green が提唱。各画素に「最も近いエッジまでの距離」を格納し、シェーダ内でゼロ付近の閾値処理を行います。
- 長所:
- 小さなテクスチャを大きく拡大してもエッジがきれいに保たれる(滑らかな補間)。
- アタラクティファクトがなく、鮮明な UI テキストのデフォルトとして長年使われてきました。
- 短所:
- 角が丸まる。距離場における不連続点(鋭い角)は、バイリニア補間によって丸められてしまいます(「A」の尖った先や「K」のノッチが柔らかくなる)。
- 極端な拡大縮小では細部ディテールが滲みます。
3. マルチチャネル符号付き距離場 (Multi-Channel SDF, MSDF)
- 概要: Viktor Chlumsky が角の問題を解決。赤・緑・青の 3 チャネルを持ち、それぞれのエッジサブセットまでの距離をエンコードし、シェーダ内で**中央値(median)**を採用します。
- 長所:
- 角がシャープに保たれる。SDF のような泥のように丸まる拡大率でも鋭い角を維持できます。
- 現在のスイスポットとなっており、Chlumsky の
は MIT ライセンスで広く採用されています。msdfgen
- 短所:
- 依然としてアトラスを使用するため、事前焼き付けコストは避けられません。
- CJK などの膨大な glyph 集合ではパイプラインとメモリ予算が確保必要です。
- 極端な縮小下でもアンチエイリアシングとの戦いは続きます。
4. テッセル化とカバレッジ (Tessellation & Coverage)
- 概要: テクスチャを使わず、輪郭を GPU がレンダライズ可能なジオメトリに変換します。
- 手法:
- Loop-Blinn: グリフ三角形を供給し、ピクセル毎の Discard シェーダーとステンシルバッファで解決(質的コストが高い)。
- NV_path_rendering: 2 段階プロセス(パスをステンシルに描き込み、次にカバリング)。ベンダー依存。
- Pathfinder: エッジを微細な三角形へ Tessellation し、Compute パスでカバレッジを累積。Tile ベースで高速。
- Rive: 2024 年オープンソース化。ベクトルパスを三角形パッチに変換し、大規模並列パイプラインでレンダリング(120fps 達成)。
- 長所: 真に解像度独立性。アニメーションされたデザインベクトルグラフィックにおいて最適。
- 短所: Tessellation の計算コストがかかる。ジオメトリ変化時再実行が必要。特定ハードウェア機能への依存がある場合も。
5. Slug(Slughorn)
- 概要: アトラスやフレームごとの Tessellation をスキップ。二次ベジェ曲線のリストを小型 GPU バッファに保持し、シェーダ内で直接解析的にカバレッジを計算します。
- 仕組み:
- 光線投射法:各画素に対し光線を投射し、近くのベジェ曲線との交差点数をカウントして巻き回し数(カバレッジ)を計算。
- ルート適合性(Root Eligibility): 曲線が合流する共有エンドポイントなどで正確に巻き回しを計算するための精密なルール。
- 長所:
- 任意のスケールでシャープ。6 ピクセルから 6000 ピクセルまで、パースペクティブ変形下でもカミソリのように鮮明。
- 無限の scalability。アトラスがないため、10 万 glyph の CJK も「フォントサイズ分の輪郭データ」のコストだけで済む(動画サイズの巨大アトラスにはならない)。
- 動的テキストに最適。焼き付けコストゼロでフレーム毎の変更が可能。
- 汎用性。ベンダー拡張機能不要、単一の Draw コールで完結。
差を確認する比較結果
Slughorn( osgSlug インテグレーション)と SDF、MSDF、Rive、osgText を比較しました。すべてのテクスチャベースパネルは64 テッセル per emの予算を与え、差異は技法によるものです。
| 視点 | ビットマップ / SDF / MSDF | Slug (Slughorn) / Rive |
|---|---|---|
| 正面・焼き付サイズ | SDF/MSDF は角が丸く、ビットマップはぼやけている(拡大時)。 | シャープ。輪郭を正確に再現。 |
| パースペクティブ(斜め視点) | ビットマップはぼやける。SDF/MSDF もサンプリング誤差で劣る。 | シャープ。画素単位で解析的に計算するため歪みに強い。 |
| 極端なズームイン | SDF/MSDF は角が段差(ノッチ)付き。ビットマップは灰色に溶ける。 | 直線なシャープなエッジを維持。 |
懸念点別比較表
| 懸念点 | ビットマップアトラス | SDF (1 チャンネル) | MSDF (3 チャンネル) | テッセル化 / Rive | Slug |
|---|---|---|---|---|---|
| 任意のスケールでシャープ | × | △(部分的) | ○(大部分) | ●(最適) | ●(最適) |
| 鋭い角の保持 | △(固定サイズのみ) | × | ○ | ● | ●(最適) |
| 極めて小さなサイズ | △(バインド依存) | ×(弱い) | ○ | ○ | ●(良好) |
| 大規模 glyph 集合 (CJK) | ×(メモリ爆発) | △(高コスト) | △(高コスト) | ○(低コスト) | ○(中程度) |
| 動的・変化するテキスト | ×(再バイン必要) | ×(再バイン必要) | ×(再バイン必要) | △(再テッセル化) | ●(不要・最適) |
| 3D とパースペクティブ | △(柔らかい) | ○(可) | ○(可) | ●(良い) | ●(優秀) |
| アニメーションベクトルアート | × | × | × | ●(Rive 特化) | ○(良い) |
| 低エンド・旧 GPU | ●(優秀) | ●(優秀) | ○(良好) | △(様々) | △(能力あるステージが必要) |
| 実装の複雑さ | ●(低い) | ●(低い) | ○(中程度) | △(高い) | ○(中〜高) |
注: オリジナル資料では、Slug が「最適」または「同点」と判断された箇所は薄緑色でマークされています。
どれを使うべきか?
単一の勝者はいません。用途に応じて選択してください。
-
Slughorn を選ぶ場合
- 要件: どのサイズでもシャープな文字、VR/AR/xR などの 3D パースペクティブ下での文字、巨大または動的な glyph 集合、リアルタイムに常に変化するテキスト、自由な視点角(無限ズーム・傾斜)。
- 用途: GIS グラス・コックピット、視覚シミュレーションのラベル、宇宙ドメインディスプレイ、AR オーバーレイ、移動中でも読みやすいインターフェース。
-
MSDF を選ぶ場合
- 要件: シャープなスケーラブル文字を望むが、アトラスへの事前焼き付けが可能で、幅広いハードウェアでの動作を確保したい場合。
- 用途: シンプルなおゲームの HUD やアプリ UI の優れたデフォルトソリューション。
-
単純な SDF を選ぶ場合
- 要件: ハードウェアが制約され、テキストは比較的安定しており、角が少し柔らかいことを許容できる場合。
-
ビットマップアトラスを選ぶ場合
- 要件: テキストサイズと UI が固定されており、最もシンプルで移植性の高いものを望む場合(2D ゲームなど)。
-
Rive またはテッセル化レンダラーを選ぶ場合
- 要件: アニメーションされるデザインベクトルアートであり、主にテキストではない場合。
機能の拡張:Slughorn の Horn を吹く
Slughorn は、Slug テクニックを C++20 で実装した現代ライブラリです。
- 描画能力: テキストだけでなく、フル SVG、グラデーション、レイヤー内のシェーダー、アニメーションを含むあらゆるベクトルジオメトリ(塗りつぶし、ストローク)を描画可能です。
- 利点: 焼き付けなしで、地図製図スケールでも対応可能です。
- 互換性: SVG、FreeType、Blend2D/Cairo/Skia のパスなど既存フォーマットをインポート可能。ネイティブ Canvas スタイルの API も提供。
技術的特徴
- ビルド時の一過重作業を行い、ランタイムでの Tessellation は不要。
- GPU API(OpenGL, Vulkan, WebGPU, DirectX)への対応済み。
- Python バインディングも同梱(埋め込み HUD からフルな 3D シーンまで)。
正当なクレジット: Slug アルゴリズムは Eric Lengyel が所有し、2026 年 3 月以来パブリックドメインとなっています。Slughorn はそれを使いやすくするための我々の試みです。もしぼやけたラベルや巨大 glyph 集合の問題に直面しているなら、Slughorn が解決策となります。
よくある質問 (FAQ)
Q: テクスチャアトラス、SDF、MSDF、Slug の違いは何ですか? A: アトラスは拡大するとぼやけます。SDF は角が丸まります。MSDF は角を改善しますがアトラス依存です。Slug はアトラスを使わず、シェーダ内で輪郭から直接計算するため、どのサイズや角度でも正確さを維持します。
Q: なぜ 3D でテキストを拡大するとぼやけるのですか? A: 事前に焼き付けたビットマップアトラスを使用しているためです。固定解像度を歪めるのでエッジが柔らかくなります。Slug などの輪郭ベース手法では、変形後に画素単位で再計算するため回避できます。
Q: Slug アルゴリズムとは何ですか? A: Eric Lengyel が発表した技法で、GPU で glyph の二次ベジェ輪郭から直接描画します。「ルート適合性」テストを用いて交差点を正確にカウントし、アトラスや Tessellation を不要とします。
Q: Slug テクニックは無料で使用できますか? A: はい。Lengyel は 2026 年 3 月に特許をパブリックドメインに献呈しました。AlphaPixel の Slughorn は C++20 で MIT ライセンスされています。
Q: MSDF を Slug より使うべきですか? A: アトラス焼き付けが可能で、テキストが安定し、低コストなシェーダーを望むなら MSDF が良いです。一方、任意の角度・サイズでシャープさを保ちたい場合、巨大な glyph 集合(CJK)を使う場合は Slug(Slughorn)が最適です。
Q: 大規模 glyph 集合(日本語/中国語)は対応できますか? A: 可能です。アトラスによるメモリ爆発はありません。輪郭データを格納するため、数万 glyph でも曲線データのコストだけで済みます(ただし、 glyph ごとのバンド構造が追加オーバーヘッドになります)。
Q: Slughorn と Slug の関係は? A: Slug はアルゴリズム(Lengyel)、Slughorn はその実装(AlphaPixel)です。Slughorn は OpenGL/Vulkan/WebGPU などをサポートし、テキストだけでなく全てのベクトルジオメトリを描画できます。