趣味で勉強したことをここに書いていこうと思う。
私は見栄っ張りだから、誰かが見てくれる可能性が0ではないと思うと頑張れる。
このメモを公開することは、私以外の誰のためにもならないと思う。
見てくれてありがとうございます。
間違いなどありましたらご指摘いただけると大変嬉しいです。
glTF 2.0
glTF™ 2.0 Specificationを読んで気になったところをメモしていこうと思う。
訳は機械翻訳です。
3.3. Indices and Names
glTFアセットのエンティティは、対応する配列内のインデックスによって参照されます。
indexでアセットを参照する仕様だけど、IDのほうがよくない？
間に挿入したくなった時とか、全部ずらさないといけなくて大変そうだけど、どう？
3DかつWebだとファイルサイズを少しでも小さくすることがそれほど重要って解釈でいいのかな
それとも、GPU転送するときにそちらのほうが都合がいいとかあるのかしら？
調べた
glTF 1.0では dictionary objects + string IDでアセットに参照する仕様だった。
https://github.com/KhronosGroup/glTF/blob/main/specification/1.0/README.md#ids-and-names
これを、2.0で array + index での参照に変更した。
https://github.com/KhronosGroup/glTF/issues/831
ID検索で反復処理をサポートしていないJSONパーサーの存在や、ファイルサイズの削減、JSON.parse()のパフォーマンス改善、parse後のオブジェクトサイズの削減などが理由のようだ。
ただし、2.0以降で「リストインデックスの代わりに辞書キーを使用する」（1.0の使用に戻す）提案や、要素にIDを振る提案がなされている。
削除時のインデックス修正が必要になることが理由として挙げられている。issues/1576
アプリケーション間でデータのやり取りをするときに、ノード名を変更したら追跡できなくなることが理由として挙げられている。issues/2337
1つ目はアプリケーション側の実装でなんとかなりそうだけど、2つ目はファイル仕様変えないと何ともならない気がする。
glTFは実行時の効率性を重視しており、これは一般的な3D「オーサリング」フォーマットとは異なる設計目標です。
とあるし、なんでも仕様を盛ればいいってわけでもないから難しいんだろうな。
glTFは編集段階でのデータのやり取りというよりは、3Dデータが完成してからそれをユーザー環境へ転送するのが主目的だから、編集や削除がしやすいことよりも、データの小ささのほうが大事ということだ。
あ！ 1.0 の仕様でも 2.0 の仕様でも、
const mesh = gltf.meshes[node.mesh];JavaScriptだとこうアクセスできるんだ！
かっけえ
それとも、GPU転送するときにそちらのほうが都合がいいとかあるのかしら？
ない。
dictionary objects であろうと、array であろうと、バイナリデータ以外はCPU側でいったん解釈してからGPUに渡す。
CPUで解釈するときのパフォーマンスは変わるけど、GPUにそのまま渡せるとかではない。
- mesh は primitive の配列で、primitive 一つがGPU の draw call 1回分のデータのひとまとまり。
仕様が明文化されているって本当に素晴らしくてありがたいことであるなあ。
3D Tiles 1.1
3D Tiles Specificationを読んで気になったところをメモしていこうと思う。
読む予定
座標参照系
WGS 84
読む予定
トポロジー
いつか勉強したい
線形代数
いつか勉強したい