Вопрос о Wavefront .obj Формат дизайна - PullRequest
0 голосов
/ 24 октября 2019

Недавно я переписывал загрузчик модели Wavefront и использовал данные как индексированный объект буфера вершин. После того, как все заработало, я понял кое-что о формате .obj, чего раньше не замечал. Кажется, что индексы являются инкрементными по отношению к последнему наибольшему индексу из предыдущей совместной модели в файле. Вот пример файла .obj, который представляет собой не более чем несколько кубов.

# Blender v2.80 (sub 75) OBJ File: ''
# www.blender.org
mtllib Cubes.mtl
o Cube
v 1.000000 1.000000 -1.000000
v 1.000000 -1.000000 -1.000000
v 1.000000 1.000000 1.000000
v 1.000000 -1.000000 1.000000
v -1.000000 1.000000 -1.000000
v -1.000000 -1.000000 -1.000000
v -1.000000 1.000000 1.000000
v -1.000000 -1.000000 1.000000
vt 0.625000 0.000000
vt 0.375000 0.250000
vt 0.375000 0.000000
vt 0.625000 0.250000
vt 0.375000 0.500000
vt 0.375000 0.250000
vt 0.625000 0.500000
vt 0.375000 0.750000
vt 0.625000 0.750000
vt 0.375000 1.000000
vt 0.375000 0.500000
vt 0.125000 0.750000
vt 0.125000 0.500000
vt 0.875000 0.500000
vt 0.625000 0.500000
vt 0.625000 0.250000
vt 0.625000 0.750000
vt 0.625000 1.000000
vt 0.375000 0.750000
vt 0.875000 0.750000
vn 0.0000 1.0000 0.0000
vn 0.0000 0.0000 1.0000
vn -1.0000 0.0000 0.0000
vn 0.0000 -1.0000 0.0000
vn 1.0000 0.0000 0.0000
vn 0.0000 0.0000 -1.0000
usemtl Material
s off
f 5/1/1 3/2/1 1/3/1
f 3/4/2 8/5/2 4/6/2
f 7/7/3 6/8/3 8/5/3
f 2/9/4 8/10/4 6/8/4
f 1/11/5 4/12/5 2/13/5
f 5/14/6 2/9/6 6/15/6
f 5/1/1 7/16/1 3/2/1
f 3/4/2 7/7/2 8/5/2
f 7/7/3 5/17/3 6/8/3
f 2/9/4 4/18/4 8/10/4
f 1/11/5 3/19/5 4/12/5
f 5/14/6 1/20/6 2/9/6
o Cube.001
v 1.023054 3.453142 -4.075902
v 1.023054 1.453142 -4.075902
v 1.023054 3.453142 -2.075902
v 1.023054 1.453142 -2.075902
v -0.976946 3.453142 -4.075902
v -0.976946 1.453142 -4.075902
v -0.976946 3.453142 -2.075902
v -0.976946 1.453142 -2.075902
vt 0.625000 0.000000
vt 0.375000 0.250000
vt 0.375000 0.000000
vt 0.625000 0.250000
vt 0.375000 0.500000
vt 0.375000 0.250000
vt 0.625000 0.500000
vt 0.375000 0.750000
vt 0.625000 0.750000
vt 0.375000 1.000000
vt 0.375000 0.500000
vt 0.125000 0.750000
vt 0.125000 0.500000
vt 0.875000 0.500000
vt 0.625000 0.500000
vt 0.625000 0.250000
vt 0.625000 0.750000
vt 0.625000 1.000000
vt 0.375000 0.750000
vt 0.875000 0.750000
vn 0.0000 1.0000 0.0000
vn 0.0000 0.0000 1.0000
vn -1.0000 0.0000 0.0000
vn 0.0000 -1.0000 0.0000
vn 1.0000 0.0000 0.0000
vn 0.0000 0.0000 -1.0000
usemtl Material
s off
f 13/21/7 11/22/7 9/23/7
f 11/24/8 16/25/8 12/26/8
f 15/27/9 14/28/9 16/25/9
f 10/29/10 16/30/10 14/28/10
f 9/31/11 12/32/11 10/33/11
f 13/34/12 10/29/12 14/35/12
f 13/21/7 15/36/7 11/22/7
f 11/24/8 15/27/8 16/25/8
f 15/27/9 13/37/9 14/28/9
f 10/29/10 12/38/10 16/30/10
f 9/31/11 11/39/11 12/32/11
f 13/34/12 9/40/12 10/29/12
o Cube.002
v -1.453796 3.256773 1.773842
v -1.453796 1.256773 1.773842
v -1.453796 3.256773 3.773842
v -1.453796 1.256773 3.773842
v -3.453796 3.256773 1.773842
v -3.453796 1.256773 1.773842
v -3.453796 3.256773 3.773842
v -3.453796 1.256773 3.773842
vt 0.625000 0.000000
vt 0.375000 0.250000
vt 0.375000 0.000000
vt 0.625000 0.250000
vt 0.375000 0.500000
vt 0.375000 0.250000
vt 0.625000 0.500000
vt 0.375000 0.750000
vt 0.625000 0.750000
vt 0.375000 1.000000
vt 0.375000 0.500000
vt 0.125000 0.750000
vt 0.125000 0.500000
vt 0.875000 0.500000
vt 0.625000 0.500000
vt 0.625000 0.250000
vt 0.625000 0.750000
vt 0.625000 1.000000
vt 0.375000 0.750000
vt 0.875000 0.750000
vn 0.0000 1.0000 0.0000
vn 0.0000 0.0000 1.0000
vn -1.0000 0.0000 0.0000
vn 0.0000 -1.0000 0.0000
vn 1.0000 0.0000 0.0000
vn 0.0000 0.0000 -1.0000
usemtl Material
s off
f 21/41/13 19/42/13 17/43/13
f 19/44/14 24/45/14 20/46/14
f 23/47/15 22/48/15 24/45/15
f 18/49/16 24/50/16 22/48/16
f 17/51/17 20/52/17 18/53/17
f 21/54/18 18/49/18 22/55/18
f 21/41/13 23/56/13 19/42/13
f 19/44/14 23/47/14 24/45/14
f 23/47/15 21/57/15 22/48/15
f 18/49/16 20/58/16 24/50/16
f 17/51/17 19/59/17 20/52/17
f 21/54/18 17/60/18 18/49/18
o Cube.003
v 3.506466 0.072150 -5.531102
v 3.506466 -1.927850 -5.531102
v 3.506466 0.072150 -3.531102
v 3.506466 -1.927850 -3.531102
v 1.506466 0.072150 -5.531102
v 1.506466 -1.927850 -5.531102
v 1.506466 0.072150 -3.531102
v 1.506466 -1.927850 -3.531102
vt 0.625000 0.000000
vt 0.375000 0.250000
vt 0.375000 0.000000
vt 0.625000 0.250000
vt 0.375000 0.500000
vt 0.375000 0.250000
vt 0.625000 0.500000
vt 0.375000 0.750000
vt 0.625000 0.750000
vt 0.375000 1.000000
vt 0.375000 0.500000
vt 0.125000 0.750000
vt 0.125000 0.500000
vt 0.875000 0.500000
vt 0.625000 0.500000
vt 0.625000 0.250000
vt 0.625000 0.750000
vt 0.625000 1.000000
vt 0.375000 0.750000
vt 0.875000 0.750000
vn 0.0000 1.0000 0.0000
vn 0.0000 0.0000 1.0000
vn -1.0000 0.0000 0.0000
vn 0.0000 -1.0000 0.0000
vn 1.0000 0.0000 0.0000
vn 0.0000 0.0000 -1.0000
usemtl Material
s off
f 29/61/19 27/62/19 25/63/19
f 27/64/20 32/65/20 28/66/20
f 31/67/21 30/68/21 32/65/21
f 26/69/22 32/70/22 30/68/22
f 25/71/23 28/72/23 26/73/23
f 29/74/24 26/69/24 30/75/24
f 29/61/19 31/76/19 27/62/19
f 27/64/20 31/67/20 32/65/20
f 31/67/21 29/77/21 30/68/21
f 26/69/22 28/78/22 32/70/22
f 25/71/23 27/79/23 28/72/23
f 29/74/24 25/80/24 26/69/24

