Сообщения на форуме пользователя Andrey (41 стр.)
Загрузка уровней | 5 окт. 2010 | 16:14 | #6 |
---|
coordBox
>единственный минус это то что сектор полностью закрытый другим сектором будет также выплюнут в видюху.
Любой иерархический алгоритм имеет данный минус, если нет Occlusion Culling.
>есть возражения?
в Octree есть проблема дробления треугольников.
Но автор так и не ответил для чего собирается строить дерево? для объектов? для геометрии всего уровня? Что из себя представляет уровень? ландшафт + набор мешей(объектов)?
Либо большой единый мешь с 2 миллионами полигонов и 200 текстур? Из этого нужно судить о недостатках Octree или другого алгоритма и структур данных для хранения/отсечения рендеринга.
>единственный минус это то что сектор полностью закрытый другим сектором будет также выплюнут в видюху.
Любой иерархический алгоритм имеет данный минус, если нет Occlusion Culling.
>есть возражения?
в Octree есть проблема дробления треугольников.
Но автор так и не ответил для чего собирается строить дерево? для объектов? для геометрии всего уровня? Что из себя представляет уровень? ландшафт + набор мешей(объектов)?
Либо большой единый мешь с 2 миллионами полигонов и 200 текстур? Из этого нужно судить о недостатках Octree или другого алгоритма и структур данных для хранения/отсечения рендеринга.
Загрузка уровней | 5 окт. 2010 | 14:11 | #1 |
---|
^Kenny^
> допустим в одном узле хранится не более 100 (число можно корректировать)
> треугольников - частей геометрии уровня, которая хранится в VBO по этим зонам.
Это очень мало! Умрет CPU на частых вызовах glDrawElements/DrawIndexedPrimitive/DrawIndexed и т.д. Число полигонов в листе дерева подбирать опытным путем в зависимости от занимаемого визуального объема геометрии и числа полигонов.
>Но тогда проблема с материалами, а именно - частое переключение текстур и установка параметров материала.
>Т.е. вопрос 1: как лучше группировать геометрию и разбивать ее по VBO?
Храни список массивов полигонов для соответствующего материала. При обходе дерева сортируй по материалам группы треугольников, а внутри групп еще можно по расстоянию до камеры. Вершинный и индексный буфер создай один на всю геометрию, если получится конечно, но хотя-бы для каждой большой модели/объекта. Для каждого листа будут просто разные стартовые индексы в пределах буфера.
>И вопрос 2: какие еще алгоритмы можете посоветовать для для обнаружения видимости и отбраковки невидимых частей уровня?
вместо Octree можно KD-tree попробовать.
Да и я так понял тут речь идет о построении дерева по геометрии? У тебя такие сложные и большие модели с разными материалами? Если они маленькие то нету смысла его бить на дерево, ты только загрузишь процессор, возможно сложность моделей можно решить на уровне арта, объединить текстуры например...
Попробуй для начала построить дерево для объектов уровня. Это проще, по крайней мере нету проблемы попадания треугольников в соседние узлы.
> допустим в одном узле хранится не более 100 (число можно корректировать)
> треугольников - частей геометрии уровня, которая хранится в VBO по этим зонам.
Это очень мало! Умрет CPU на частых вызовах glDrawElements/DrawIndexedPrimitive/DrawIndexed и т.д. Число полигонов в листе дерева подбирать опытным путем в зависимости от занимаемого визуального объема геометрии и числа полигонов.
>Но тогда проблема с материалами, а именно - частое переключение текстур и установка параметров материала.
>Т.е. вопрос 1: как лучше группировать геометрию и разбивать ее по VBO?
Храни список массивов полигонов для соответствующего материала. При обходе дерева сортируй по материалам группы треугольников, а внутри групп еще можно по расстоянию до камеры. Вершинный и индексный буфер создай один на всю геометрию, если получится конечно, но хотя-бы для каждой большой модели/объекта. Для каждого листа будут просто разные стартовые индексы в пределах буфера.
>И вопрос 2: какие еще алгоритмы можете посоветовать для для обнаружения видимости и отбраковки невидимых частей уровня?
вместо Octree можно KD-tree попробовать.
Да и я так понял тут речь идет о построении дерева по геометрии? У тебя такие сложные и большие модели с разными материалами? Если они маленькие то нету смысла его бить на дерево, ты только загрузишь процессор, возможно сложность моделей можно решить на уровне арта, объединить текстуры например...
Попробуй для начала построить дерево для объектов уровня. Это проще, по крайней мере нету проблемы попадания треугольников в соседние узлы.
Dragon's Adventure (casual action/adventure) | 4 окт. 2010 | 15:07 | #21 |
---|
Ghost Dragon
как скелетную анимацию делал? свой формат(я не ковырял особо ресурсы) На чем написано? по exe я так и не понял
как скелетную анимацию делал? свой формат(я не ковырял особо ресурсы) На чем написано? по exe я так и не понял
Ландшафт с лодами занимает ну очень много памяти. Что делать? | 4 окт. 2010 | 12:16 | #30 |
---|
arabesc
>> TerrainWidth * (PathWidth + 1) <= 65535
> ерунда какая
> достаточно работать в рамках патча, причём тут размер ландшафта?
Я немного с неравенством ошибся. Исправил пост 21.
Ну вершины же в вершинном буфере хранятся, индексируются от 0 до размера патча. Слева направо, сверху вниз, примерно так, для патча 32x32 и размера ландшафта 1025x1025:
Тут индексы от 0 до 32800 влазим в 16 бит.
Для патча 64x64 уже не влезем в 16 битов. Последний индекс будет 64 * 1025 + 64 > 65535
Каким образом ты предлагаешь организовать вершины в ландшафте что-бы независимо от размера патча и самого ландшафта можно было пользоваться 16-битными индексами?
возможно есть решение, но явно не просто в разгрузке карты из растрового файла и построения вершинного буфера стандартным способом.
>> TerrainWidth * (PathWidth + 1) <= 65535
> ерунда какая
> достаточно работать в рамках патча, причём тут размер ландшафта?
Я немного с неравенством ошибся. Исправил пост 21.
Ну вершины же в вершинном буфере хранятся, индексируются от 0 до размера патча. Слева направо, сверху вниз, примерно так, для патча 32x32 и размера ландшафта 1025x1025:
--------------------------------- 0 1 2... 32... |1024 | 1025 1026 1027... 1056... |2048 | ..... | | 32768...32769....32800 | ---------------------------------
Для патча 64x64 уже не влезем в 16 битов. Последний индекс будет 64 * 1025 + 64 > 65535
Каким образом ты предлагаешь организовать вершины в ландшафте что-бы независимо от размера патча и самого ландшафта можно было пользоваться 16-битными индексами?
возможно есть решение, но явно не просто в разгрузке карты из растрового файла и построения вершинного буфера стандартным способом.
Ландшафт с лодами занимает ну очень много памяти. Что делать? | 4 окт. 2010 | 11:05 | #27 |
---|
Executor
> Отдельными дипами рендеришь "юбочки"?
да. А ты что предлагаешь локать индексный? не будет тут прироста наверное.
innuendo
> молодец... бортики, значит, не понравились :)
Я не знаю про бортики, возможно они лучше или это они и есть.
> Отдельными дипами рендеришь "юбочки"?
да. А ты что предлагаешь локать индексный? не будет тут прироста наверное.
innuendo
> молодец... бортики, значит, не понравились :)
Я не знаю про бортики, возможно они лучше или это они и есть.
Ландшафт с лодами занимает ну очень много памяти. Что делать? | 4 окт. 2010 | 10:53 | #24 |
---|
innuendo
вроде это "юбочка" Скоро будет демка.
вроде это "юбочка" Скоро будет демка.
Практическое использование расширений: анизотропная фильтрация в OpenGL (комментарии) | 4 окт. 2010 | 10:20 | #44 |
---|
YarUnderoaker
Тестировал анизотропную на ATI X700 и nVidia 7600 GT В обоих случаях качество лучше с анизотропной на наклонных поверхностях. Ты делаешь что-то неправильно.
Тестировал анизотропную на ATI X700 и nVidia 7600 GT В обоих случаях качество лучше с анизотропной на наклонных поверхностях. Ты делаешь что-то неправильно.
Ландшафт с лодами занимает ну очень много памяти. Что делать? | 4 окт. 2010 | 10:16 | #21 |
---|
Sergio
>По правде сказать я пытался так уже делать, но не очень правильно и ничего не получилось. Буду пробовать заново
На бумаге разрисуй индексы и все поймешь. Не забывай про выполнение условия выхода за пределы 16-битных индексов:
TerrainWidth * (PathWidth + 1) <= 65535
Executor
>Разговор ведь о том как отрендерить затратив меньше ресурсов...
как раз VTF и GL3 это затраты ресурсов. Или GL_ARB_draw_elements_base_vertex будет быстрее чем VBO + смещение вершин??? Не верю, может быть удобно, да но это не тот случай что-бы поддерживать 2 ветви кода от рисовки геометрии. VTF будет наверняка медленней, сложнее реализация. А карты ATI X1950XT и NVidia 7800 GT есть еще у многих.
>По правде сказать я пытался так уже делать, но не очень правильно и ничего не получилось. Буду пробовать заново
На бумаге разрисуй индексы и все поймешь. Не забывай про выполнение условия выхода за пределы 16-битных индексов:
TerrainWidth * PathWidth + PathWidth < 65536
>Разговор ведь о том как отрендерить затратив меньше ресурсов...
как раз VTF и GL3 это затраты ресурсов. Или GL_ARB_draw_elements_base_vertex будет быстрее чем VBO + смещение вершин??? Не верю, может быть удобно, да но это не тот случай что-бы поддерживать 2 ветви кода от рисовки геометрии. VTF будет наверняка медленней, сложнее реализация. А карты ATI X1950XT и NVidia 7800 GT есть еще у многих.
Правка. Неверное неравенство.
Правка: 4 окт. 2010 12:00
Ландшафт с лодами занимает ну очень много памяти. Что делать? | 3 окт. 2010 | 19:56 | #15 |
---|
Executor
>Чтобы не парится с расширениями...
Какая запарка, тут одного VBO c головой хватит.
>Чтобы имея одну сетку 64х64 отрендерить весь ландшафт... А если ещё инстансинг прикрутить, то ваще лялька будет...
Ну круто ландшафт для видео карт ATI <=X1950XT не будет работать :) Зато будет модный VTF, как-же без этого.
какой инстансинг??? для 50 патчей??? тормозить еще больше будет.
>Чтобы не парится с расширениями...
Какая запарка, тут одного VBO c головой хватит.
>Чтобы имея одну сетку 64х64 отрендерить весь ландшафт... А если ещё инстансинг прикрутить, то ваще лялька будет...
Ну круто ландшафт для видео карт ATI <=X1950XT не будет работать :) Зато будет модный VTF, как-же без этого.
какой инстансинг??? для 50 патчей??? тормозить еще больше будет.
Ландшафт с лодами занимает ну очень много памяти. Что делать? | 3 окт. 2010 | 13:33 | #9 |
---|
Sergio
> Надо будет проверить. Про указатели в xxxPointer я как-то не подумал, спасибо.
Да сравни скорость кстати. Интересно самому если что подключу расширение это....
> Надо будет проверить. Про указатели в xxxPointer я как-то не подумал, спасибо.
Да сравни скорость кстати. Интересно самому если что подключу расширение это....
Ландшафт с лодами занимает ну очень много памяти. Что делать? | 3 окт. 2010 | 13:12 | #7 |
---|
Sergio
Я делал используя glDrawElements. Смещение ставится в glVertexPointer, glNormalPointer, glTexCoordPointer, glVertexAttribPointer последних параметрах.
> это и есть DrawElementsBaseVertex?
это ты уже почитай поподробнее про GL_ARB_draw_elements_base_vertex.
Кстати с ним будет быстрей рисоваться или это просто для удобства сделали?...
Я делал используя glDrawElements. Смещение ставится в glVertexPointer, glNormalPointer, glTexCoordPointer, glVertexAttribPointer последних параметрах.
> это и есть DrawElementsBaseVertex?
это ты уже почитай поподробнее про GL_ARB_draw_elements_base_vertex.
Кстати с ним будет быстрей рисоваться или это просто для удобства сделали?...
Dragon's Adventure (casual action/adventure) | 3 окт. 2010 | 12:36 | #18 |
---|
Ghost Dragon
Очень Круто! сделай тени от остальных объектов. Есть ошибка когда дракон под корягой идет то тень на верху коряги, а не на земле.
Очень Круто! сделай тени от остальных объектов. Есть ошибка когда дракон под корягой идет то тень на верху коряги, а не на земле.
Ландшафт с лодами занимает ну очень много памяти. Что делать? | 3 окт. 2010 | 12:33 | #3 |
---|
Sergio
>индексный буфер ландашфта 1025х1025 занимает около 200Мб в памяти (если не больше).
Нафиг тебе 32-битные индексы??? поэтому и размер большой.
Используй единую комбинацию буферов и буфер для 0 лода для части ландшафта с 16-битными индексами, а рисовать части нужно со смещением вершин в вершинном буфере.
У меня так работает с 16 битными буферами + смещение в вершинном(правда сшиваю дырки не комбинацией).
Executor
Нафиг тут GL3 ? зачем тут VTF еще ?
>индексный буфер ландашфта 1025х1025 занимает около 200Мб в памяти (если не больше).
Нафиг тебе 32-битные индексы??? поэтому и размер большой.
Используй единую комбинацию буферов и буфер для 0 лода для части ландшафта с 16-битными индексами, а рисовать части нужно со смещением вершин в вершинном буфере.
У меня так работает с 16 битными буферами + смещение в вершинном(правда сшиваю дырки не комбинацией).
Executor
Нафиг тут GL3 ? зачем тут VTF еще ?
Раскрытие циклов в Cg | 28 сен. 2010 | 13:24 | #43 |
---|
innuendo
нет не про параметры. Внутри dll тормоза.
http://developer.nvidia.com/forums/index.php?showtopic=4598&s… p;#entry13741
http://developer.nvidia.com/forums/index.php?showtopic=4236
http://developer.nvidia.com/forums/index.php?showtopic=5145
http://developer.nvidia.com/forums/index.php?showtopic=3755
нет не про параметры. Внутри dll тормоза.
http://developer.nvidia.com/forums/index.php?showtopic=4598&s… p;#entry13741
http://developer.nvidia.com/forums/index.php?showtopic=4236
http://developer.nvidia.com/forums/index.php?showtopic=5145
http://developer.nvidia.com/forums/index.php?showtopic=3755
Как определить колчество элементов массиве по указателю? | 27 сен. 2010 | 15:26 | #30 |
---|
KpeHDeJIb
> malloc_usable_size
о! возьму на заметку
> malloc_usable_size
о! возьму на заметку