GLTF 拡張機能の使用および開発ガイド

glTF 拡張機能は、基本的な glTF モデル形式を拡張します。拡張機能では、新しいプロパティ (外部データを参照するプロパティを含み、拡張機能はこのデータの形式を定義できます)、新しいパラメータ セマンティクス、保持される ID、および新しいコンテナ形式を導入できます。拡張機能は glTF の特定のバージョン用に作成されており、glTF の新しいバージョンではコア glTF に昇格される可能性があります。

glTF は、Web 上の 3D プレゼンテーションに広く使用されています。モデルを glTF 形式に変換する必要がある場合は、NSDT 3DConvertオンライン変換ツールを使用できます。
ここに画像の説明を挿入します

1. GLTF拡張メカニズム

すべての glTF オブジェクト プロパティ (glTFProperty.schema.json を参照) には、新しい拡張機能固有のプロパティを含めることができるオプションの拡張オブジェクト プロパティがあります。これにより、拡張機能はジオメトリ、マテリアル、アニメーションなどを含む glTF の任意の部分を拡張できます。拡張機能では、新しいパラメーター セマンティクス、ID の保持、glTF などの新しい形式を導入することもできます。

GLTF 拡張機能では、既存の glTF 属性を削除したり、既存の glTF 属性を再定義して他の意味を表すことはできません。

例としては次のものが挙げられます。

  • 新しいプロパティ: KHR_texture_transform 拡張機能では、次のようなテクスチャ変換プロパティのセットが導入されています。
{
  "materials": [{
    "emissiveTexture": {
      "index": 0,
      "extensions": {
        "KHR_texture_transform": {
          "offset": [0, 1],
          "rotation": 1.57079632679,
          "scale": [0.5, 0.5]
        }
      }
    }
  }]
}

GLTF 拡張機能では、テクスチャの属性セマンティクスや MIME タイプなど、新しい属性と値を追加できます。すべての Khronos (KHR) 拡張機能と同様、ベンダー拡張機能のベスト プラクティスとして、これらの機能追加は、extensions Used 配列内の拡張機能を認識しないツールで安全なフォールバック使用を可能にすることを目的としています。

モデルで使用されるすべての拡張子は、最上位の extensions Used 配列に文字列としてリストされます。すべての必要な拡張子は、最上位の extensionsRequired 配列に文字列としてリストされます。たとえば、次のようになります。

{
  "extensionsUsed": [
    "KHR_draco_mesh_compression", "VENDOR_physics"
  ],
  "extensionsRequired": [
    "KHR_draco_mesh_compression"
  ]
}

これにより、エンジンは、すべてのオブジェクトの拡張プロパティをチェックすることなく、モデルのレンダリングに必要な拡張をサポートしているかどうかを迅速に判断できます。

一般的な glTF ローダーが拡張機能をサポートせずにリソースをロードできない場合、拡張機能が必要であるとみなされます。たとえば、アセットが非圧縮のフォールバック メッシュを提供する場合を除き、メッシュ圧縮拡張機能はオンデマンドでリストする必要があります。同様に、コア形式 (JPG、PNG) のフォールバック テクスチャも提供されていない限り、テクスチャ イメージ形式の拡張子も必要に応じてリストする必要があります。一般に、コア glTF マテリアルはそのような拡張機能の有効なフォールバックと見なすことができ、そのような拡張機能は一貫した glTF ローダーのエラーを引き起こさないため、PBR または他のタイプのマテリアル拡張機能は必須にリストされるべきではありません。

2.GLTF拡張機能の作成

新しい GLTF 拡張機能を作成するには、GLTF 拡張機能テンプレートを使用し、このリポジトリでプル リクエストを開きます。必ず拡張子を glTF 拡張子レジストリに追加してください。

拡張機能が (ルート glTF オブジェクトを拡張することによって) 新しい最上位配列を追加する場合、その要素は glTFChildOfRootProperty.schema.json のすべてのプロパティを継承する必要があります。拡張機能によって導入された他のオブジェクトは、glTFProperty.schema.json のすべてのプロパティを継承する必要があります。glTF 2.0 の規約によれば、スキーマでは追加の属性を許可する必要があります。例として、KHR_lights_punctual を参照してください。

拡張機能のサポートがないため、ジオメトリを正しく読み込むことができない場合は、拡張仕様でこれを宣言する必要があります (また、そのような拡張機能は、extensionsRequired 最上位の glTF 属性で指定する必要があります)。

3. GLTF 拡張の命名規則

注: 歴史的な理由により、古い拡張機能はこれらのガイドラインに従っていない可能性があります。将来の拡張機能ではこれが行われるはずです。

  • 名前は大文字の接頭辞で始まり、その後にアンダースコアが続く必要があります。Khronos 拡張機能には KHR、マルチベンダー拡張機能には EXT、およびベンダー拡張機能用に予約されているその他の接頭辞が付けられます。
  • 名前には、KHR_materials_unlit のように、接頭辞の後に小文字のスネーク文字を使用する必要があります。
  • 名前は次のように構成する必要があります<PREFIX>_<scope>_<feature>。ここで、スコープは既存の glTF 概念 (メッシュ、テクスチャ、イメージなど) であり、機能はそのスコープ内に追加された機能を表します。この構造は推奨されますが、必須ではありません。
  • 既存の Khronos 拡張機能 (マテリアル、ライトなど) と矛盾しない限り、スコープは単一 (メッシュ、テクスチャなど) である必要があります。

4. GLTF 拡張機能と GLTF アドオン

拡張機能に加えて、エクストラ オブジェクトを使用して glTF を拡張することもできます。これは拡張機能とは完全に別のものです。

すべての glTF オブジェクト プロパティでは、たとえば、エクストラ オブジェクトのサブプロパティに新しいプロパティを追加できます。

{
  "asset": {
    "version": 2.0,
    "extras": {
      "guid": "9abb92a3-39cf-4986-a758-c43d4bb4ab58",
    }
  }
}

これにより、完全な glTF 拡張機能を作成しなくても、glTF モデルにアプリケーション固有のプロパティを含めることができます。これは、拡張機能が広く採用されないニッチなユースケースに適している可能性があります。

5. GLTF拡張登録センター

