OBJファイルの読み込み処理を修正

OBJファイルの読み込み処理を修正した。わりと複雑なモデルも読み込めるようになった。

画像のドラゴンのモデルは 871,306 ポリゴンもあるようだ。読み込み処理自体は数秒かかるものの、画面に表示する時はタスクマネージャで確認するとCPU負荷は増えていなかった。画面に描くモデルの複雑さによってCPU負荷も増えると思っていたけど、そうでもないようだ。GPU負荷は増えてそうだけど。

このモデルは次のサイトからお借りした。

McGuire Computer Graphics Archive

インターネットで軽く検索した感じではOBJファイルの全貌が分かるほど細かいドキュメントがなさそうだった。上のドラゴンのモデルは "ｆ" の項目にマイナスの値が入っていて、どの頂点を指すのか謎だった。

色々試していくと、マイナスのｆの値は、その行までに登場した頂点の個数 (ｖの行数) からｆの値分、前に戻るという指示のようだった。具体的には、

v  -1.01  0.00   0.99
v   1.00  0.00   0.99
v   1.00  0.00  -1.04
v  -0.99  0.00  -1.04

f -4 -3 -2 -1

v  -1.02  1.99   0.99  
v  -1.02  1.99  -1.04
v   1.00  1.99  -1.04
v   1.00  1.99   0.99

f -4 -3 -2 -1

というようなファイルがあったとすると、最初のｆが登場する時、

-4, -3, -2, -1

の代わりに、

0, 1, 2, 3

がｆの値として使われる (そのように読み替える。１つめのｆの登場時点でｖの行数は４)。

次のｆも同様に、

-4, -3, -2, -1

の代わりに、

4, 5, 6, 7

が使われる (２つめのｆの登場時点でｖの行数は８)。

どういうことかというと、ｆの行が登場するまでのｖの行数をカウントしておき、その数からｆの (マイナスの) 値を足すことで実際のｆの値を求めることができる。つまり、

if (f[0] < 0) {
 f[0] = v.length + f[0];
}
// f[1], f[2], f[3] についても同じ処理を行う

というような値が実際のｆの値になる。ｖｎ (法線)、ｖｔ (テクスチャ座標) でも同じように処理する必要がある。

・関連するコミット

fix ObjReader · hikipuro/tea.js@5368861 · GitHub