Компьютерная графика |
Привет, Гость! Войдите или зарегистрируйтесь.
Вы здесь » Компьютерная графика » Программирование графики и GPU » Обсуждение статьи про расширения EXT_draw_instanced и EXT_texture_buff
Собственно статья: http://steps3d.narod.ru/tutorials/draw- … orial.html
Ну как всегда предлагаю обсудить.
Очень интересная статья! Очень! Но к сожелению написана так, что без C не разобраться. Очень удручает 
.
Кстати, что значит "init ();" (процедура main)?
Не используйте вы EXT_draw_instanced. На данный момент псевдо-инстансинг на OpenGL дешевле. И переносимей...
Вот EXT_texture_buffer реально полезная вещь. Точнее была бы, если бы не плохая поддержка.
На данный момент псевдо-инстансинг на OpenGL дешевле.
Неправда! Аппаратный инстансинг работает быстрее своего псевдо аналога.
______________________________________________________________________________________
Кстати, Steps3D, здесь индексы в другие массивы вам не помогут! Это:
void Torus :: preDraw ()
{
int vertexStride = sizeof ( Vertex );
int texOffs = ((int)&vertices [0].tex) - ((int)&vertices [0]);
glPushClientAttrib ( GL_CLIENT_VERTEX_ARRAY_BIT );
// vertex data
glBindBufferARB ( GL_ARRAY_BUFFER_ARB, vertexId );
glEnableClientState ( GL_VERTEX_ARRAY );
glVertexPointer ( 3, GL_FLOAT, vertexStride, (void *)0 );
glClientActiveTextureARB ( GL_TEXTURE0_ARB );
glEnableClientState ( GL_TEXTURE_COORD_ARRAY );
glTexCoordPointer ( 2, GL_FLOAT, vertexStride, (void *)texOffs );
glEnableClientState ( GL_INDEX_ARRAY );
glBindBufferARB ( GL_ELEMENT_ARRAY_BUFFER_ARB, indexId );
}
Лишнее!
Как и это:
void Torus :: postDraw ()
{
// unbind array buffer
glBindBufferARB ( GL_ARRAY_BUFFER_ARB, 0 );
glBindBufferARB ( GL_ELEMENT_ARRAY_BUFFER_ARB, 0 );
glPopClientAttrib ();
}
Поэтому как насчёт прочитать это: http://www.opengl.org/wiki/Common_Mista … X_ARRAY.29
Отредактировано DungeonLords (2009-09-01 04:01:16)
Неправда! Аппаратный инстансинг работает быстрее своего псевдо аналога.
Отличие лишь в количестве вызовов glDraw*, но, учитывая что для glDrawElementsInstancedEXT нет возможности производить Frustum/Occlusion Culling, то в результате получается еще медленнее чем через псевдоинстансинг.
Кстати, Steps3D, здесь индексы в другие массивы вам не помогут! Это:
DungeonLords хотел сказать что GL_INDEX_ARRAY не имеет ничего общего с индексным буффером, потому вызывать glEnableClientState ( GL_INDEX_ARRAY ) нет надобности, и в качестве примера приводит ссылку с opengl.org, где как раз пишут об этой распространенной ошибке, связанной с созвучностью названия:
The problem is that GL_INDEX_ARRAY is not understood by the programmer.
GL_INDEX_ARRAY has nothing to do with indices for your glDrawRangeElements.
This is for color index arrays.
Неправда! Аппаратный инстансинг работает быстрее своего псевдо аналога.
У меня есть пруфлинк. С момента теста произошло только одно - на форвард контексте 3.1 у ати появилась поддержка EXT_draw_instanced (как следствие - он стал доступен для предыдущих версий OpenGL)
DungeonLords хотел сказать что GL_INDEX_ARRAY не имеет ничего общего с индексным буффером, потому вызывать glEnableClientState ( GL_INDEX_ARRAY ) нет надобности
И мне так кажется. GL_INDEX_ARRAY используется для индексирования в палитру цвета.
Отредактировано crsib (2009-08-31 21:21:45)
glBindBufferARB ( GL_ARRAY_BUFFER_ARB, 0 );
glBindBufferARB ( GL_ELEMENT_ARRAY_BUFFER_ARB, 0 );
Сорри оверпостинг, но двиг форума не очень удобен.
Данная операция является вполне законной. (За исключением реализации OpenGL 3.1 от AMD - они воспользовались не точной формулировкой khronos)
Действием данной операции будет установка стандартного буфера вершин/индексов. Это позволит:
а) Восстановить стандартное поведение gl{...}Pointer/glDrawElements
б) избежать ошибок при работе с буферами в сложных приложениях
Так что вам тоже стоит повнимательнее почитать материалы с OpenGL.org
PS. Обоснуйте хотя бы один из поставленных вами мне минусов
Да, с GL_INDEX_ARRAY я ошибся 
((((
Исправлю
Насчёт массива индексов в другие масивы я ошибался, очень здорово.
Steps3D, можно вам кое-что сказать на ушко? ЯПОНО-МАТЬ, НЕ ИСПОЛЬЗУЙТЕ ВЫ СВОЙ ДУРАЦКИЙ ТОРУС! Мне и многим другим пользователям нереально использовать текст вашей программы именно из-за того, что вы используете не относящиеся к теме файлы. Неужели нельзя было вместо туроса использовать треугольник? Это же как здорово!!! Треугольник! Получается, никаких файлов вроде Triangle.h (потому что нарисовать это в OpenGL супер просто) и великоя простота ваших статей, а так же, спасибо Алексею Викторовичу за прекрасную статью. Но вместо последнего предложения людям наступает, как это говорилось в фильме Хоттабыч, "глобальный облом".
Поэтому как насчёт предложения переработать первый пример? Ну или хотя бы совет дайте что ли, обитателям Delphi'ария (кроме предложения учить Си).
Отредактировано DungeonLords (2009-09-03 21:36:53)
Мне и многим другим пользователям нереально использовать текст вашей программы именно из-за того, что вы используете не относящиеся к теме файлы.
А зачем использовать текст програмы? Программы Алексея - иллюстрации к его статьям. Все, что теоретически можно использовать вне контекста статьи вынесено Алексеем в различные библиотеки. Если вы не в состоянии после прочтения статьи и разбора кода примера понять, как использовать какую-либо методику - то вы занимаетесь явно не своим делом.
Неужели нельзя было вместо туроса использовать треугольник? Это же как здорово!!! Треугольник!
Не вижу глобальной разницы. В контексте приложения, которое рисует нечто более интересное, чем треугольник - разницы нет никакой
Ну или хотя бы совет дайте что ли, обитателям Delphi'ария (кроме предложения учить Си).
Учить С++. На крайний случай ObjC,Java,C#. Если вас так интересует как нарисовать треугольник - то вообще хватит с головой Python'а. Delphi как язык (а не как IDE) - впринципе очень неудачное решение. А для 3D приложений - и подавно
Поэтому как насчёт предложения переработать первый пример?
И что предлагается переработать? Заменить тор на треугольник? Показать как можно извратиться что бы вывести 64 треугольника? Как говорили в значительно более качественно нарисованном чем Хоттабыч фильме TNMT - "Афигеть, дайте две"
2crsib,
у Алексея (который, надеюсь, в скором времени приоединится к нам) используется дурацкий файл Turus.h. В этот файл связан с текстом программы настолько тесно, насколько вы себе не представляете. И в коде, который в статье, использует его методы: setupBuffers, preDraw, postDraw. Поэтому я предлагаю всё, действительно всё необходимое, задействовать в файле основного проекта, а не половина в сатье, половина сныкана в файле. Ведь так будет всем легче!
Отредактировано DungeonLords (2009-09-04 15:08:20)
На одном треугольнике что-то показывать просто бессмысленно, должно быть тело из набора трегуольников
Насчет тора - может быть я перейду на более удобную обретку, но включать в каждый пример посмтоянно один из тот же код инициализации вершинных и индексных буферов - явно плохо
Вызов методов для этого (как и использование дополнительного класса) IMHO очень удобно
DungeonLords, setupBuffers, preDraw и postDraw никак не связанно с темой инстансинга, оно относится исключительно к VBO, и если ты удосужишься прочитать последнюю главу "своего учебника", который кстати тут тоже обсуждался, то поймешь что означают эти функции и поймешь на сколько ты не прав "осуждая" Алексея и что-то от него требуя.
Алексей, crsib - не обращайте внимание, ему уже чуть ли не построчно разобрали ваш код, отдельно была проведена очень длительная беседа по поводу VBO, все что ему нужно сделать - сесть и чуть-чуть подумать, возможно перечитать свой же учебник, но он вместо этого постит на всех форумах в заголовке которых есть "OpenGL" с просьбой помочь, и ведь помогают...
Но он по сути хочет чтоб вы привели ему весь код, причем с комментариями и в виде, в котором он сможет поместить его в свой учебник, после чего он успокоится и возьмется за очередную вашу статью 
Поднимаю старую тему. Возникла заминка, есть в статье такой вершинный шейдер:
[пам-пам-пам]
А фрагментного нету , обидно. Порылся в прилагаемых исходниках, там две верии, насколько я углядел [оба с расширением .fsh]. Один из них:
#extension GL_EXT_gpu_shader4 : enable
uniform isampler2DRect srcMap;
varying out ivec4 result;
void main ()
{
ivec4 tex = texture2DRect ( srcMap, gl_TexCoord [0].xy );
tex += ivec4 ( 1 );
result = ivec4 ( tex.x ^ tex.y, tex.x & tex.y, tex.x | tex.y, 777 );
}Начнём с того, что здесь опечатка. Не isampler2DRect, а sampler2DRect. Теперь спрашивается (наверное, очень странный вопрос) , это подходит к этому вершинному шейдеру:
uniform samplerBuffer texBuf;
void main(void)
{
vec4 instData = texelFetchBuffer ( texBuf, gl_InstanceID );
vec4 pos = gl_Vertex + instData;
gl_Position = gl_ModelViewProjectionMatrix * pos;
gl_TexCoord [0] = gl_MultiTexCoord0;
}
Вопрос задан поскольку мне кажется тема перекручена, не надо было использовать такой "продвинутый" тип как sampler2DRect.
Отредактировано DungeonLords (2010-08-24 21:06:42)
Начнём с того, что здесь опечатка. Не isampler2DRect, а sampler2DRect
Начнем с того, что здесь опечатки нет
Вопрос задан поскольку мне кажется тема перекручена, не надо было использовать такой "продвинутый" тип как sampler2DRect.
sampler2DRect от sampler2D очень оличается способом трактовки текстурных координат. Если нужно гарантировать точность выборки текселя, то sampler2D не подходит
Начнем с того, что здесь опечатки нет
Посмотрел opengl.org, вы правы, моя вина. iSampler2dRect служит для "a handle for accessing an integer 2D rectangular texture", хотя из этого непонятно для чего конкретно. Может для меньшего расхода памяти?
Вот вся семья:
sampler1D sampler2D sampler3D samplerCube
sampler1DShadow sampler2DShadow samplerCubeShadow
sampler1DArray sampler2DArray
sampler1DArrayShadow sampler2DArrayShadow
isampler1D isampler2D isampler3D isamplerCube
isampler1DArray isampler2DArray
usampler1D usampler2D usampler3D usamplerCube
usampler1DArray usampler2DArray
sampler2DRect sampler2DRectShadow isampler2DRect usampler2DRect
samplerBuffer isamplerBuffer usamplerBuffer
sampler2DMS isampler2DMS usampler2DMS
sampler2DMSArray isampler2DMSArray usampler2DMSArray
Отредактировано DungeonLords (2009-11-07 18:38:57)
Вам непонятно чем отличается float от integer? Тогда я мало чем могу помочь...
Достаточно интересно, что в ядра 3.3/4.0 вошел D3D9 style инстансинг. В данном случае в виде ARB(NVX)_instanced_arrays. Стоит отметить, что оно поддерживается SM3.0 картами обоих производителей. При этом khronos упоминает его в своей презентации чуть ли не как в виде большой плюшки для перехода на 3.3 ядро. Что весьма странно с учетом того, что в 3.2 значительно удобнее пользоваться D3D10 style инстансингом (хотя на самом D3D10 он более удобный и гибкий)
Я тут перевожу текст о ARB_instanced_arrays, присоединяйтесь! Ссылка.
Отредактировано DungeonLords (2010-08-26 00:01:36)
I
Steps3D, есть к вам следующее предложение: добавьте в вашу статью о EXT_draw_instanced аналогичный этому текст:
(из спецификации OGL 4.1)
L.3.44 Instanced Rendering
.
This instanced rendering interface is a less-capable form of GL_ARB_draw_-
instanced which can be supported on older hardware.
The name string for instanced rendering is GL_ARB_instanced_arrays.
То есть описанное вами расширение устарело и теперь нужно использовать GL_ARB_instanced_arrays.
II
Пожалуйста, не громоздите файлы как попало в ваших каталогах. Смотрел откомпилированные примеры для Windows по статье, там файлы находятся в совершенном хаосе! Это уже не первый раз в ваших примерах. Ещё, как так получилось, что на три экзешника в архиве находятся семь шейдеров? Плохо, что нет логики именования шейдеров, то есть: fragment-2.fsh, program-1.fsh, fragment.fsh. К слову, что за fragment.fsh, помоему он из другой оперы.
Ни один пример не запускается, вижу чёрный экран. Почему вы не приложили какую-нибудь левую текстурку (2x2, скажем)?
III
Так, а это уже bagreport.
Функции "textFetchBuffer", как написано в вашей статье, не существует. На самом деле это пишется как "texelFetchBuffer".
IV
Вы пишите, что объект текстурного буфера служит для заполнения его текстурой. А сами же зполняете его не текстурой, а чёрт знает чем: смещением торусов. Зачем вы сами себе противоречите? Буду изучать пример отсюда: http://developer.download.nvidia.com/SD … mples.html [потом]Ага, глянул я это великолепие. Steps3D, помоему вы вешаете лапшу на уши этим предложением: "Довольно часто возникает необходимость использовать текстуру просто как большой массив с данными", есть другое мнение: "Данная технология позволяет считывать в вершинном шейдере данные из буфера, используя тексели текстуры как ячейки хранения данных."
Отредактировано DungeonLords (2010-08-31 00:40:36)
4. Где противоречие?
Вы прооцитировали тоже что я и писал - буфер используется для хранения большого массива данных
3. Исправлю
1. ARB_instanced_arrays - это полный аналог соответствующей возможности из D3D9 и НВидия вводила его в свое время как экспериментальное, но отказалась
Именно это расширение может идти на старом железе, а EXT_draw_instanced требует железа на уровне G80
Кроме того EXT_draw_instanced гораздо более гибкое
На ajhevt opengl.org было в свое время обсуждение этой темы и было сказано, что выйгрышь в OpenGL от D3D9 -инстансинга небольшой и лучше использовать имекнно EXT_draw_instanced (по словам представителя НВидиа)
Исходное расширение от NVidia - NVX_instanced_arrays
Вы прооцитировали тоже что я и писал - буфер используется для хранения большого массива данных
1)У вас не сказано, зачем это нужно.
2)У вас не сказано, почему TBO лучше, чем bindable uniform. Хотя на этот вопрос ответили нам специалисты NVidia в документе, прилагаемом в SDK 10:
GL_EXT_texture_buffer_object to access large blocks of data from within the
vertex shader. In this sample, the texture buffer is used to contain irregularly
indexed vertex data, with the indexing all handled from within the shader. Note that
the performance when fetching from the texture buffer object is significantly less
than the performance when using vertex buffer objects to supply the geometry. This
is because the model and shader in this sample are not bound by the vertex attribute
fetch stage of the pipeline. Instead, they are bound by the shader, so the additional
work of fetching the vertices reduces the performance. Under certain scenarios,
where the hardware is bottlenecked on vertex attribute fetching, using a texture
buffer object to hold some of the attributes may provide a performance advantage.
Осталось перевести и вставить.
В итоге ананимус подумал, что TBO служит для хранения текстуры без фильтрации и прочих фитч.
ARB_instanced_arrays - это полный аналог соответствующей возможности из D3D9 и НВидия вводила его в свое время как экспериментальное, но отказаласьИменно это расширение может идти на старом железе, а EXT_draw_instanced требует железа на уровне G80Кроме того EXT_draw_instanced гораздо более гибкоеНа ajhevt opengl.org было в свое время обсуждение этой темы и было сказано, что выйгрышь в OpenGL от D3D9 -инстансинга небольшой и лучше использовать имекнно EXT_draw_instanced (по словам представителя НВидиа)
Есть ещё одно мнение - отправить в топку оба расширения и пользоваться геометрическим шейдером. Но в спецификации OGL 4.1 английским языком написано: "GL_ARB_draw_instanced для старого железа, GL_ARB_instanced_arrays для нового."
Отредактировано DungeonLords (2010-08-31 20:13:49)
1) - очевидно
2) - ну не запихнуть в юниформы большой объем данных
3) - по крайней мере на Gl 3 -железе геометрический шейдер не надо использовать для создания большого числа примитивов - будет жутко тормозить
Так что инстансинг очень правильная вещь
Ну и посмотрите все-таки историю NVX_instanced_arrays и его обсуждения на opengl.org - это чистио D3D9-фича и не трубет никакого нового железа, а вот
ARB_draw_instanced как раз требует (собственно и поддерживается начиная с G80)
Steps3D, у вас в вышеупомянутой статье появилась ошибка. Вы поместили вконец статьи как бы описание расширения EXT_texture_buffer_object, но на самом деле это описание ARB_instanced_arrays.
Правилом хорошего тона будет предоставления рядом с термином его англоязычного написания. Например, чтобы анонимусу узнать толкование слова divisor, придётся лезть в словарь. А вот если бы вы написали: "В его основе лежит возможность задания для массива обобщенных вершинных атрибутов, так называемого делителя (divisor)", - было бы понятно. Кстати, зелёную запятую вставьте в свою статью.
Ещё недочёты из статьи выделены красным:
...то это значит, этот атрибут используется при инстансинге.
[Зелёную запятую нужно поставить.]
При выводе instanced-объектов способ, каким атрибуты для очередного экземпляра берутся из вершинного массива, зависит от делителя для заданного массива.
[Уууу, а перефразировать не пробывали? Атрибуты бертся из вершинного массива. Способ, которым осуществляется эта выборка регулируется делителем. Для каждого вершинного массива нужно задавать свой делитель. Как-то так....
Для атрибутов, читаемых из массивовс делителем, равным нулю, каждый инстанс объекта получает свое значение атрибута:
[Во-первых, слова "массивовс" нет. Во-вторых, я, например, не могу понять смысл этого предложения. Прошу вас его перефразировать.]
В вашей статье фигурирует слово "divider". Что это означает? Есть же divisor.
Хочу поделиться опытом. Я много намучался с переводом NVidia стать по псевдо-инстансингу. Вот, кстати, эта статья: http://www.trueimpostors.ucoz.ru/publ/1-1-0-3 Так вот, вы пишите: "то каждому значению этого атрибута соответствует уже не один инстанс объекта, а divider:". Я бы советовал вам не использовать конструкцию "инстанс объекта", а использовать "копия объекта". Смысл в том, что так получается намного понятнее, ИМХО. Теперь переделываем ваше предложение: "то каждому значению этого атрибута соответствует уже не одна копия объекта, а divider:", теперь всплыла на поверхность зыбкость смысла в этом предложении: как объект может соответствовать значению?
II
Теперь мой вопрос. Почему в рисунке №2 divisor равен двум, а не 1 или 3? Почему также в третьем столбце 8 ячеек, когда по логике должно быть 4?
___________________________________________________________________________
Пожалуйста, отвечайте на все вопросы сразу.
Отредактировано DungeonLords (2010-09-05 13:45:04)
Исправлено
Исправлено
Клас! Мы так быстро ещё никогда не срабатывали.
Но нашёл ещё несколько ошибок в статье, связанных с великим и могучим.
данныфх
занчение
Явная опечатка.
"для них делитель равен нулю, и каждый инстанс получает свои значения данного атрибута"
Надо проставить зелёную запятую. Смысл в том, что вышенаписанное предложение сложное.
Ещё у вас в два обзаца подрят начинаются со слов "тем самым", непорядок!
"Тем самым можно избежать чтения данных в вершинном шейдере из текстур/текстурных буферов, и обеспечить каждому инстансу соответствующие ему данные."
Поставьте зелёную запятую.
Отредактировано DungeonLords (2010-09-12 09:33:18)
Спасибо, исправил
Возник практический вопрос. Я рисую дерево (линиями, это нереалистичный рендинг), начальная часть состоит из трех отрезков - ствола, ветки вправо, ветки влево. Все остальные части будут такими же, только масштаб будет меняться. Вопрос: имеет ли смысл мне юзать инстансинг?
Вопрос: имеет ли смысл мне юзать инстансинг?
Имеет смысл писать все в одно VBO. Инстансинг нужен там, где необходимо рендерить большие блоки одинаковой геометрии. Три линии явно не являются большим блоком.
Steps3D,
скачал сегодня заново примеры для данной статьи. Возник провокационный вопрос - в архиве есть файлы di-visitor.cpp и di-visitor.h, а где сам пример по инстансингу через расширение ARB_instanced_arrays?
Вы здесь » Компьютерная графика » Программирование графики и GPU » Обсуждение статьи про расширения EXT_draw_instanced и EXT_texture_buff