Обратите внимание, как увеличиваются индексы в объявлениях лица. Каждая со-модель является прямым дополнением к последней лицевой линии от предыдущей модели. Мой первый вопрос: почему они увеличивают индексы? Разве не имеет смысла сбрасывать формат на 1 (0) для каждой совместной модели в файле? Естественно, я мог бы отрицать этот инкрементальный дизайн, отслеживая последний самый высокий индекс из предыдущей совместной модели и вычитая из этого любой новый индекс из следующей модели. Или, другими словами, если первая модель имела максимальное значение индекса 20, а следующая совместная модель имела начальный индекс 21, я мог бы просто сделать ((20-1) - (21-1)) - 1)чтобы получить индекс массива 0. Это поднимает мой второй вопрос, есть ли причина НЕ сводить на нет инкрементные индексы? Есть ли что-то полезное в инкрементных индексах, которых я не вижу? Возможно, глобальный список индексов для GL.DrawElements?

Надеюсь, кто-нибудь может рассказать мне об этой теме;Я был бы очень признателен.

1 Ответ

3 голосов
/ 24 октября 2019

Индексы внутри obj против индексов в OpenGL - довольно длинная тема. Основная веская причина наличия единого набора данных вершин и единого списка индексов заключается в том, что весь файл OBJ можно извлечь из одной пары VBO.

Индексы OBJ обычно нужно несколько массировать. Тот факт, что они начинаются с 1, немного раздражает (хотя вы можете обойти это, указав указатель вершины как элемент перед или уменьшив каждый индекс). Тот факт, что они могут индексировать треугольники / квадраты / полисы, означает, что вам, вероятно, потребуется триангулировать данные. Тот факт, что индексы НЕ разделяются между UV / normal / vertex, означает, что вы, вероятно, в конечном итоге создадите свой собственный набор индексов (вы можете использовать буферы хранения шейдеров для использования отдельных индексов, если вам нужно, но это может быть не самый быстрый подход),

В конечном счете, файлы obj довольно ужасны, как формат файла OpenGL во время выполнения. Вам было бы гораздо лучше написать простой инструмент для нанесения вреда файлам obj, массировать данные по мере необходимости, а затем выплевывать гораздо более простые для чтения двоичные файлы.

...