GLTF 拡張機能を広く使用するには、GLTF 拡張機能レジストリに追加する必要があります。具体的な登録方法については、README.mdを参照してください。

5.1 glTF 2.0 承認済みの Khronos 拡張機能

Khronos 拡張機能は予約された KHR プレフィックスを使用します。Khronos Group によって承認されると、Khronos IP フレームワークによって保護されます。承認を目的とした拡張機能では、名前/コード/バージョンのスラッシングを避けるために KHR プレフィックスを使用することもあります。クロノス メンバーは承認のために延長を提出でき、その後クロノス スポンサー理事会によって投票されます。

Khronos Group は次の拡張機能を承認しました。

  • KHR_draco_mesh_compression

KHR_draco_mesh_compression 拡張機能は、glTF 形式の Draco ジオメトリ圧縮 (非正規) ライブラリを使用するためのスキーマを定義します。これにより、glTF は生データの代わりに圧縮されたジオメトリ データのストリーミングをサポートできるようになります。この拡張仕様は、Draco Bitstream バージョン 2.2 に基づいています (この仕様の内容全体は規範であり、範囲に含まれます)。

適合性セクションでは、この拡張機能に遭遇したときに実装が実行しなければならないこと、および拡張機能が基本仕様で定義されているプロパティとどのように相互作用するかを指定します。

  • KHR_ライト_時間厳守

KHR_lights_punctual 拡張機能は、glTF 2.0 で使用するライトのセットを定義します。ライトはシーン内の光源を定義します。

多くの 3D ツールとエンジンは、ライト タイプの組み込み実装をサポートしています。この拡張機能を使用すると、ツールでこれらのライトをエクスポートし、エンジンでインポートできます。

この拡張機能は、指向性、ポイント、スポットライトの 3 つの「オンタイム」ライト タイプを定義します。準光は、明確に定義された方向と強度で光を放射する、パラメーター化された無限小点として定義されます。

これらのライトはノードによって参照され、そのノードのトランスフォームを継承します。

この拡張機能の一貫した実装では、リソースに定義されたライト データをロードでき、それらのライトを使用してリソースをレンダリングできる必要があります。

  • KHR_材料_異方性

KHR_materials_anisotropy 拡張機能は、ブラシをかけられた金属を通して観察できるものなど、マテリアルの異方性プロパティを定義します。この現象を考慮するために、非対称ミラー ローブ モデルが導入されます。このローブの視覚的に際立った特徴は、鏡面反射が細長く見えることです。

  • KHR_素材_クリアコート

KHR_materials_clearcoat 拡張機能は、既存の glTF マテリアル定義の上に重ねることができるクリアコートを定義します。クリアコートは、基板に適用される保護層を表現するために物理ベースのレンダリングで一般的に使用される手法です。

  • KHR_materials_emissive_strength

コア glTF 2.0 マテリアル モデルには、マテリアルから放射される光の色と強度を制御するための emissiveFactor と emissiveTexture が含まれており、[0.0, 1.0] の範囲に制限されています。ただし、ダイナミック レンジの高い反射や照明がある PBR 環境では、より強力な発光効果が必要になる場合があります。

KHR_materials_emissive_strength 拡張機能では、各マテリアルの放射強度の上限を制御する新しい emissiveStrength スカラー係数が提供されます。

この強度は、コア マテリアルの emissiveFactor および emissiveTexture コントロールを使用してシェーディングおよび調整することができ、マテリアルの表面全体で強度を変化させることができます。emissiveStrength に 1.0 より大きい値を指定すると、反射、トーン マッピング、ブルームなどに影響を与える可能性があります。

  • KHR_materials_ior

KHR_materials_ior 拡張機能を使用すると、ユーザーは屈折率を特定の値に設定できます。

glTF の金属粗さマテリアルの誘電 BRDF は、屈折率として 1.5 の固定値を使用します。これは多くのプラスチックやガラスにはうまく機能しますが、水やアスファルト、サファイア、ダイヤモンドなどの他の素材にはうまく機能しません。

  • KHR_素材_虹色

虹色とは、見る角度や照明の角度に応じて色相が変化する効果を指します。半透明の層の薄膜は相互反射を引き起こし、薄膜の干渉により特定の波長が吸収または増幅されます。虹色に輝く色は、シャボン玉や油膜、多くの昆虫の羽などに見られます。

KHR_materials_iridescent 拡張機能を使用すると、フィルムの厚さと屈折率 (IOR) を指定して、虹色マテリアルを実装できます。

  • KHR_素材_光沢

KHR_materials_sheen 拡張機能は、既存の glTF マテリアル定義の上に重ねることができるシーンを定義します。たとえば、光沢レイヤーは、布地や布地のマテリアルを表現するために物理ベースのレンダリングで使用される一般的な手法です。

  • KHR_materials_specular

KHR_materials_specular 拡張機能は、鏡面反射光と鏡面反射光カラーという 2 つのパラメータを金属粗さマテリアルに追加します。

鏡面反射を使用すると、誘電体 BRDF の鏡面反射の強度を設定できます。値を 0 にすると、鏡面反射が無効になり、純粋に拡散したマテリアルになります。Metal BRDF はこのパラメータの影響を受けません。

specularColor は誘電体 BRDF の鏡面反射の F0 カラーを変更し、アーティストが金属粗さマテリアルの鏡面光沢マテリアル (KHR_materials_pbrSpecularGlossiness) で知られる効果を使用できるようにします。

  • KHR_素材_伝送

KHR_materials_transmission 拡張機能は、光透過性の最も単純かつ一般的な使用例、つまり屈折、散乱、分散のない無限に薄いマテリアルに対処するように設計されています。特に「薄い」マテリアル (つまり、体積ではなく表面のみが考慮されるマテリアル) を扱うと、屈折や吸収などの計算を大幅に簡略化できます。

光学的に透明なマテリアルの多くは、コア glTF 2.0 PBR マテリアルでは物理的に合理的な方法で表現できません。これは、コア仕様には「カバレッジとしてのアルファ」(baseColorFactor および BaseColorTexture のアルファ チャネルを通じて公開される) の概念のみが含まれているためです。ガラスやプラスチックなどの一般的なマテリアルの多くは、大幅に異なるレンダリング技術を必要とします。

  • KHR_マテリアル_消灯

