Да, экспортеры / авторы glTF должны «разбивать» вершины в любом месте, где появляются прерывистые UV или нормали.
glTF предназначен для формата доставки с поддержкой GPU, формата последней мили, а не обмена артистами. формат. В результате его внутренние структуры данных почти соответствуют 1: 1 тому, как атрибуты вершин передаются в графический процессор, например, с атрибутом vec3 position, vec3 normal attribute и, возможно, текстурой vec2 координата в типичном случае. Так что да, один нормальный и один UV для каждой вершины, как и ожидалось для набора необработанных данных, передаваемых в GPU.
Часть преимущества состоит в том, что хорошо отобранная коллекция файлов glTF будет содержать двоичные полезные данные, которые могут быть установлены (например) на мобильные устройства, где эти мобильные устройства могут затем передавать целые секции двоичных данных прямо в память графического процессора без дальнейшей обработки. Например, фреймворкам WebGL не нужно много обрабатывать вершины после получения файла, они просто загружают его и визуализируют. Бремя явно возлагается на экспортеров и писателей, а не читателей и загрузчиков.
Более подробная информация о структуре довольно хорошо изложена в glTF Tutorial . В частности, раздел Buffers, Buffer Views и Accessors охватывает необработанное хранение данных вершин в двоичных двоичных объектах. Как правило, программист, знакомый с графическими API-интерфейсами, может рассматривать glTF accessor как отдельный атрибут вершины, а bufferView - как блок памяти графического процессора, содержащий несколько атрибутов вершины (средства доступа) на одном шаге, возможно, с чередованием . Сам по себе buffer - это просто кусок всех двоичных данных (bufferViews) в glTF без каких-либо шагов.