Сообщения на форуме пользователя Andrey (20 стр.)
OpenGL передача массива в фрагментный шейдер | 29 мая 2012 | 16:14 | #13 |
---|
ontario83
> Как объявить тело блока в шейдере и как его адресовать для вышеупомянутого
> примера (пусть даже с float), чтобы std140 запаковался без дырок и чтобы
> достучаться до любого элемента массива - можешь дать образец кода?
Я не понял до конца задачу, что такое ID тайла у тебя ? размер ID == int ? Как связан ID тайла с числами 1680 на 1050 из 1 поста?
без дырок нужно объявить:
layout (std140) uniform myblock
{
int myarray[7104];
};
> Как объявить тело блока в шейдере и как его адресовать для вышеупомянутого
> примера (пусть даже с float), чтобы std140 запаковался без дырок и чтобы
> достучаться до любого элемента массива - можешь дать образец кода?
Я не понял до конца задачу, что такое ID тайла у тебя ? размер ID == int ? Как связан ID тайла с числами 1680 на 1050 из 1 поста?
без дырок нужно объявить:
layout (std140) uniform myblock
{
int myarray[7104];
};
Велосипедный вектор | 29 мая 2012 | 10:59 | #14 |
---|
Pokimon
> Ведь в итоге получится непереносимая куча кода.
> Оно вам надо?
можешь рассказать что будет непереносимо?
> Ведь в итоге получится непереносимая куча кода.
> Оно вам надо?
можешь рассказать что будет непереносимо?
OpenGL передача массива в фрагментный шейдер | 29 мая 2012 | 10:56 | #9 |
---|
ontario83
В общем тебе нужно все данные привести к float. Потом просто в шейдере по нужным индексам получаешь смещение в общем массиве, через индексы кастуешь к нужному типу, если нужно.
Что-бы не было дырок, объединяй плотно упакованные данные вместе, к примеру vec4, ma4, 4 x vec3, 2 x vec2 и т,д. Дырок возможно всех не избежать, просто в конце массива будет float, vec2 или vec3, т.е. 1 дырка.
Не вижу больше решения. Если не получается, приведи конкретный пример с твоими данными, что в С++ хранится и что делает шейдер.
Anika
> Для использования UBO uniform блоки обязательно именованные делать или можно к неименованному обращаться, если он один всего ?
Не знаю насчет не именованного, если он один то его handle по идее равен нулю. По крайней мере у меня во всех шейдерах.
В общем тебе нужно все данные привести к float. Потом просто в шейдере по нужным индексам получаешь смещение в общем массиве, через индексы кастуешь к нужному типу, если нужно.
Что-бы не было дырок, объединяй плотно упакованные данные вместе, к примеру vec4, ma4, 4 x vec3, 2 x vec2 и т,д. Дырок возможно всех не избежать, просто в конце массива будет float, vec2 или vec3, т.е. 1 дырка.
Не вижу больше решения. Если не получается, приведи конкретный пример с твоими данными, что в С++ хранится и что делает шейдер.
Anika
> Для использования UBO uniform блоки обязательно именованные делать или можно к неименованному обращаться, если он один всего ?
Не знаю насчет не именованного, если он один то его handle по идее равен нулю. По крайней мере у меня во всех шейдерах.
OpenGL передача массива в фрагментный шейдер | 28 мая 2012 | 21:31 | #5 |
---|
ontario83
> Как объявить массив в блоке, чтобы было без дырок? В голову приходит тот-же
> ivec4, но как тогда напрямую индексировать его одной переменной?
откуда индексировать ? из glsl или C++ ? приведи пример.
> Как объявить массив в блоке, чтобы было без дырок? В голову приходит тот-же
> ivec4, но как тогда напрямую индексировать его одной переменной?
откуда индексировать ? из glsl или C++ ? приведи пример.
Проблема с текстурированием ландшафта [OpenGL] | 28 мая 2012 | 21:27 | #8 |
---|
monogrind
m_VertexBuffer, m_IndexBuffer отдельный для каждого куска?
по идее индексный может быть одинаковый.
> вызывать glGetError(), я надеюсь это не убьет производительность?
>program->getAttributeId("attr_v3Position")
вот это наверное больше заберет производительности, найдешь ошибку уберешь.
m_VertexBuffer, m_IndexBuffer отдельный для каждого куска?
по идее индексный может быть одинаковый.
> вызывать glGetError(), я надеюсь это не убьет производительность?
>program->getAttributeId("attr_v3Position")
вот это наверное больше заберет производительности, найдешь ошибку уберешь.
OpenGL передача массива в фрагментный шейдер | 28 мая 2012 | 18:45 | #1 |
---|
ontario83
> Отсюда вопрос - действительно ли при попытке передать простейший массив
> скаляров 3/4 памяти уходит в никуда?
получается да.
> Если это так, то как сохранить: а) совместимость (std140);
> b) производительность UBO без тормоза распаковок
пересмотри формат хранения констант что-бы все лежало плотно в памяти без дырок.
>c) не выйти за лимит размера блока?
разбить на несколько UBO блоков и слать за несколько вызовов glBufferData(GL_UNIFORM_BUFFER, ... ?
> Отсюда вопрос - действительно ли при попытке передать простейший массив
> скаляров 3/4 памяти уходит в никуда?
получается да.
> Если это так, то как сохранить: а) совместимость (std140);
> b) производительность UBO без тормоза распаковок
пересмотри формат хранения констант что-бы все лежало плотно в памяти без дырок.
>c) не выйти за лимит размера блока?
разбить на несколько UBO блоков и слать за несколько вызовов glBufferData(GL_UNIFORM_BUFFER, ... ?
Проблема с текстурированием ландшафта [OpenGL] | 28 мая 2012 | 18:41 | #6 |
---|
monogrind
> Пытаюсь сделать ландшафт на основе quadtree. Появилась небольшая проблема с текстурированием.
> На первые пару нодов текстуры накладываются нормально, но когда этих нодов
> становится больше, допустим 30, то они начинают исчезать и не рисоваться
> совсем. Пробовал использовать не генерированную текстуру а обычную - тот же эффект.
Ошибка в реализации Quadtree. Ну точно подтверждается что используешь обычную текстуру. т.е. и FBO тут не причем, тем более переключение текстур. Посмотри внимательнее что передаешь в glDrawElement/glDrawRangeElements. Как рисуешь? какие индексы GL_UNSIGNED_SHORT ?
При отрисовке делаешь смещением индексов или вершин? может используешь GL_ARB_base_vertex_index и там что-то не так?
> Пытаюсь сделать ландшафт на основе quadtree. Появилась небольшая проблема с текстурированием.
> На первые пару нодов текстуры накладываются нормально, но когда этих нодов
> становится больше, допустим 30, то они начинают исчезать и не рисоваться
> совсем. Пробовал использовать не генерированную текстуру а обычную - тот же эффект.
Ошибка в реализации Quadtree. Ну точно подтверждается что используешь обычную текстуру. т.е. и FBO тут не причем, тем более переключение текстур. Посмотри внимательнее что передаешь в glDrawElement/glDrawRangeElements. Как рисуешь? какие индексы GL_UNSIGNED_SHORT ?
При отрисовке делаешь смещением индексов или вершин? может используешь GL_ARB_base_vertex_index и там что-то не так?
Матрицы в разных приложениях (OpenGL) | 25 мая 2012 | 14:04 | #2 |
---|
nXs
Найди исходники glRotate и посмотри что не так. Например тут http://www.koders.com/c/fid5FA988C762FD9E5E1E8F657FE4CA862ABF2400EE.aspx
Ну придется разбираться с языком C.
Найди исходники glRotate и посмотри что не так. Например тут http://www.koders.com/c/fid5FA988C762FD9E5E1E8F657FE4CA862ABF2400EE.aspx
Ну придется разбираться с языком C.
OpenGL 4.2 | 22 мая 2012 | 10:21 | #43 |
---|
innuendo
> а они нужны ?
странный вопрос, какая разница нужны или нет? решили так разработать API c загрузкой только 2 матриц
> а они нужны ?
странный вопрос, какая разница нужны или нет? решили так разработать API c загрузкой только 2 матриц
OpenGL 4.2 | 22 мая 2012 | 10:05 | #41 |
---|
=A=L=X=
> В OGL нет World. А "model view" это одно понятие, а не два.
точнее не понятие, в OpenGL "model view" это modelMatrix * ViewMatrix, в FFP нету констант для загрузки одной ModelMatrix через функцию glLoadMatrix*, а только результат перемножения.
modelMarix она-же World Matrix для Direct3D.
> В OGL нет World. А "model view" это одно понятие, а не два.
точнее не понятие, в OpenGL "model view" это modelMatrix * ViewMatrix, в FFP нету констант для загрузки одной ModelMatrix через функцию glLoadMatrix*, а только результат перемножения.
modelMarix она-же World Matrix для Direct3D.
SwapBuffer(hdc); кушает память | 18 мая 2012 | 17:59 | #24 |
---|
programina
> Мне кажется, что дело или в CodeBlocks
Собери в Visual C++, или OpenWatcom
> Мне кажется, что дело или в CodeBlocks
Собери в Visual C++, или OpenWatcom
Тормозит D3DXSaveSurfaceToFileInMemory | 18 мая 2012 | 17:36 | #1 |
---|
3D-GRAF
>Проблема в том, что строчка D3DXSaveSurfaceToFileInMemory вызывает ощутимое подвисание даже на очень сильных системах, не говоря уже о слабых.
Может связано с временем необходимым для сжатия в jpg формат, ну и разрешение высокое. Попробуй bmp, tga, png. Хотя тут большая часть времени может занимать запись на диск.
>Хотя аналогичная функция во всем известной программе Fraps вообще не ощущается, по крайней мере на моем компьютере.
в Fraps наверняка заводится буфер, в отдельном потоке или асинхронно пишут на диск.
>Пробовал выносить D3DXSaveSurfaceToFileInMemory в отдельный поток - подвисания пропали, но на некоторых системах видимо не успевает обработаться до следующего кадра и в итоге на >скриншоте получается не до конца отрендеренное изображение.
странно у тебя-же синхронная операция.
>Проблема в том, что строчка D3DXSaveSurfaceToFileInMemory вызывает ощутимое подвисание даже на очень сильных системах, не говоря уже о слабых.
Может связано с временем необходимым для сжатия в jpg формат, ну и разрешение высокое. Попробуй bmp, tga, png. Хотя тут большая часть времени может занимать запись на диск.
>Хотя аналогичная функция во всем известной программе Fraps вообще не ощущается, по крайней мере на моем компьютере.
в Fraps наверняка заводится буфер, в отдельном потоке или асинхронно пишут на диск.
>Пробовал выносить D3DXSaveSurfaceToFileInMemory в отдельный поток - подвисания пропали, но на некоторых системах видимо не успевает обработаться до следующего кадра и в итоге на >скриншоте получается не до конца отрендеренное изображение.
странно у тебя-же синхронная операция.
SwapBuffer(hdc); кушает память | 18 мая 2012 | 17:14 | #11 |
---|
programina
> /* render */
А тут есть что нибудь? или там действительно коменты?
> /* render */
А тут есть что нибудь? или там действительно коменты?
Быстрое отображение множества спрайтов поверх основной сцены | 14 мая 2012 | 16:08 | #14 |
---|
bugman
>4. Если в результате 3-я ячейка результирующего массива ненулевая, то продолжаем
делай проверку видимости спрайта, тогда этот пункт можно возможно пропустить, упростив функцию преобразования координат.
> шустро отображаются 10000 квадратов
Пересчет, а не отображение.
>4. Если в результате 3-я ячейка результирующего массива ненулевая, то продолжаем
делай проверку видимости спрайта, тогда этот пункт можно возможно пропустить, упростив функцию преобразования координат.
> шустро отображаются 10000 квадратов
Пересчет, а не отображение.
Быстрое отображение множества спрайтов поверх основной сцены | 14 мая 2012 | 14:10 | #11 |
---|
bugman
> Хочешь сказать, сокращение одного умножения матриц настолько в разы увеличивает
> перфоманс?
ну 2000 перемножений 2 матриц. Я не гарантирую что в разы, но зачем постоянно перемножать 2 константные величины что-бы получить третью, да еще в цикле?
Ты попробуй может будет быстрее, лишнее перемножение 2 матриц сразу в глаза бросается. Можно попробовать еще отсекать значки которые перекрывают другие если это возможно
bugman
> > В твоём случае можно совместить преобразование из мировой системы координат в
> > экранные с матрицей проекции, т.е. объединить в одну матрицу, которую
> > использовать
> > как матрицу проекции, и вызывать GLUproject станет больше не нужно.
> Не совсем понял идеи
Ну по сути что и я говорил про матрицы.
> Хочешь сказать, сокращение одного умножения матриц настолько в разы увеличивает
> перфоманс?
ну 2000 перемножений 2 матриц. Я не гарантирую что в разы, но зачем постоянно перемножать 2 константные величины что-бы получить третью, да еще в цикле?
Ты попробуй может будет быстрее, лишнее перемножение 2 матриц сразу в глаза бросается. Можно попробовать еще отсекать значки которые перекрывают другие если это возможно
bugman
> > В твоём случае можно совместить преобразование из мировой системы координат в
> > экранные с матрицей проекции, т.е. объединить в одну матрицу, которую
> > использовать
> > как матрицу проекции, и вызывать GLUproject станет больше не нужно.
> Не совсем понял идеи
Ну по сути что и я говорил про матрицы.