技術概要

仕組み

Needle Engine は、おおよそ 3 つの要素で構成されています。

  • たとえば Unity Editor から Needle Engine 用のシーンを設定できる、多くのコンポーネントとツール

  • シーンおよびコンポーネントのデータを glTF に変換するエクスポーター

  • 生成された glTF ファイルとその拡張機能を読み込み、実行するウェブ ランタイム

ウェブ ランタイムはレンダリングに three.js を使用し、three シーン グラフの上にコンポーネント システムを追加し、カスタム glTF 拡張機能の拡張ローダーを接続します。

これにより、実質的に Unity や Blender のようなツールが空間ウェブ開発の強力なツールに変わります。glTF アセットが一般的な HTML、CSS、JavaScript、およびバンドル ワークフローに追加されます。

glTF アセット

モデル、テクスチャ、アニメーション、ライト、カメラなどは、Needle Engine では glTF 2.0 ファイルとして保存されます。 カスタム データは ベンダー固有の glTF 拡張機能に保存されます。これらは、インタラクティブなコンポーネントから物理、シーケンス、ライトマップまで、すべてをカバーします。

サポートされる glTF 拡張機能

Needle Engine によって作成される一般的なプロダクション glTF は、以下の拡張機能を使用します。

KHR_lights_punctual
KHR_materials_unlit
KHR_texture_transform
KHR_animation_pointer
NEEDLE_techniques_webgl
NEEDLE_gameobject_data
NEEDLE_components
NEEDLE_persistent_assets
NEEDLE_lightmaps
NEEDLE_lighting_settings
KHR_texture_basisu
KHR_draco_mesh_compression

その他のサポートされる拡張機能:

サポートされるマテリアル拡張機能:

UnityGLTF のエクスポート コールバック (未文書化) および three.js の glTF インポート拡張機能を使用して、さらに多くの拡張機能やカスタム拡張機能を追加できます。

: これらの拡張機能を使用するマテリアルは、UnityGLTF の PBRGraph マテリアルを介して Unity からエクスポートできます。

: オーディオとバリアントは、NEEDLE_components および NEEDLE_persistent_assets を介して Needle Engine で既にサポートされていますが、KHR_audio および KHR_materials_variants のような既存の提案とのより多くの整合性に対するいくつかのオプションがあります。

three.js での glTF の読み込みについてさらに学ぶ

圧縮

プロダクション向けには、glTF-transform を使用して glTF アセットを圧縮します。テクスチャは、テクスチャ タイプに応じて、etc1suastcwebp または圧縮なしを使用します。メッシュはデフォルトで draco を使用しますが、meshtopt を使用するように設定できます (glTF ファイルごと)。カスタム拡張機能は不透明な方法でパススルーされます。

詳細については、デプロイメントと圧縮のページを参照してください。

ベンダー固有の glTF 拡張機能 (NEEDLE_*)

Needle Engine は、ベンダー拡張機能を使用して glTF ファイルにカスタム データを保存します。これらの拡張機能は柔軟に設計されており、比較的任意のデータをそれらに格納できます。特に、これらのファイルにはコードは保存されません。インタラクティブなコンポーネントは実行時にデータから復元されます。これは、Unity の AssetBundles が機能する方法といくつかの類似点があります。アセットの受信側は、ファイルに保存されているコンポーネントに対応するコードを持っている必要があります。

これらの拡張機能はまだ開発中であるため、現在スキーマを提供していません。以下の JSON スニペットは、使用例を通じて拡張機能の使用法を示しており、アーキテクチャ上の選択肢や今後のリリースで変更する可能性のあるものに関する注記が含まれています。

データの間の参照は、glTF ファイルの他の部分へのインデックスと JSON ポインターの組み合わせを通じて現在構築されています。今後のリリースでこれらのアプローチを統合する可能性があります。また、順序解決が困難な場合 (たとえば、相互に参照する 2 つのコンポーネント) には、文字列ベースの GUID を格納していますが、これも将来削除する可能性があります。

NEEDLE_components

この拡張機能にはノードごとのコンポーネント データが含まれています。コンポーネント名は、JavaScript 側と C# 側の両方でタイプ名にマッピングされます。 同じ名前の複数のコンポーネントを同じノードに追加できます。

NEEDLE_components のデータは、現在まだ批准されていない KHR_animation_pointer 拡張機能を通じてアニメーション化できます。

: コンポーネントのタイプ名のみを保存するということは、現在タイプ名はプロジェクトごとに一意である必要があることを意味します。将来のリリースでは、この制約をグローバルではなくパッケージごとの一意のコンポーネント タイプ名に緩和するために、パッケージ名を含めることを計画しています。

: 現在、拡張機能にはバージョン情報がありません (どの npm パッケージにコンポーネントが属しているか、どのバージョンのそのパッケージに対してエクスポートされたか)。将来のリリースでは、バージョン情報を含めることを計画しています。