KHR_materials_unlit 拡張機能は、コア仕様によって提供される物理ベース レンダリング (PBR) シェーディング モデルの代替として、glTF 2.0 マテリアルの unlit シェーディング モデルを定義します。非発光材料の動機となる 3 つの使用例は次のとおりです。

  1. リソースに制約のあるモバイル デバイスでは、非発光マテリアルが高品質のシェーディング モデルに代わる高性能の代替手段となります。
  2. 写真測量。照明情報がすでに存在しており、追加の照明を適用する必要はありません。
  3. 美的理由から照明を必要としない様式化されたマテリアル (「アニメ」または「手描き」の外観など)。

これらの使用例は相互に排他的ではありません。アーティストはパフォーマンス上の理由から非照明素材を選択し、その選択を補うために美的決定を下す場合があります。したがって、PBR をレンダリングできるクライアント実装は、完全にシェーディングされた PBR に自動的に「アップグレード」すべきではありません。unlit マテリアルで指定されたコア PBR プロパティ (baseColor を除く) は、KHR_materials_unlit 拡張機能をサポートしないクライアントのフォールバックとしてのみ使用されます。拡張子は、アセット内で必須であるかオプションであるかに関係なく、非点灯の視覚スタイルの設定を示します。

  • KHR_materials_variants

KHR_materials_variants 拡張機能を使用すると、実行時の低遅延切り替えを可能にする構造を備えた、アセットの複数のマテリアル バリアントのコンパクトな glTF 表現が可能になります。

典型的な使用例はデジタル商取引で、たとえば、スニーカーと異なる色を切り替える機能がユーザーに提示されます。

  • KHR_材料_体積

デフォルトでは、glTF 2.0 マテリアルは、無限に薄いボリュームを囲む表面の散乱特性を記述します。メッシュで定義されたサーフェスは薄壁を表します。

KHR_materials_volume 拡張機能を使用すると、サーフェスをボリューム間のインターフェイスに変換できます。マテリアルが取り付けられるメッシュは均質な媒体の境界を定義するため、多様である必要があります。ボリュームは、屈折、吸収、散乱などの効果を提供します。散乱はこの拡張機能の対象ではありません。

  • KHR_メッシュ量子化

頂点属性は通常、FLOAT コンポーネント タイプを使用して保存されます。ただし、これにより、精度が過剰になり、メモリ消費量と転送サイズが増加し、レンダリング パフォーマンスが低下する可能性があります。

KHR_mesh_quantization 拡張機能は、メッシュ属性ストレージによって許可されるコンポーネント タイプのセットを拡張して、メモリと精度のトレードオフを提供します。アプリケーションのニーズに応じて、16 ビットまたは 8 ビットのストレージで十分な場合があります。

16 ビットまたは 8 ビットのストレージを使用するには、多くの場合、生の浮動小数点値を均一な 3D または 2D グリッドに適合するように変換する必要があり、このプロセスは量子化と呼ばれることがよくあります。

実装要件を簡素化するために、この拡張機能はパターンに特殊な逆量子化変換を追加するのではなく、幾何学的変換を指定する既存の方法に依存しています。

たとえば、静的 PBR 対応メッシュは通常、頂点ごとに POSITION (12 バイト)、TEXCOORD (8 バイト)、NORMAL (12 バイト)、および TANGENT (16 バイト) の合計 48 バイトを必要とします。この拡張機能を使用すると、SHORT を使用して位置とテクスチャの座標データ (それぞれ 8 バイトと 4 バイト) を保存し、BYTE を使用して法線データと接線データ (それぞれ 4 バイト) を保存できます (頂点ごとに合計 20 バイト)。これは通常は機能します。品質への影響。

拡張子にはデータの FLOAT および量子化バージョンを指定する方法が提供されていないため、拡張子を使用するファイルは拡張子を extensionsRequired 配列で指定する必要があります。拡張子はオプションではありません。

  • KHR_texture_basis

KHR_texture_basisu 拡張機能は、Basis Universal 超圧縮を備えた KTX v2 イメージを使用してテクスチャを指定する機能を追加します。この拡張機能の実装では、glTF 2.0 で利用可能な PNG または JPEG 画像の代わりにこのような画像を使用して、リソース転送効率を高め、GPU メモリの占有面積を削減できます。さらに、ミップマップレベルを指定することもできます。

この拡張機能を使用する場合、KHR_texture_basisu テクスチャ拡張オブジェクトの source 属性によって参照される画像の mimeType 属性として、値 image/ktx2 を使用することができます。

実行時に、エンジンはユニバーサル テクスチャ フォーマットを、プラットフォームでサポートされているブロック圧縮テクスチャ フォーマットの 1 つにトランスコードする必要があります。BasisViewer を使用すると、オンラインで Basis 形式のテクスチャを表示できます。

  • KHR_texture_transform

3D シーンのリソース使用量を最適化するために、多くのテクニックを使用できます。その主な機能は、GPU がロードする必要があるテクスチャの数を最小限に抑える機能です。これを実現するために、多くのエンジンは、多くのオブジェクトの低解像度テクスチャを 1 つの大きなテクスチャ アトラスにパッキングすることを推奨しています。各オブジェクトに対応する生成されたアトラスの領域は、領域の垂直方向と水平方向のオフセットと幅と高さによって定義されます。

この使用例をサポートするために、KHR_texture_transform 拡張機能は、オフセット、回転、およびスケールのプロパティを textureInfo 構造に追加します。これらのプロパティは通常、UV 座標のアフィン変換として実装されます。GLSL の場合:

varying in vec2 Uv;

uniform vec2 Offset, Scale;
uniform float Rotation;

mat3 translation = mat3(1,0,0, 0,1,0, Offset.x, Offset.y, 1);
mat3 rotation = mat3(
    cos(Rotation), sin(Rotation), 0,
   -sin(Rotation), cos(Rotation), 0,
                0,             0, 1
);
mat3 scale = mat3(Scale.x,0,0, 0,Scale.y,0, 0,0,1);

mat3 matrix = translation * rotation * scale;
vec2 uvTransformed = ( matrix * vec3(Uv.xy, 1) ).xy;

