まいつのページ
戻る

趣味で勉強したことのメモ

読了目安: 8分

趣味で勉強したことをここに書いていこうと思う。
私は見栄っ張りだから、誰かが見てくれる可能性が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にそのまま渡せるとかではない。

仕様が明文化されているって本当に素晴らしくてありがたいことであるなあ。

3D Tiles 1.1

3D Tiles Specificationを読んで気になったところをメモしていこうと思う。

3D Tilesは地理データ（でかくなりがち）を効率よく配信するためのファイル形式。
JSON + glTF という構成。
木構造になっていて、広範囲で簡略化されたデータ-空間的に分割された詳細なデータという風につながっていく。
JSONの中に、どの範囲のどの詳細度のデータを表示すべきかを判定するためのメタデータが入っている。

LOD

大まかに、遠くのものは簡略化されたモデルを、近くのものは詳細なモデルを表示する仕組み。

Geometric error

簡略化されたモデルが、元の形状から最大どれだけずれているかをm単位で書いておく。
実行時に、距離や画面解像度と組み合わせて Screen-Space Errorに変換し、その結果で詳細なモデルに切り替えるかを決めるのに使う。

Bounding volumes

タイルを覆う空間を定義する。box, sphere, region で書ける。

Transforms

3D Tiles は z-up 、glTF は y-up

More broadly the order of transformations is:
glTF node hierarchy transformations
glTF y-up to z-up transform
Tile transform

3D Tiles を出力するときは、glTF は y-up で、tileset.json は z-up で書けばいいのね
了解、でも辛いね

External tilesets

3D Tiles は content.uri で別の 3D Tiles を参照することで入れ子にできる
content.uri で別の 3D Tiles を参照したときは、children を持たせてはいけない。

Spatial data structures

tileset が定義した任意の木を描画できる。
子タイルの中身が親タイルのbounding volume内に収まるという条件さえ満たせばよい。
どのタイルを表示するかは Geometric error と Bounding volumes で判定するから、木構造は好きにしていいということなんだろうな。
schema のシンプルさよりも構造の柔軟性を取ったのだろう。
構造を柔軟にできるように、どんな構造でも対応できるタイル探査システムを外付けしたというべきか。

Quadtree

4つの子タイルに分かれる。中心の緯度経度で均等分割する 2D 地理空間タイルに近い。が、3D Tiles ではもっと柔軟に書くことが許されている。
4分割でなくていいし、子同士が重なっていてもいいし、親を全部覆う必要もない。
これの規則的な分け方がimplicit tiling（暗黙的タイリング）でサポートされている。（後述）

Octrees

3 本の直交分割面で 8 個の子タイルに分ける。
これの規則的な分け方がimplicit tiling（暗黙的タイリング）でサポートされている。（後述）

K-d tree

2つの子タイルに分かれる。分割面は x, y, z 軸、あるいは緯度、経度、高さに平行。

Grids

任意の子タイルを持つ。

Implicit Tiling

規則的な分割を全ノード列挙しなくてもいいように、テンプレートURL（level,x,y,z）でアクセスする仕組み。
tileset.json の記述量を減らすことができる。
また、タイル座標からのランダムアクセスが可能となり、空間クエリの高速化・タイル更新の効率化なども利点である。 分割したすべてのタイルが存在する必要はなく、subtreeでどのタイルが存在するかを指定する。

Metadata

3D Tiles 1.1 では、メタデータは tileset/tile/content/feature などのEntityだけでなく、vertex/texel のような要素にも関連付け可能
schemaをtileset内に埋め込んでもよいし、外部参照（schemaUri）してもよい。

Styling

タイルセットの各featureに対して、表示するかどうかと、色を指定できる。

座標参照系（CRS：Coordinate Reference System）

地球上の位置を数値で表すときの決まり。いろいろな種類があって、代表的なものは、緯度経度で表す地理座標系と、平面に投影した投影座標系がある。識別するためのEPSGコードというのがある。

地理座標系

WGS 84（World Geodetic System 1984）

地球モデルはWGS84楕円体、原点は地球の質量中心、位置を緯度経度で表す。GPS測位で使われている。
Cesiumの座標系はこれと、これを地心直交座標系で表現したものを使う。

投影座標系

地球を平面に投影する。
日本では平面直角座標系が設定されている。北をXの正、東をYの正方向としている。19か所の原点が定められている。北（上）がXなので、数学とかで見慣れているのとは逆になるので注意。

空間ID

空間ID・3次元空間情報基盤の活用人材育成 特別講座 を視聴したり、 4 次元時空間情報利活用のための空間 ID ガイドライン（1.1 版）を読んで気になったところをメモする。

後で読む
【パブリックコメント】4次元時空間情報利活用のための空間IDガイドライン（1.2 beta版）

シェーダー

書けるようになりたい

トポロジー

いつか勉強したい

線形代数

いつか勉強したい

で共有
前の記事
ラブレター日記
次の記事
デッサン教室5