: 現在、すべてのコンポーネントは builtin_components 配列に含まれています。将来のリリースでこれを単に components に名前変更する可能性があります。

NEEDLE_gameobject_data

この拡張機能には、状態、レイヤー、タグに関連するノードごとの追加データが含まれています。レイヤーは、three.js および Unity が扱う方法と同様に、レンダリングと物理の両方で使用されます。

: これがなぜ NEEDLE_components の別のエントリではないのかについて、より詳しく説明する必要があるかもしれません。

NEEDLE_lighting_settings

これは、glTF ファイルごとの環境光プロパティを定義するルート拡張機能です。

: この拡張機能は、ファイルごとではなくシーンごとに定義する必要があるかもしれません。

NEEDLE_lightmaps

これは、glTF ファイルのライトマップのセットを定義するルート拡張機能です。

: 現時点では、この拡張機能には環境テクスチャ参照も含まれています。将来のリリースでこれを変更することを計画しています。

Texture Type
Value

Lightmap

0

Environment Map

1

Reflection Map

2

ライトマップがどのように適用されるかは、NEEDLE_components 拡張機能内の MeshRenderer コンポーネントでノードごとに定義されます。

: 将来のリリースでこれを変更し、ライトマップ関連のデータをノードごとの NEEDLE_lightmap 拡張エントリに移動する可能性があります。

NEEDLE_persistent_assets

NEEDLE_components 内のコンポーネントは、JSON Pointers を介してデータを参照できます。NEEDLE_persistent_assets のデータは、異なるコンポーネントによって複数回参照されることが多いため、ルート拡張機能として個別に保存されます。設計上、それらは常に何か他のものによって参照されるか (または相互に参照を持つか)、したがってタイプ情報をまったく保存しません。それらは単に JSON データの断片であり、それらを参照するコンポーネントは現在、何を期待するかを知っている必要があります。

ここに保存されるアセット/データの例としては、以下のようなものがあります。

  • AnimatorControllers、そのレイヤーと状態

  • PlayableAssets (タイムライン)、そのトラックと埋め込みクリップ

  • SignalAssets

  • ...

persistent_assets のデータは、JSON Pointer を介して他の persistent_assets を参照できますが、設計上、NEEDLE_components を参照することはできません。これは、Unity の「シーンデータ」と「アセットデータベースの内容」の間の分離に似ています。

: 今後、より多くのタイプ情報とバージョン情報を含める可能性があります。

NEEDLE_techniques_webgl

この拡張機能は、アーカイブされた KHR_techniques_webgl 拡張機能に基づき、いくつかの重要な箇所を拡張しています。元の拡張機能は WebGL 1.0 に対して指定されていましたが、ここでは WebGL 2.0 で使用し、多数の uniform 型を追加しています。

: 現在、頂点シェーダーとフラグメント シェーダーは常に URI として埋め込まれています。将来、そのデータを、より合理的な bufferViews に移動することを計画しています。

: ここにはいくつかの冗長なプロパティがあり、それらをクリーンアップすることを計画しています。

TypeScript とデータのマッピング

🏗️ 開発中

three.js を使用したレンダリング

🏗️ 開発中

なぜ WebAssembly にコンパイルしないのですか?

C# から IL、C++ (IL2CPP 経由)、WASM (emscripten 経由) への Unity のコンパイル プロセスは独創的ですが、比較的遅いです。単純なプロジェクトでも WASM にビルドするには何分もかかり、コードを変更するたびにそのプロセスがほぼ繰り返されます。賢いキャッシングや開発ビルドでのコード ストリッピングを最小限に抑えることで回避できる部分もありますが、それでも遅いままです。

WASM 翻訳のプロトタイプはありますが、完成にはほど遠く、イテレーション速度が遅いため、現在は積極的にこのパスを調査していません。

現代のウェブ ワークフローを見ると、開発中のコード リロード時間は無視できるほどで、通常は 1 秒未満の範囲です。これはもちろん、(ビルド時のコンパイラ最適化の代わりに、その場での JavaScript の解釈という) 多少のパフォーマンスを柔軟性と引き換えにしていますが、ブラウザは JavaScript を最大限に活用することに非常に優れています。

イテレーションと厳密なテスト ワークフローにとって、可能な限り迅速かつ頻繁にデバイス上およびターゲット プラットフォーム (この場合はブラウザ) でテストできることが有益であると私たちは信じています。そのため、私たちは Unity のプレイモード全体をスキップし、実質的に常にブラウザで実行しています。

: 非常に良い副次効果は、通常プレイモードに入るたびに 15~60 秒かかる遅い「ドメイン リロード」ステップ全体を回避できることです。プレイを押した瞬間にブラウザで「ライブ」になります。


このページはAIによって自動的に翻訳されました。

Last updated