これは、Unity の Material#SetTextureOffset および Materials#SetTextureScale、または Three.js の Texture#offset および Texture#repeat に相当します。現時点では、UV 回転は広くサポートされていませんが、上位互換性のためにここに含まれています。

  • KHR_xmp_json_ld

KHR_xmp_json_ld 拡張機能は、XMP (Extensible Metadata Platform) (ISO 16684-1) メタデータのサポートを glTF に追加します。メタデータは、glTF 資産に関する情報 (所有権、ライセンス、作成日など) を転送するために使用されます。メタデータは、glTF リソースの外観とレンダリングに正規の影響を与えません。

XMP はドキュメントにメタデータを埋め込むためのテクノロジーで、2012 年から ISO 標準となっています。XMP データ モデルの例は、XMP パケット (ISO 16684-1$6.1) と呼ばれます。XMP メタデータは、メタデータ パッケージの配列としてトップレベルの glTF 拡張機能に埋め込まれます。XMP メタデータ パッケージは、アセット、シーン、ノード、メッシュ、マテリアル、イメージ、アニメーションなどのタイプの glTF オブジェクトから参照できます。glTF のトップレベル オブジェクト アセットによって参照される XMP メタデータは、glTF アセット全体に適用されます。

XMP メタデータは名前空間ごとに編成されます (ISO 16684-1$6.2)。この拡張機能を使用すると、任意の XMP メタデータ名前空間を glTF アセットに埋め込むことができます。glTF の XMP メタデータ パケットは、JSON-LD の制限された機能セットを使用します。これにより、JSON パーサーと JSON-LD パーサーが個々のパケットを読み取ることができるようになります。

JSON-LD を使用した XMP メタデータのシリアル化については、「XMP の JSON-LD シリアル化 (ISO 16684-3)」で説明されています。JSON-LD 仕様では、JSON-LD 1.1 の詳細な使用法の概要が説明されています。glTF のその他の制限については、「JSON-LD の制限と推奨事項」で概説されています。

  • EXT_mesh_gpu_intancing

EXT_mesh_gpu_instancing 拡張機能は、GPU インスタンス化が少数の描画呼び出しを使用して 1 つのメッシュの複数のコピーを一度にレンダリングできるようにするために特別に設計されています。木、草、道路標識などに最適です。移動、回転、およびスケールのプロパティを使用すると、メッシュをさまざまな回転とスケールでさまざまな位置に表示できます。頂点属性と同様に、カスタム インスタンス属性にはアンダースコア (_ID、_COLOR など) を接頭辞として付けて、アプリケーション固有の効果に使用できます。

この拡張機能は GPU インスタンス用に最適化されたメッシュ データを保存しますが、(1) この拡張機能がなくても GPU インスタンスとその他の最適化は可能であり推奨されること、(2) 「インスタンス化」という用語には、これとは異なる他の一般的な意味が存在することに注意することが重要です。この拡張子。

  • EXT_meshopt_compression

glTF ファイルには、頂点属性データ、インデックス データ、モーフ ターゲット デルタ、アニメーション入出力などのさまざまなバイナリ データが付属しており、全体の転送サイズの大部分を占める可能性があります。配信サイズを最適化するために、gzip などの汎用圧縮を使用できますが、通常、glTF バイナリ データのいくつかの一般的なタイプの冗長性はキャプチャされません。

EXT_meshopt_compression 拡張機能は、glTF バッファー内の一般的なデータ型用にカスタマイズされた、バイナリ データを圧縮するための一般的なオプションを提供します。この拡張機能は、bufferView レベルで動作するため、データの使用方法には依存せず、ジ​​オメトリ (モーフ ターゲットを含む頂点およびインデックス データ)、アニメーション (キーフレーム時間と値)、および EXT_mesh_gpu_instancing のインスタンス変換などのその他のデータをサポートします。

超圧縮テクスチャ (KHR_texture_basisu を参照) と同様に、この拡張機能は、バッファー ビュー データが GPU 効率に合わせて最適化されている (量子化を使用し、GPU レンダリングに最適なデータ順序を使用している) ことを前提としており、bufferView データの上に圧縮レイヤーを提供します。各bufferView は個別に圧縮されるため、ローダーは最も効率的にデータを GPU ストレージに直接解凍できます。

圧縮率の最適化に加えて、圧縮形式には 2 つの特性もあります。1 つは非常に高速なデコード (WebAssembly SIMD を使用し、デコーダは最新のデスクトップ ハードウェアで約 1 GB/秒で動作します)、もう 1 つはユニバーサル ストレージを使用したバイト互換の圧縮です。つまり、エンコード サイズを最小限に抑える代わりに、汎用の圧縮器でさらに圧縮できるようにビットストリームが構築されます。

これは、すべてのファイルが gzip を使用して圧縮される典型的な Web 配信シナリオにとって有益です。ここでのコーデックは完全に置き換えるわけではありませんが、サイズを削減しながら強化します (これは、gzip 圧縮が利用できない場合の最適化に役立ち、配信サイズが重要です)。また、gzip 解凍によるパフォーマンスへの影響も軽減されます。gzip 解凍は、通常、ここで提案されているデコーダよりもはるかに低速です)。

  • EXT_texture_webp

EXT_texture_webp 拡張機能を使用すると、glTF モデルで WebP を有効な画像形式として使用できるようになります。この拡張機能を実装していないクライアントは、提供された WebP 画像を無視し、基本仕様で利用可能な PNG および JPG テクスチャに依存し続けることができます。フォールバック テクスチャの定義はオプションです。「ベスト プラクティス」セクションでは、この拡張機能の意図された使用例と、バッキング テクスチャなしで使用した場合に予想される動作について説明します。

WebP は、Google によって開発および保守されている画像形式で、Web 上の画像に優れた可逆圧縮および非可逆圧縮を提供します。通常、PNG よりもサイズが 26% 小さく、同等の JPEG 画像よりも 25 ~ 34% 小さくなります (出典)。

5.2 glTF 2.0 のマルチベンダー拡張機能

拡張機能が複数のベンダーによって実装されている場合、その拡張機能の名前には予約済みの EXT プレフィックスを使用できます。Khronos IP フレームワークは通常、マルチベンダー拡張機能をカバーしていませんが、EXT プレフィックスで広く使用された後に Khronos 承認プロセスを経たいくつかの注目すべき例外 (上記にリスト) があります。

  • EXT_lights_ies

