技術概要
Last updated
Last updated
Needle Engine は、おおよそ 3 つの要素で構成されています。
たとえば Unity Editor から Needle Engine 用のシーンを設定できる、多くのコンポーネントとツール。
シーンおよびコンポーネントのデータを glTF に変換するエクスポーター。
生成された glTF ファイルとその拡張機能を読み込み、実行するウェブ ランタイム。
ウェブ ランタイムはレンダリングに three.js を使用し、three シーン グラフの上にコンポーネント システムを追加し、カスタム glTF 拡張機能の拡張ローダーを接続します。
これにより、実質的に Unity や Blender のようなツールが空間ウェブ開発の強力なツールに変わります。glTF アセットが一般的な HTML、CSS、JavaScript、およびバンドル ワークフローに追加されます。
モデル、テクスチャ、アニメーション、ライト、カメラなどは、Needle Engine では として保存されます。 カスタム データは に保存されます。これらは、インタラクティブなコンポーネントから物理、シーケンス、ライトマップまで、すべてをカバーします。
Needle Engine によって作成される一般的なプロダクション glTF は、以下の拡張機能を使用します。
その他のサポートされる拡張機能：
サポートされるマテリアル拡張機能：
注: これらの拡張機能を使用するマテリアルは、UnityGLTF の
PBRGraphマテリアルを介して Unity からエクスポートできます。
注: オーディオとバリアントは、
NEEDLE_componentsおよびNEEDLE_persistent_assetsを介して Needle Engine で既にサポートされていますが、KHR_audioおよびKHR_materials_variantsのような既存の提案とのより多くの整合性に対するいくつかのオプションがあります。
プロダクション向けには、glTF-transform を使用して glTF アセットを圧縮します。テクスチャは、テクスチャ タイプに応じて、etc1s、uastc、webp または圧縮なしを使用します。メッシュはデフォルトで draco を使用しますが、meshtopt を使用するように設定できます (glTF ファイルごと)。カスタム拡張機能は不透明な方法でパススルーされます。
Needle Engine は、ベンダー拡張機能を使用して glTF ファイルにカスタム データを保存します。これらの拡張機能は柔軟に設計されており、比較的任意のデータをそれらに格納できます。特に、これらのファイルにはコードは保存されません。インタラクティブなコンポーネントは実行時にデータから復元されます。これは、Unity の AssetBundles が機能する方法といくつかの類似点があります。アセットの受信側は、ファイルに保存されているコンポーネントに対応するコードを持っている必要があります。
これらの拡張機能はまだ開発中であるため、現在スキーマを提供していません。以下の JSON スニペットは、使用例を通じて拡張機能の使用法を示しており、アーキテクチャ上の選択肢や今後のリリースで変更する可能性のあるものに関する注記が含まれています。
データの間の参照は、glTF ファイルの他の部分へのインデックスと JSON ポインターの組み合わせを通じて現在構築されています。今後のリリースでこれらのアプローチを統合する可能性があります。また、順序解決が困難な場合 (たとえば、相互に参照する 2 つのコンポーネント) には、文字列ベースの GUID を格納していますが、これも将来削除する可能性があります。
この拡張機能にはノードごとのコンポーネント データが含まれています。コンポーネント名は、JavaScript 側と C# 側の両方でタイプ名にマッピングされます。 同じ名前の複数のコンポーネントを同じノードに追加できます。
NEEDLE_components のデータは、現在まだ批准されていない KHR_animation_pointer 拡張機能を通じてアニメーション化できます。
注: コンポーネントのタイプ名のみを保存するということは、現在タイプ名はプロジェクトごとに一意である必要があることを意味します。将来のリリースでは、この制約をグローバルではなくパッケージごとの一意のコンポーネント タイプ名に緩和するために、パッケージ名を含めることを計画しています。
注: 現在、拡張機能にはバージョン情報がありません (どの npm パッケージにコンポーネントが属しているか、どのバージョンのそのパッケージに対してエクスポートされたか)。将来のリリースでは、バージョン情報を含めることを計画しています。
注: 現在、すべてのコンポーネントは
builtin_components配列に含まれています。将来のリリースでこれを単にcomponentsに名前変更する可能性があります。
これは、glTF ファイルごとの環境光プロパティを定義するルート拡張機能です。
注: この拡張機能は、ファイルごとではなくシーンごとに定義する必要があるかもしれません。
これは、glTF ファイルのライトマップのセットを定義するルート拡張機能です。
注: 現時点では、この拡張機能には環境テクスチャ参照も含まれています。将来のリリースでこれを変更することを計画しています。
Lightmap
0
Environment Map
1
Reflection Map
2
注: 将来のリリースでこれを変更し、ライトマップ関連のデータをノードごとの
NEEDLE_lightmap拡張エントリに移動する可能性があります。
NEEDLE_components 内のコンポーネントは、JSON Pointers を介してデータを参照できます。NEEDLE_persistent_assets のデータは、異なるコンポーネントによって複数回参照されることが多いため、ルート拡張機能として個別に保存されます。設計上、それらは常に何か他のものによって参照されるか (または相互に参照を持つか)、したがってタイプ情報をまったく保存しません。それらは単に JSON データの断片であり、それらを参照するコンポーネントは現在、何を期待するかを知っている必要があります。
ここに保存されるアセット/データの例としては、以下のようなものがあります。
AnimatorControllers、そのレイヤーと状態
PlayableAssets (タイムライン)、そのトラックと埋め込みクリップ
SignalAssets
...
persistent_assets のデータは、JSON Pointer を介して他の persistent_assets を参照できますが、設計上、NEEDLE_components を参照することはできません。これは、Unity の「シーンデータ」と「アセットデータベースの内容」の間の分離に似ています。
注: 今後、より多くのタイプ情報とバージョン情報を含める可能性があります。
この拡張機能は、アーカイブされた KHR_techniques_webgl 拡張機能に基づき、いくつかの重要な箇所を拡張しています。元の拡張機能は WebGL 1.0 に対して指定されていましたが、ここでは WebGL 2.0 で使用し、多数の uniform 型を追加しています。
注: 現在、頂点シェーダーとフラグメント シェーダーは常に URI として埋め込まれています。将来、そのデータを、より合理的な bufferViews に移動することを計画しています。
注: ここにはいくつかの冗長なプロパティがあり、それらをクリーンアップすることを計画しています。
🏗️ 開発中
🏗️ 開発中
C# から IL、C++ (IL2CPP 経由)、WASM (emscripten 経由) への Unity のコンパイル プロセスは独創的ですが、比較的遅いです。単純なプロジェクトでも WASM にビルドするには何分もかかり、コードを変更するたびにそのプロセスがほぼ繰り返されます。賢いキャッシングや開発ビルドでのコード ストリッピングを最小限に抑えることで回避できる部分もありますが、それでも遅いままです。
WASM 翻訳のプロトタイプはありますが、完成にはほど遠く、イテレーション速度が遅いため、現在は積極的にこのパスを調査していません。
現代のウェブ ワークフローを見ると、開発中のコード リロード時間は無視できるほどで、通常は 1 秒未満の範囲です。これはもちろん、(ビルド時のコンパイラ最適化の代わりに、その場での JavaScript の解釈という) 多少のパフォーマンスを柔軟性と引き換えにしていますが、ブラウザは JavaScript を最大限に活用することに非常に優れています。
イテレーションと厳密なテスト ワークフローにとって、可能な限り迅速かつ頻繁にデバイス上およびターゲット プラットフォーム (この場合はブラウザ) でテストできることが有益であると私たちは信じています。そのため、私たちは Unity のプレイモード全体をスキップし、実質的に常にブラウザで実行しています。
注: 非常に良い副次効果は、通常プレイモードに入るたびに 15～60 秒かかる遅い「ドメイン リロード」ステップ全体を回避できることです。プレイを押した瞬間にブラウザで「ライブ」になります。
このページはAIによって自動的に翻訳されました。
UnityGLTF のエクスポート コールバック (未文書化) および three.js の を使用して、さらに多くの拡張機能やカスタム拡張機能を追加できます。
詳細については、のページを参照してください。
この拡張機能には、状態、レイヤー、タグに関連するノードごとの追加データが含まれています。レイヤーは、 および が扱う方法と同様に、レンダリングと物理の両方で使用されます。
注: これがなぜ の別のエントリではないのかについて、より詳しく説明する必要があるかもしれません。
ライトマップがどのように適用されるかは、 拡張機能内の MeshRenderer コンポーネントでノードごとに定義されます。