Структура данных в вершинном буфере.
 

Основываясь тому что много кто тут писал/пишет движки, то думаю вопрос будет актуальным. Если он относиться к DirectX равным счётом - дайте знать, поправлю топик.

Разные модели (статика, динамика, со скелетом, и т.п.) требуют разную структуру данных для вершин. Например для статики может хватать: position, normal, tc1, tc2, иногда чуток больше. Для динамики же tc2 часто не нужен, но нужны данные о весах вершины к кости, или цвета вершины, а может и других данных в зависимости от ситуации.

Вопрос стоит в том какие подходы вы предпочитаете: требовать от всех моделей одного формата и адаптировать данные под этот формат, заполняя не существующие данные стандартными.
Или пишете систему что адаптируется под разный набор данных, но как быть с разными шейдерами (Program в OGLES)?
Либо имеете определённый набор типов моделей (спрайты, статика, динамика, анимированные, и т.д.), и модель данные модели адаптируются под тип объекта?

Ответ: OpenGL структура данных в вершинном буфере.
 

В Д3Д юзал это. Более того, у меня даже в формате моделей загружаемых можно было объявить свою структуру вертекса, и каждая модель могла хранить какие угодно данные, лишь бы шейдер переварил.
Насчёт разных шейдеров не совсем понял в чём трабла - шейдеры должны быть как раз под твои данные. Ну т.е. зачем тебе юзать шейдер статики на скинмеше?

Ответ: OpenGL структура данных в вершинном буфере.
 

А ты объявлял структуру данных исходя из формата модели, или свой формат был который это заранее хранил? Следственно у тебя была полная динамика в плане форматов?

Ну шейдер не ругается если в него не запихнули данные которые он там ожидает, но вот если пытаться впихнуть данные по аттрибуте которые шейдер не ожидает, WebGL например просто ругается по этому поводу, каждый раз когда биндишь. Следственно то что шейдер ожидает тоже нужно "уважать".

Ответ: Структура данных в вершинном буфере.
 

Можно использовать один вертекс декларейшн, но продумать его таким образом, чтобы можно было одни и теже данные вершин использовать по разному в зависимости от контента и шейдера, тем самым минимизировать размер данных вершины. Например в статике это tc2, а в анимации в tc2.x можно записать вес вершины и шейдер ее по другому обработает.

Ответ: Структура данных в вершинном буфере.
 

Но если объекту не нужно ни то ни другое, зачем расходовать лишний раз память и гонять буфера (дольше загрузка и т.п.)?

Ответ: Структура данных в вершинном буфере.
 

не совсем понял вопрос. формат модели один, формат вертексного буфера в ней - любой, в этом плане динамика.

для некоторых моделей очень жирный буфер все равно понадобится (персонаж с бампом), для террейна я например вообще юзал убер пожатый формат, типа 4 байта на позицию и запечённое АО + ещё 4 на нормали.
меньше нагрузка на шину - это важно.

Ответ: Структура данных в вершинном буфере.
 

Ну вот я вижу такой pipeline: есть модель, любой формат, пишем/берём парсер, получаем доступ к данным, position 3, normal (3), color (4), tc(2), ... далее это дело пихаем в буффер. Тут варианта 2: либо в один буфер, либо по разным буферам., далее когда нужно это дело рендерить, биндим нужный буффер/ы, и далее поинтим участки буффера на аттрибуты в шейдере (vertexAttribPointer), и тут то загвоздка. Что во первых имена переменных зависят от шейдера, во вторых нужно знать что и куда поинтить.
Тут либо мы ставим правила по названию аттрибутов, и если есть данные из формата модели - поинтим, если нет, то пропускаем. Либо мы скидываем это на разработчика, чтобы он сам отвечал за какие данные в буфере куда поинтить (аттрибуты).
Либо мы пишем полностью автономную тему, с define'ами или пропроцессами которыми можем в шейдере метить аттрибуты, что-то типа:
И как ранее если у модели есть данные, биндим и указываем на них, если нет - пропускаем.

Я думаю над подходом позволяющим следовать лёгким "правилам" и тогда вообще не нужно париться, и при этом возможность не следовать им вообще и самому всё указывать.

Как понимаю один буффер на много лучше разделённых (меньше биндов и указаний видяхе).

Ответ: Структура данных в вершинном буфере.
 

да, interleaved данные лучше. отдельными буферами можно делать тогда, когда часть данных постоянно заливается с хоста, а часть не меняется. (например позиции/нормали меша какой нибудь тряпки считающейся на цпу в одном буфере, а ее tc в другом, ибо позиции/нормали меняются, а tc нет)

это реально такой синтаксис в webgl-е или типа хотелки?
в gl3.0+ и gles 3.0 синтаксис таков:
по теме:
в акселе использовался один форат вершины на тип геометрии (два на сюрфейс, там данные были либо с двумя tc либо с цветом, в который можно было пропихнуть что нибудь).
т.е. обыные меши одни формат, скиненные другой, спрайтовые системы третий и т.д. при компиляции шейдера все стандартные аттрибуты жестко связывались (glBindAttribLocation).
иногда этого не хватало. и намного чаще буфер был просто жирнее чем нужно. в принципе не смертельно, но все равно неприятно.

в новом движке для меша можно написать свой описатель вершины и в шейдере через layout (location) его использовать. у многих вижу такой подход. мне он кажется более правильным.

Ответ: Структура данных в вершинном буфере.
 

не пашет такое в вебгле)
я тоже изначально планировал чётко указывать в шейдере какие аттрибуты куда тыкают в буфер, а вот хер.
только в нормальном ГЛ.
из-за этого у меня на геом.ио костыльная несколько вышла система с форматом вертекса.