EXT_lights_ies 拡張機能を使用すると、IES ライト プロファイルをシーン内の光源として使用できるようになります。IES 光プロファイリングは、光源からの実際の測定データを使用して光の分布を記述します。

多くの 3D ツールとエンジンは、IES 照明プロファイルをサポートしています。この拡張機能を使用すると、IES ライト プロファイルで記述されたライトを含むシーンをツールでエクスポートしたり、エンジンでインポートしたりできます。

ライト設定はノードによって参照され、そのノードの変換を継承します。これらは、シーン内の点光源を記述します。これらの光源は、角度的に変化する強度で全方向に光を放射するパラメータ化された無限小点として定義されます。

この拡張機能を一貫して実装するには、アセットで定義されたライト プロファイルをロードし、それらのライトを使用してアセットをレンダリングできる必要があります。次の IES 光構成標準をサポートする必要があります: IES LM-63-95、ANSI/IESNA LM-63-02、および ANSI/IES LM-63-19。実装では、タイプ B およびタイプ C 測光の光プロファイルをサポートする必要があります。タイプ A 測光のライト プロファイルのサポートはオプションです。必須フィールドのリストと、上記の標準バージョン間の関連する相違点の説明については、実装の詳細を参照してください。

  • EXT_lights_image_based

EXT_lights_image_based 拡張機能は、glTF シーンでイメージベースのライトを定義する機能を提供します。イメージベースのライティングは、シーンの鏡面輝度と放射照度情報を表す環境マップで構成されます。

多くの 3D ツールとエンジンは画像ベースのグローバル イルミネーションをサポートしていますが、使用される具体的な技術とデータ形式は異なります。この拡張機能を使用すると、ツールはイメージベースのライトをエクスポートし、エンジンはインポートできるため、結果の一貫性が高くなります。

この拡張機能は、使用する環境マップをフォーマットおよび参照する方法を正確に指定します。これを行う目的は 2 つあります。まず、この拡張機能のサポートを実装しやすくなります。2 番目に、イメージベースのライティングのレンダリングが実行時に一貫した状態を維持できるようにします。

この拡張機能を一貫して実装するには、画像ベースの環境データをロードし、このライティングを使用して PBR マテリアルをレンダリングできる必要があります。

5.3 glTF 2.0 のベンダー拡張

ベンダー プレフィックスのリストは Prefixes.md で管理されます。(Khronos メンバーだけでなく) すべてのベンダーは、GitHub に問題を送信することで拡張プレフィックスをリクエストできます。リクエストには以下を含める必要があります。

  • プレフィックスの名前。
  • プレフィックスを要求しているサプライヤーの名前。
  • サプライヤーの URL および/または連絡先情報。

Khronos IP フレームワークはベンダー拡張機能をカバーしていません。

  • ADOBE_materials_clearcoat_specular

ADOBE_materials_clearcoat_specular 拡張機能は、KHR_materials_clearcoat 拡張機能によって提供されるクリアコートの屈折率 (IOR) と鏡面反射光 F0 を制御するメソッドを定義します。これはクリアコートのデフォルト IOR (1.5) をオーバーライドし、F0 反射率を調整する方法も提供します。これは、KHR_materials_ior 拡張機能と KHR_materials_specular 拡張機能が連携して F0 反射率を変更するのとまったく同じ方法です。

  • ADOBE_materials_thin_transparency

光学的に透明なマテリアルの多くは、コア glTF 2.0 PBR マテリアルでは物理的に合理的な方法で表現できません。アルファ オーバーレイ (baseColorTexture のアルファ チャネルを通じて公開される) は、光を反射、屈折、吸収、または散乱しない透明なマテリアル (ガーゼなど) に役立ちます。ただし、ほとんどの物理マテリアルはこのカテゴリに分類されません。透明なガラスやプラスチックが良い例です。最も単純なケースでは、ガラス表面からの鏡面反射が完全に透明なメッシュ上に表示されます。0% アルファ カバレッジを使用すると、反射も見えなくなります。

ADOBE_materials_thin_transparency 拡張機能は、光学的透明性の最も単純かつ最も一般的なユースケース、つまり複雑な散乱 (動的散乱など) や分散のない薄いマテリアルに対処するように設計されています。特に「薄い」マテリアル (つまり、体積ではなく表面のみが考慮されるマテリアル) を扱うと、屈折や吸収などの計算を大幅に簡略化できます。

  • AGI_ジョイント

AGI_articulations 拡張機能は、モデル上のすべての可動ノードの名前と自由度の範囲を定義します。

glTF 2.0 のコア アニメーション システムは、典型的なグラフィックス業界の使用パターンをターゲットにしており、モデルの作成者がオーサリング時にモデルのどの部分が移動するか、およびそれらの移動の正確な性質とタイミングを決定します。モデルの一部が作成者によって可動として指定されているが、その正確な動きがモデルが構築されるまで分からない場合は許可されません。

たとえば、電動スタンド上のラジオ受信アンテナの場合を考えてみましょう。モデルを構築するとき、モデルの作成者は、皿が特定の方向を指す可能性があることを知っているかもしれませんが、特定の時点で皿がどこを指しているのかは (皿が実際に使用されるまで) わからない場合があります。この料理の glTF モデルは、利用可能な動作の名前と制限を示す必要がありますが、モデルには実行される実際の一連の動作が含まれていないため、実行時または料理の実行のリアルタイム シミュレーションが行われるまで分からない可能性があります。 。

この場合、モデルは多関節であると言い、モデル上のすべての可動ノードの名前と許容される動きの範囲 (自由度) を定義するために多関節が必要です。ノードにジョイントを適用しても、必要に応じて glTF コア アニメーションを同じノードに適用できます。実装は、利用可能なジョイントをいつどのように適用するかを自由に選択でき、この情報は glTF ファイルの外部にあることが期待されます (そうでない場合は、単にアニメーションとしてエンコードできます)。

  • AGI_stk_metadata

AGI_stk_metadata 拡張機能は、追加のメタデータを glTF モデルに追加します。このメタデータは、Analytical Graphics, Inc. が製造する製品 STK (システム ツール キット) の既存の機能と 1 対 1 で一致することを目的としています。

  • CESIUM_primitive_outline

