Структура данных в вершинном буфере.
Основываясь тому что много кто тут писал/пишет движки, то думаю вопрос будет актуальным. Если он относиться к DirectX равным счётом - дайте знать, поправлю топик.
Разные модели (статика, динамика, со скелетом, и т.п.) требуют разную структуру данных для вершин. Например для статики может хватать: position, normal, tc1, tc2, иногда чуток больше. Для динамики же tc2 часто не нужен, но нужны данные о весах вершины к кости, или цвета вершины, а может и других данных в зависимости от ситуации. Вопрос стоит в том какие подходы вы предпочитаете: требовать от всех моделей одного формата и адаптировать данные под этот формат, заполняя не существующие данные стандартными. Или пишете систему что адаптируется под разный набор данных, но как быть с разными шейдерами (Program в OGLES)? Либо имеете определённый набор типов моделей (спрайты, статика, динамика, анимированные, и т.д.), и модель данные модели адаптируются под тип объекта? |
Ответ: OpenGL структура данных в вершинном буфере.
Цитата:
Насчёт разных шейдеров не совсем понял в чём трабла - шейдеры должны быть как раз под твои данные. Ну т.е. зачем тебе юзать шейдер статики на скинмеше? |
Ответ: OpenGL структура данных в вершинном буфере.
Цитата:
Цитата:
|
Ответ: Структура данных в вершинном буфере.
Можно использовать один вертекс декларейшн, но продумать его таким образом, чтобы можно было одни и теже данные вершин использовать по разному в зависимости от контента и шейдера, тем самым минимизировать размер данных вершины. Например в статике это tc2, а в анимации в tc2.x можно записать вес вершины и шейдер ее по другому обработает.
|
Ответ: Структура данных в вершинном буфере.
Но если объекту не нужно ни то ни другое, зачем расходовать лишний раз память и гонять буфера (дольше загрузка и т.п.)?
|
Ответ: Структура данных в вершинном буфере.
Цитата:
Цитата:
меньше нагрузка на шину - это важно. |
Ответ: Структура данных в вершинном буфере.
Цитата:
Тут либо мы ставим правила по названию аттрибутов, и если есть данные из формата модели - поинтим, если нет, то пропускаем. Либо мы скидываем это на разработчика, чтобы он сам отвечал за какие данные в буфере куда поинтить (аттрибуты). Либо мы пишем полностью автономную тему, с define'ами или пропроцессами которыми можем в шейдере метить аттрибуты, что-то типа: Код:
attribute vec3 aVertexPosition : POSITION0; Я думаю над подходом позволяющим следовать лёгким "правилам" и тогда вообще не нужно париться, и при этом возможность не следовать им вообще и самому всё указывать. Как понимаю один буффер на много лучше разделённых (меньше биндов и указаний видяхе). |
Ответ: Структура данных в вершинном буфере.
Цитата:
Код:
attribute vec3 aVertexPosition : POSITION0; в gl3.0+ и gles 3.0 синтаксис таков: Код:
layout (location = N) in vec3 aVertexPosition в акселе использовался один форат вершины на тип геометрии (два на сюрфейс, там данные были либо с двумя tc либо с цветом, в который можно было пропихнуть что нибудь). т.е. обыные меши одни формат, скиненные другой, спрайтовые системы третий и т.д. при компиляции шейдера все стандартные аттрибуты жестко связывались (glBindAttribLocation). иногда этого не хватало. и намного чаще буфер был просто жирнее чем нужно. в принципе не смертельно, но все равно неприятно. в новом движке для меша можно написать свой описатель вершины и в шейдере через layout (location) его использовать. у многих вижу такой подход. мне он кажется более правильным. |
Ответ: Структура данных в вершинном буфере.
Цитата:
я тоже изначально планировал чётко указывать в шейдере какие аттрибуты куда тыкают в буфер, а вот хер. только в нормальном ГЛ. из-за этого у меня на геом.ио костыльная несколько вышла система с форматом вертекса. |
Часовой пояс GMT +4, время: 10:59. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot