Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Frustum Culling (комментарии)

Frustum Culling (комментарии)

Поделиться
Страницы: 1 2 3 4 5 Следующая »
_Wizard_Участникwww10 фев. 20175:49#0
Frustum Culling (комментарии)
Это сообщение сгенерировано автоматически.
HplusDieseПостоялецwww10 фев. 20175:49#1
Почему transform feedback, а не compute shaders? Может быстрее выйдет.
MiraПостоялецwww10 фев. 20177:32#2
Нового не нашел,  но статейка хорошая.  Раньше бы сократила время.
bykabakПостоялецwww10 фев. 20179:27#3
Отличная статья. Благодарю.

Отдельная благодарность за ссылки по теме после статьи.

Правка: 10 фев. 2017 9:29

_Wizard_Участникwww10 фев. 201711:09#4
Mira
bykabak
>Отличная статья. Благодарю.
спасибо

HplusDiese
>Почему transform feedback, а не compute shaders? Может быстрее выйдет.
не думаю, что быстрее через compute. Проверять надо.
transform feedback - DX10 железо, compute shaders - DX11 железо.
Да и смысл был - просто показать что на GPU делать кулинг - быстро + есть плюшки в виде Hierarchical-Z map based occlusion кулинга.
Хочу еще раз заметить что кулится 100к объектов! Это надо ОЧЕНЬ постараться чтобы в сцене (вокруг игрока) столько было.
Мелкие объекты просто выбрасываются, если далеко от игрока - их кулить не надо. Так что 100к объектов - это овер дофига.

Правка: 10 фев. 2017 11:10

bykabakПостоялецwww10 фев. 201712:15#5
А возможно расписать в подробностях как формируются frustum_planes ?  ( этого в статье нет )

Правка: 10 фев. 2017 12:17

foxesПостоялецwww10 фев. 201712:23#6
_Wizard_
> не думаю, что быстрее через compute. Проверять надо.
Если организовать объекты не в виде точек, а как матрицы используемые уже для отрисовки самих объектов то плюс не придется лишний комит делать для точек.
SSE                  1,2  1,45  4,63
SSE, multithreading  1,18  1,2  2,02
GPU                  1,19
Получается если на SSE считать, то для GPU как раз всю производительность сожрет обмен данных.
Дополнительно если использовать физику/анимацию на GPU, то есть расчет матриц, то их не придется все время туда постить.

Кстати, из геометрического шейдера результат можно прочитать назад в CPU?
Меня интересовал вопрос передачи результата работы или отдельный пользовательский буфер геометрического шейдера одного объекта в другой. Чтобы побочные промежуточные результаты расчета для отрисовки можно было потом использовать и не считать заново.

Правка: 10 фев. 2017 12:33

MiraПостоялецwww10 фев. 201712:27#7
Тоже хочу поиграться с gpgpu  или на шейдере сделать.  Simd дает вкусные результаты,  а это в теории должно еще больше дать.
_Wizard_Участникwww10 фев. 201713:37#8
bykabak
>А возможно расписать в подробностях как формируются frustum_planes ? ( этого в статье нет )
в конце статьи можно скачать полный код всех примеров - там есть

foxes
>Получается если на SSE считать, то для GPU как раз всю производительность сожрет обмен данных.
>Дополнительно если использовать физику/анимацию на GPU, то есть расчет матриц, то их не придется все время туда постить.
да, когда на цпу считаешь, нужно передавать данные по шине
единственно - ты передаешь информацию только видимых инстансов

>Кстати, из геометрического шейдера результат можно прочитать назад в CPU?
на количество сгенерированных инстансов - делается запрос
//get feedback from prev frame
  num_visible_instances = 0;
  glGetQueryObjectiv(num_visible_instances_query[prev_frame], GL_QUERY_RESULT, &num_visible_instances);
сами данные ВИДИМЫХ инстансов пишутся в отдельный буфер (dips_texture_buffer), если их хочется получить - нужно лочить буфер... но не надо этого делать (лучше все на стороне гпу считать)

+DX11 железа в том, что можно использовать DrawIndirect... т.е. не нужно даже считывать количество сгенерированных инстансов на цпу - информацию о дипе можно сформировать на стороне гпу

foxesПостоялецwww10 фев. 201713:46#9
_Wizard_
> +DX11 железа в том, что можно использовать DrawIndirect... т.е. не нужно даже
> считывать количество сгенерированных инстансов на цпу - информацию о дипе можно
> сформировать на стороне гпу
Да я сейчас так и делаю, но конкретно в своей задаче уперся в лимит [maxvertexcount(192)] на один поток, и приходится решение делать через повторение отрисовки одного и того же объекта с входными данными от предыдущей итерации, поэтому перенес все из геометрического шейдера в расчетный. Я стек рекурсии перенес на расчет в ширину, где каждый триангл это отдельная колонка (глубина) рекурсии. Как вариант ручной и достаточно глубокой тесселяции. Где стандартная тесселяция делает детализацию не более чем на 3 уровня - это как раз равно лимиту выходного maxvertexcount (DIVIDED_PARTS_COUNT^(3)*VERTEX_COUNT_PER_TRIANGLE=192) для одного прохода в геометрическом шейдере.

Правка: 10 фев. 2017 14:08

_Wizard_Участникwww10 фев. 201714:20#10
foxes
не очень может понял - ты делаешь тесселяцию на геометрических шейдерах / компуте?
не делай так)
есть специальные стадии конвеера/шейдера где это делается
foxesПостоялецwww10 фев. 201714:37#11
_Wizard_
> есть специальные стадии конвеера/шейдера где это делается
Да, но глубина и результат в целом меня не удовлетворил, поэтому перенес на Compute. На самом деле очень быстро работает я вообще не вижу проседаний в FPS в сравнении с соответствующими стадиями шейдера. Примера как на обычной тесселяции сделать 16 делений в глубину (на каждом триангл делиться на 4) я не нашел максимум 3, и FPS уже очень проседает.

Правка: 10 фев. 2017 14:38

BaveПостоялецwww13 фев. 201716:41#12
Как то прифигел от цифр:
Только кулинг  0,92
Весь кадр 1,94

для решения на cpu для 100к объектов это как то слишком офигенно....
——

не думаю, что быстрее через compute. Проверять надо.

У нас вот свой движок и весь scene graph на compute stage (там не только frustum culling).

Так вот у нас на 10к объектах вычислительная часть выполняется за 1.3 ms - это время в себя включает обновление world-матриц (ессесвено по необходимости, но в данном замере обновлялись все 10к) + сам frustum culling (у нас OBB) + всякие служебные операции (мы на выходе вычислительной части получаем готовые буферы для Multi draw indirect команд) + синхронизация (тоже вся на gpu, с host-ом синхронизации нет).

1.3 ms  - это у меня получается на GTX 750-ой (проц не привожу, так на нем у нас ничего не делается кроме запекания pipeline-ов).

Для сравнения своего результата я брал Ogre-вский octree scene manager - он на той же самой сцене (10k объектов) выдает over 16 ms и до того как я прочитал эту статью, я думал, что у меня все хорошо...

Пойду застрелюсь....

Правка: 13 фев. 2017 16:57

innuendoПостоялецwww13 фев. 201716:58#13
Bave
> Пойду застрелюсь....

Уточните место работы

StiXУдалёнwww13 фев. 201717:44#14
Страницы: 1 2 3 4 5 Следующая »

/ Форум / Программирование игр / Общее

2001—2017 © GameDev.ru — Разработка игр