テクスチャーのない建物など、フォトリアリスティックではない 3D オブジェクトは、多くの場合、エッジの輪郭が描かれていると視覚的に魅力的になります。glTF モデルに等高線を追加する簡単な方法は、LINES タイプのプリミティブをモデルに追加し、等高線を描くエッジに沿って線を描画することです。残念ながら、線の深さが三角形と競合するため、このアプローチの視覚的な品質は非常に劣ります。線のラスタライズが三角形のエッジのラスタライズと一致しません。

別々にレンダリングされた線と三角形の間の深さの競合

このような深刻な競合を回避する従来の方法は、glPolygonOffset または同様のメソッドを使用することです。ただし、glTF 2.0 はポリゴン オフセットの指定をサポートしていません。たとえそれができたとしても、またはそれをサポートする拡張機能が定義されていたとしても、このアプローチを使用して高品質のレンダリングを取得することは困難です。選択したポリゴン オフセット値によっては、深度偏差が大きすぎるために背面の線が前面に「にじみ出る」場合や、深度偏差が小さすぎるために線が点状に見える場合があります。ポリゴン オフセット値を注意深く調整しても、多くの場合、単一のシーンで両方の問題を検出できます。

これらのアーティファクトは許容できると考えられる場合でも、個々のライン プリミティブをレンダリングすると、シーンのレンダリングに必要な描画呼び出しの数が増加します。さらに、一部のハードウェアでは、線の描画は三角形の描画よりもはるかに遅くなります。

CESIUM_primitive_outline 拡張機能は、輪郭を描く必要がある三角形の辺のリストをレンダリング エンジンに示します。レンダリングをどのように行うべきかについては規定しませんが、すべての線が実際には三角形のエッジであるという事実により、レンダリング エンジンは、実行時にそのような技術の適用可能性を推測することなく、より高品質で高速な技術を使用して線をレンダリングできます。

  • FB_geometry_metadata

FB_geometry_metadata 拡張機能は、シーンに関連するシーン グラフの累積的な幾何学的複雑さとシーン空間の範囲の概要を glTF シーン オブジェクトに注釈を付けます。再帰的に参照される各メッシュが列挙されて頂点とプリミティブの合計数が取得され、個々の頂点がシーン空間に変換されて、完全に計算されたバウンディング ボックスが取得されます。

この情報の実証済みの実際的な応用例は次のとおりです。

  1. 視聴者がどのシーンを表示するかについて、迅速かつ大まかな決定を下す必要がある場合。これは、たとえば、モデルのさまざまなバリエーション (LoD レベルなど) を表すためにシーンが使用される場合に、おそらく最も意味があります。
  2. サーバー側システムが幾何学的複雑さに基づいて決定を下す必要があり、独自の複雑な行列/ベクトル コードを含めたくない場合。
  • MPEG_accessor_timed

glTF のアクセサは、bufferView を通じて表示されるバッファに格納されているデータのタイプとレイアウトを定義します。バッファからタイミング データを読み取る場合、バッファ内のデータは時間の経過とともに動的に変化する可能性があります。

タイムメディアやメタデータを含むシーンでは、MPEG_accessor_timed タイムアクセサー拡張機能を利用して、動的に変化するデータへのアクセスを記述する必要があります。MPEG_accessor_timed は、基礎となるデータ バッファーが動的であることを示す通常のアクセサーの拡張機能です。timed アクセサーには 2 つのbufferView があり、1 つは包含アクセサーから継承され、もう 1 つは MPEG_accessor_timed 拡張内にあることに注意してください。前者は、時間指定されたメディア データを参照するために使用されます。後者は、存在する場合も存在しない場合もある動的バッファ ヘッダーを指すために使用できます。存在する場合、両方のbufferViewは同じ循環バッファを指す必要があります。

MPEG_accessor_timed 拡張子を持つアクセサーの accessor.bufferView フィールドと、timed アクセサー情報ヘッダー フィールドは、循環バッファー内のデータの各フレームに適用されます。

時限アクセサー拡張は、MPEG_accessor_timed によって識別されます。

  • MPEG_animation_timing

MPEG_animation_timing 拡張機能は、メディア タイムラインと glTF 2.0 で定義されたアニメーション タイムラインの間の位置合わせをサポートします。拡張機能を使用して、伝えるストーリーを作成します。アニメーション タイミング メタデータにより、glTF 2.0 で定義されたアニメーションとメディアの一時停止やその他の操作を同時に行うことができます。

  • MPEG_audio_spatial

MPEG_audio_spatial 拡張機能は、空間オーディオのサポートを追加します。空間オーディオは、シーン内の任意のノードの上に含めたり、接続したりできます。

  • MPEG_buffer_circular

時間指定されたデータ アクセスをサポートするために、バッファー要素が拡張され、循環バッファーの機能が提供されます。MPEG_buffer_circular 拡張子はバッファの一部として含めることができます。タイミング データへのアクセスを提供するバッファには、MPEG_buffer_circular 拡張子を含める必要があります。

  • MPEG_メディア

MPEG_media は、glTF ドキュメント内の他の拡張子によって参照される MPEG メディア アイテムの配列を提供します。

  • MPEG_mesh_linking

MPEG_mesh_linking 拡張機能は、glTF リソース内の 1 つのメッシュを別のメッシュにリンクする可能性を提供します。

シェーディングされたメッシュは、MPEG_mesh_linking 拡張子のない、glTF 2.0 によって定義された通常のメッシュ データに対応します。依存メッシュはシャドウ メッシュに依存して変形/アニメーション化できます。スレーブ メッシュに含まれる MPEG_mesh_linking 拡張機能は、スレーブ メッシュとシャドウ メッシュをリンクし、スレーブ メッシュをアニメーション化する機能を実装するために使用されるデータと情報を提供します。したがって、スレーブ メッシュに変換を適用する機能を容易にするために、シャドウ メッシュが glTF リソースに存在します。

  • MPEG_シーン_ダイナミック

MPEG_scene_dynamic 拡張リンク。

  • MPEG_texture_video

