Извините, ничего не найдено.

Не расстраивайся! Лучше выпей чайку!
Регистрация
Справка
Календарь

Вернуться   www.boolean.name > Программирование в широком смысле слова > Алгоритмика

Алгоритмика Об алгоритмах вообще; методы, обсуждения способов решения

Ответ
 
Опции темы
Старый 06.04.2014, 20:53   #1
moka
.
 
Регистрация: 04.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,861 пользователей)
Структура данных в вершинном буфере.

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

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

Вопрос стоит в том какие подходы вы предпочитаете: требовать от всех моделей одного формата и адаптировать данные под этот формат, заполняя не существующие данные стандартными.
Или пишете систему что адаптируется под разный набор данных, но как быть с разными шейдерами (Program в OGLES)?
Либо имеете определённый набор типов моделей (спрайты, статика, динамика, анимированные, и т.д.), и модель данные модели адаптируются под тип объекта?
(Offline)
 
Ответить с цитированием
Старый 06.04.2014, 21:07   #2
Mr_F_
Терабайт исходников
 
Аватар для Mr_F_
 
Регистрация: 13.09.2008
Сообщений: 3,907
Написано 2,157 полезных сообщений
(для 5,843 пользователей)
Ответ: OpenGL структура данных в вершинном буфере.

Или пишете систему что адаптируется под разный набор данных, но как быть с разными шейдерами (Program в OGLES)?
В Д3Д юзал это. Более того, у меня даже в формате моделей загружаемых можно было объявить свою структуру вертекса, и каждая модель могла хранить какие угодно данные, лишь бы шейдер переварил.
Насчёт разных шейдеров не совсем понял в чём трабла - шейдеры должны быть как раз под твои данные. Ну т.е. зачем тебе юзать шейдер статики на скинмеше?
__________________
бложик | geom.io | твиттер | faded | демо 1 2 | роботы | лайтмаппер
(Offline)
 
Ответить с цитированием
Старый 06.04.2014, 21:20   #3
moka
.
 
Регистрация: 04.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,861 пользователей)
Ответ: OpenGL структура данных в вершинном буфере.

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

Сообщение от Mr_F_ Посмотреть сообщение
Насчёт разных шейдеров не совсем понял в чём трабла - шейдеры должны быть как раз под твои данные. Ну т.е. зачем тебе юзать шейдер статики на скинмеше?
Ну шейдер не ругается если в него не запихнули данные которые он там ожидает, но вот если пытаться впихнуть данные по аттрибуте которые шейдер не ожидает, WebGL например просто ругается по этому поводу, каждый раз когда биндишь. Следственно то что шейдер ожидает тоже нужно "уважать".
(Offline)
 
Ответить с цитированием
Старый 06.04.2014, 21:33   #4
Samodelkin
Мастер
 
Регистрация: 12.01.2009
Сообщений: 977
Написано 388 полезных сообщений
(для 630 пользователей)
Ответ: Структура данных в вершинном буфере.

Можно использовать один вертекс декларейшн, но продумать его таким образом, чтобы можно было одни и теже данные вершин использовать по разному в зависимости от контента и шейдера, тем самым минимизировать размер данных вершины. Например в статике это tc2, а в анимации в tc2.x можно записать вес вершины и шейдер ее по другому обработает.
(Offline)
 
Ответить с цитированием
Старый 06.04.2014, 21:40   #5
moka
.
 
Регистрация: 04.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,861 пользователей)
Ответ: Структура данных в вершинном буфере.

Но если объекту не нужно ни то ни другое, зачем расходовать лишний раз память и гонять буфера (дольше загрузка и т.п.)?
(Offline)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
Mr_F_ (06.04.2014)
Старый 06.04.2014, 22:37   #6
Mr_F_
Терабайт исходников
 
Аватар для Mr_F_
 
Регистрация: 13.09.2008
Сообщений: 3,907
Написано 2,157 полезных сообщений
(для 5,843 пользователей)
Ответ: Структура данных в вершинном буфере.

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

Например в статике это tc2, а в анимации в tc2.x можно записать вес вершины и шейдер ее по другому обработает.
для некоторых моделей очень жирный буфер все равно понадобится (персонаж с бампом), для террейна я например вообще юзал убер пожатый формат, типа 4 байта на позицию и запечённое АО + ещё 4 на нормали.
меньше нагрузка на шину - это важно.
__________________
бложик | geom.io | твиттер | faded | демо 1 2 | роботы | лайтмаппер
(Offline)
 
Ответить с цитированием
Эти 2 пользователя(ей) сказали Спасибо Mr_F_ за это полезное сообщение:
HolyDel (07.04.2014), Samodelkin (07.04.2014)
Старый 07.04.2014, 00:22   #7
moka
.
 
Регистрация: 04.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,861 пользователей)
Ответ: Структура данных в вершинном буфере.

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

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

Как понимаю один буффер на много лучше разделённых (меньше биндов и указаний видяхе).
(Offline)
 
Ответить с цитированием
Старый 07.04.2014, 02:36   #8
HolyDel
 
Регистрация: 25.09.2006
Сообщений: 6,030
Написано 1,469 полезных сообщений
(для 2,690 пользователей)
Ответ: Структура данных в вершинном буфере.

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

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

в новом движке для меша можно написать свой описатель вершины и в шейдере через layout (location) его использовать. у многих вижу такой подход. мне он кажется более правильным.
(Offline)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
Samodelkin (07.04.2014)
Старый 07.04.2014, 07:38   #9
Mr_F_
Терабайт исходников
 
Аватар для Mr_F_
 
Регистрация: 13.09.2008
Сообщений: 3,907
Написано 2,157 полезных сообщений
(для 5,843 пользователей)
Ответ: Структура данных в вершинном буфере.

layout (location = N)
не пашет такое в вебгле)
я тоже изначально планировал чётко указывать в шейдере какие аттрибуты куда тыкают в буфер, а вот хер.
только в нормальном ГЛ.
из-за этого у меня на геом.ио костыльная несколько вышла система с форматом вертекса.
__________________
бложик | geom.io | твиттер | faded | демо 1 2 | роботы | лайтмаппер
(Offline)
 
Ответить с цитированием
Ответ


Опции темы

Ваши права в разделе
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


Часовой пояс GMT +1, время: 01:48.


vBulletin® Version 3.6.5.
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Перевод: zCarot
Style crйe par Allan - vBulletin-Ressources.com