MPEG_texture_video 拡張機能は、glTF 2.0 で定義されたテクスチャ オブジェクトをメディアおよびそれに対応するトラック (MPEG_media でリストされる) にリンクする可能性を提供します。MPEG_texture_video 拡張子は、時限アクセサー、つまり MPEG_accessor_timed 拡張子を持つアクセサーへの参照も提供し、デコードされた時限テクスチャーが利用可能になります。

MPEG_texture_video 拡張子がサポートされていない場合、テクスチャ バッファには標準の glTF ソース オブジェクトで記述されたデータを入れる必要があります。

  • MPEG_ビューポート_推奨

MPEG_viewport_recommished 拡張機能は、推奨ビューポート情報のサンプルが利用可能な時限アクセサーを参照することにより、glTF 2.0 で定義されたカメラ オブジェクトから推奨ビューポート情報へのリンクを提供します。

推奨されるビューポート情報は、カメラ オブジェクトを含むノードの移動や回転、カメラ オブジェクトの固有のカメラ パラメータなど、動的に変化する情報を提供します。クライアントは、動的に変化する情報に基づいてビューポートをレンダリングします。

注: 推奨ビューポートを実装するもう 1 つの方法は、カメラが接続されたノードのアニメーションを定義することです。ただし、このメソッドは内部カメラの動的変更をサポートしていないため、glTF オブジェクトの作成時に定義する必要があります。

  • MSFT_lod

MSFT_lod 拡張機能は、glTF リソースのさまざまな詳細レベル (LOD) を指定する機能を追加します。この拡張機能の実装では、オブジェクトの距離に基づいてさまざまな LOD をレンダリングしたり、最も低い LOD から開始して glTF リソースを段階的に読み込んだりするなど、さまざまなシナリオで LOD を使用できます。

この拡張機能により、LOD をジオメトリ ノードまたはマテリアル レベルで定義できるようになります。ノード LOD は異なるレベルにわたって異なるジオメトリとマテリアルを指定できますが、マテリアル LOD は同じジオメトリに対して異なるマテリアルを指定できます。

MSFT_lod 拡張子は、最高の LOD レベルに追加されます。この拡張機能は、下位 LOD レベルのインデックスを含む配列である ids 属性を定義します。配列内の各値は、前のレベルよりも品質が低い LOD レベルを指します。たとえば、拡張機能がノード レベルで定義されている場合、拡張機能を持つノード オブジェクトが最高の LOD レベルになります。展開された ids 配列で指定された各値は、下位 LOD レベルとして使用される別のノード オブジェクトへのインデックスを指します。

この拡張機能の実装では、ids 配列を解析して、アセットに使用できる LOD レベルのリストを作成できます。この拡張機能を含むリソースが、拡張機能を実装していないクライアントにロードされる場合、最高の LOD レベルがロードされ、それより低い LOD はすべて無視されます。

  • MSFT_packing_normal粗さメタリック

MSFT_packing_normalRoughnessMetallic 拡張機能は、代替テクスチャ パッキングのサポートを追加し、Windows Mixed Reality ホームおよび Windows Mixed Reality の 3D ランチャーで使用することを目的としています。

この拡張機能は、normalRoughnessMetallicTexture の追加プロパティを定義します。このプロパティは、ラップ法線 (RG)、粗さ (B)、メタリック (A) を含むテクスチャのインデックスを指定します。この特殊なラッパーは、コア glTF 2.0 仕様で指定されているラッパーの最適化された代替手段を提供することを目的としています。

この拡張機能は、このパッケージ化をサポートするエンジン用の glTF アセットを作成する場合にのみ使用する必要があり、汎用のパッケージ化拡張機能ではありません。この拡張機能をサポートしていないクライアントは、これらの追加のパックされたテクスチャを安全に無視し、glTF 2.0 のデフォルトのパッキングに依存できます。この拡張機能を MSFT_texture_dds などの他の拡張機能とともに使用して、パックされたテクスチャを DDS ファイルに保存することもできます。

  • MSFT_packing_occlusion粗さメタリック

MSFT_packing_occlusionRoughnessMetallic 拡張機能は、代替テクスチャ パッキングのサポートを追加し、Windows Mixed Reality ホームおよび Windows Mixed Reality の 3D ランチャーで使用することを目的としています。

この拡張機能は、次の 3 つの追加プロパティを定義します。

  1. occlusionRoughnessMetallicTexture: パックドオクルージョン®、Roughness(G)、Metallic(B)のテクスチャを指定するインデックス
  2. roughnessMetallicOcclusionTexture: パックされたラフネス®、メタリック(G)、オクルージョン(B)のテクスチャを指定するインデックス
  3. NormalTexture: 2 チャネル (RG) 法線マップを含むテクスチャのインデックスを指定します。

この拡張機能は、このパッケージ化をサポートするエンジン用の glTF リソースを作成する場合にのみ使用する必要があり、汎用のパッケージ化拡張機能ではありません。この拡張機能をサポートしていないクライアントは、これらの追加のパックされたテクスチャを安全に無視し、glTF 2.0 のデフォルトのパッキングに依存できます。この拡張機能を MSFT_texture_dds などの他の拡張機能とともに使用して、パックされたテクスチャを DDS ファイルに保存することもできます。

  • MSFT_texture_dds

MSFT_texture_dds 拡張機能は、DirectDraw Surface ファイル形式 (DDS) を使用してテクスチャを指定する機能を追加します。この拡張機能の実装では、glTF 2.0 で使用可能な PNG または JPG テクスチャの代わりに、DDS ファイルで提供されるテクスチャを使用できます。

この拡張子はテクスチャ ノードに追加され、イメージ ノード インデックスを指すソース アトリビュートを指定します。このインデックスは、DDS テクスチャ ファイルを指します。この拡張子を理解できないクライアントは、DDS ファイルを無視して、指定された PNG または JPG テクスチャに依存し続けることができます。

  • NV_マテリアル_mdl

NV_materials_mdl 拡張機能は、MDL 言語仕様で定義されているように、NVIDIA マテリアル定義言語 (MDL) で定義されている glTF リソースにマテリアルを保存および転送する機能を提供します。この拡張機能の目的は、標準の glTF 2.0 PBR モデルに加えて、MDL 対応アプリケーションおよびレンダラーに glTF で高品質のマテリアル定義を提供することです。

MDL マテリアルは MDL モジュールで定義され、.mdl ファイル拡張子の付いたファイルに保存されます。.mdl ファイルへの参照は、特に MDL 言語仕様の付録 F に記載されている検索パスを使用して、準拠する実装の構成コンテキスト内で解決されます。代わりに、MDL モジュールをアセットに埋め込むこともできます。MDL マテリアルは、テクスチャやその他のリソースを入力パラメータとして受け入れることができます。この拡張機能は、コア glTF 2.0 標準の画像に JPG および PNG テクスチャを使用します。さらに、この拡張機能を使用すると、イメージ オブジェクトはそれぞれ image/x-exr および application/x-vdb メディア タイプを使用して EXR および VDB リソースを参照できます。EXT_lights_ies 拡張は IES ライト プロファイル用であり、MDL 言語仕様の付録 B で定義されている MBSDF 等方性測定 BSDF データはこの拡張の一部です。

この拡張機能の適合実装は、参照された MDL モジュールをロードし、参照された関数呼び出しとユーザー定義タイプにそれらの MDL モジュール内で互換性のある定義があることを確認し、参照されたマテリアル バインディングでこれらの関数を使用してそれに応じてメッシュをレンダリングできる必要があります。この材料は標準の glTF PBR 材料を置き換えます。関数呼び出しは、型パラメーターを使用した呼び出しで一致する関数定義 (MDL 言語仕様のセクション 12.4 で定義されているオーバーロード解決を含む) が見つかったかどうかをチェックすることによって、MDL モジュールに対して検証されます。対応する型のすべてのフィールドまたは列挙値が MDL モジュールに存在するかどうかを確認することにより、MDL モジュールに対してユーザー定義型を検証します。

MDL マテリアルは標準の glTF マテリアルを置き換えるため、オーサリング アプリケーションが MDL マテリアルと並行して厳密に一致する標準の glTF PBR マテリアルも提供することを強くお勧めします。これにより、この拡張機能を理解できない実装でもこの glTF ファイルの代表的なレンダリングを表示できます。 。ただし、フォールバック マテリアルの定義はオプションです。この問題については、「ベスト プラクティス」セクションで詳しく説明します。

MDL マテリアルは、組み込みタイプのマテリアルを返す言語の関数を通じて定義されます。この拡張機能は、参照される MDL モジュールで定義された関数への関数呼び出しに対して動作します。これらの関数呼び出しは、最上位の NV_materials_mdl 拡張オブジェクトで定義される functionCalls 配列属性で定義されます。関数呼び出しと型参照のモジュールは modules 配列で定義されます。最後に、BSDF 測定リソースが bsdfMeasurements 配列で定義されます。

5.4 glTF 2.0 のアーカイブ拡張機能

アーカイブされた拡張子は、古い glTF ファイルを読み取る場合には便利ですが、新しいファイルの作成に使用することは推奨されなくなりました。

  • KHR_materials_pbr鏡面光沢度

KHR_materials_pbrSpecularGlossiness 拡張機能は、物理ベース レンダリング (PBR) の鏡面光沢マテリアル モデルを定義します。この拡張機能により、glTF はこの追加のワークフローをサポートできるようになります。

  • KHR_techniques_webgl

KHR_techniques_webgl 拡張機能を使用すると、glTF は外部シェーダ プログラムとそのパラメータ化された値を使用してシェーディング テクニックのインスタンスを定義できます。シェーディング テクノロジは、JSON 属性を使用して、GLSL 頂点およびフラグメント シェーダ プログラムのデータ型とセマンティクスを記述します。

この拡張仕様は WebGL 1.0 をターゲットにしており、デバイスが必要な WebGL 拡張をサポートしている場合は、任意の WebGL 1.0 ベースのエンジンでサポートできます。

  • KHR_xmp

KHR_xmp 拡張機能は、XMP (Extensible Metadata Platform) (ISO 16684-1) メタデータのサポートを glTF に追加します。メタデータは、glTF 資産に関する情報 (所有権、ライセンス、作成日など) を転送するために使用されます。メタデータは、glTF リソースの外観とレンダリングに正規の影響を与えません。

XMP はドキュメントにメタデータを埋め込むためのテクノロジーで、2012 年から ISO 標準となっています。XMP データ モデルの例は、XMP パケット (ISO 16684-1$6.1) と呼ばれます。XMP メタデータは、メタデータ パッケージの配列としてトップレベルの glTF 拡張機能に埋め込まれます。XMP メタデータ パッケージは、アセット、シーン、ノード、メッシュ、マテリアル、イメージ、アニメーションなどのタイプの glTF オブジェクトから参照できます。glTF のトップレベル オブジェクト アセットによって参照される XMP メタデータは、glTF アセット全体に適用されます。XMP メタデータは名前空間ごとに編成されます (ISO 16684-1$6.2)。

この拡張機能を使用すると、任意の XMP メタデータ名前空間を glTF アセットに埋め込むことができます。

5.5 進行中の Khronos と glTF 2.0 へのマルチベンダー拡張機能

クロノス (KHR) 延長草案はまだ承認されていません。マルチベンダー (EXT) 拡張機能には承認は必要ありませんが、完了前に変更される可能性があります。

このセクションでは、すでに開発中であるか、または将来の開発で使用される可能性が高い十分な合意が得られていると思われる、Khronos およびマルチベンダー拡張機能のステータスを追跡します。これらおよび他のすべての拡張機能に関するフィードバックを歓迎します (GitHub の問題を参照)。このリストは、現在の優先事項と方向性の概要を提供することを目的としています。

ここにリストされていないが、さまざまな用途にとって重要である可能性のある機能については、コミュニティがベンダー拡張機能 (レビューは必要ありません) から開始し、フィードバックや協力者を求めることを奨励します。また、合意の形として、ベンダー間の拡張機能により、マルチベンダー拡張機能、Khronos 拡張機能、または glTF 仕様の将来のバージョンへの組み込みを通じて、より広範なエコシステムが導入されます。

拡大する
KHR_animation_pointer テストの準備をする
KHR_オーディオ テストの準備をする
KHR_materials_diffuse_transmission テストの準備をする
KHR_素材_sss 開発中

元のリンク: GLTF 拡張機能の決定版ガイド—BimAnt

おすすめ

転載: blog.csdn.net/shebao3333/article/details/132824925