Войти
ФлеймФорумОбщее

Пароль на архиве с исходниками Game7? (6 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#75
10:57, 31 мар. 2005

Fly
Спасибо, что ответил.

>уменьшив объекты (разбив на несколько батчей), можно добиться, например, что на объект будет действовать 1 источник света вместо 2-х
Это понятно, но я не нашёл в сырцах вообще исключения из обработки источников света, которые не влияют на выводимый меш. Плохо искал?
И, имхо, т.к. в игре радиус действия источников очень мал, лучше освещать геометрию каждым источником в отдельный проход. И для маленьких источников будет выводиться пара объектов. Хотя это бред, наверное.
>Видюху мы тем самым не разгрузим.
Видюху то разгрузим. Вопрос в другом. Насколько, и что это даст.
>Известный факт: чем больше батчей, тем сильнее нагружается процессор.
Это понятно. Но я не предлагаю увеличить число объектов (точнее вначале предлагал), а лишь разбить существующие статичные объекты ... напр. на 4 части. Вон, в RenderDX9::Draw какая чёртова уйма всего, сколько стейтов устанавливается (нельзя это вынести в главный цикл?) и только один вызов DrawPrimitives в конце. А так будет не один вызов, а четыре проверки видимости BBOX-ов подобъектов, составляющих объект и от одного до двух! вызовов DrawIndexedPrimitive(D3DPT_TRIANGLELIST,...). Это не так уж и страшно.
>И вообще о каком увеличении кол-ва батчей может идти речь, если игра у нас CPU limited?
Как это CPU ltd. ? Не может быть. Всего ~60 батчей, простейшая физика и AI.
Очевидно, что ограниченность CPU/GPU определяется исходя из конфига тестовой системы. На каких системах вы тестили игру? И на всех CPU limited?
Вообще может быть несколько ситуаций. Напр:
Изображение удалено
В этом случае вначале каждого кадра CPU выполняет начальный код (в том числе, как в Game7, обходит дерево и формирует список видимых объектов) -- это отмечено светло-зелёной зоной. GPU в этот момент простаивает (синяя зона).
Далее (зелёная зона), идут батчи, CPU их выполняет быстрее GPU, но последняя красная зона (расчёт физики, AI и всякая всячина) делает игру CPU bounded, т.к. до выполнения процессором всех расчётов, GPU свою работу уже закончил.

Возможен и другой случай:
Изображение удалено
Здесь, для примера, 3 батча. Вначале идёт начальный код (светло-зел. зона), затем первый батч (зел.), и когда его выполнение завершится, GPU начинает отрисовку геометрии. Так идут ещё 2 батча (хотя батч здесь -- условность, там может быть очень много смен стейтов и вызовов API функций). GPU тут отрисовывает батч быстрее, чем CPU подготавливает следующий. И в итоге красная зона -- физика и AI.

В обоих случая действительно смысла увеличивать батчи нет, но в первом случае оптимизировать надо преимущественно физику, а во втором -- батчи (уменьшать их число).
Вообще-то, по идее, подобные диаграммы должен строить сам движок. Т.е. замерять время каждой зоны (зоны выделяются заранее) и проверять загруженность GPU, напр., с помощью GL_NV_fence, постоянно (достаточно часто) вызывая TestFenceNV() например. Тогда будет сразу понятно, что тормозит процесс и насколько. Само понятие "CPU limited" не является ёмким и надо проводить кучу дополнительных тестов.


Mikle
>повысит кол-во переключений стейтов,
Хм. Как это повысит? Ведь стейты для каждого материала при рендеринге всех мешей из него будут устанавливаться только один раз.


#76
12:23, 31 мар. 2005

tav
Игра CPU limited даже на серьезном P4. Там очень сложная скелетная анимация, это во-первых (совсем не для скроллера, одна водомерка костей 25). К тому же хреновый collision detection. Ну и еще ряд проблем есть. Как это все будет исправлено, и игра станет GPU limited (а она, поверь, ей не станет при таких простых шейдерах ;-) ), то можно думать как бы нагрузить проц, чтобы разгрузить видюху.

#77
12:58, 31 мар. 2005

Fly
>одна водомерка костей 25
?????
Может лучше расчитать кадры при загрузке моделей (24 в сек.) и использовать для анимации морфинг?
Зачем там скел. анимация для водомерок и прочей мелочи? Сколько в той же водомерке поли?

#78
13:16, 31 мар. 2005

tav
1. жаба - hi poly вообще. Какие тут кадры :))
2. Жук - пара десятков качественных анимаций + IK. Ок жрет дофига процессорного времени.
3. Я умею писать только 3D шутеры со всеми вытекающими последствиями :) И этот движок писался и пишется для шутера.
4. Твое предложение если только для водомерок подходит и то с большим напрягом. Проще уменьшить кол-во костей в ней. Но будет некрасиво.

#79
13:22, 31 мар. 2005

tav
Обычно, любые оптимизации начинаются с самых простых и очевидных вещей. Так вот, как верно заметил Флай, в текущей версии жука проще начать оптимизировать что-то, что реализовно либо плохо, либо не эффективно. То, что предлагаешь оптимизировать ты, в жуке реализовано далеко не плохо, и, главное, дальнейшие оптимизации не приведут к качественному росту производительности.
Потом морфирование сложно переложить на GPU. А кости (правда я не уверен, что это действительно так, я не отслеживаю код) реализованы так, что они используют GPU. Плюсы использовния GPU для скелетной анимации очевидны (иначе бы никто не стал заморачиваться и делать поддержку в железе). Так что ты не в ту сторону копаешь :)

#80
14:06, 31 мар. 2005

tav
Я имел ввиду увеличение переключений стейтов, если не использовать очередь.

#81
2:03, 1 апр. 2005

Fly
>жаба - hi poly вообще. Какие тут кадры :))
Ну если лоуполи уже 2000 :-) , то hi -- тысяч 10 минимум. Я прав?
>Какие тут кадры
Обычные кадры такие. Предположим там 3 секунды анимации, и кадров будет 12 в сек (с интерполяцией сойдёт).
Получаем на жабу памяти нужно 3*12*10000*12байт=4.3 Мб.
Это много? А если хранить с игрой и загружать в ОЗУ модели в виде костей, их анимаций, веса вершин и т.д. для всех тварей игры. И поочерёдно загружать в видеопамять покадровую анимацию только тех моделей которые могут быть потенциально видны. Ведь у вас в конце не все же твари на одном экране могут появляться (я правда игру не прошёл).
Т.е. по ходу игры, можно предварительно рассчитывать кадры анимации для твари которая появится следующей, просчитывая на CPU для неё один кадр анимации в 1 секунду, напр.

Так если Zulus говорит, что скел. анимация на GPU, то... что там тормозит то? Почему CPU limited?

Zulus
>Так вот, как верно заметил Флай, в текущей версии жука проще начать оптимизировать что-то, что реализовно либо плохо, либо не эффективно
Я всё-таки так и не понял, что там реализовано плохо или неэффективно. Физика? IK для жука? И всё?
>Потом морфирование сложно переложить на GPU
Да это элементарно, в принципе. Кадры в буфере последовательно положить, один за другим, и при выводе модели с интерполяцией между соседними кадрами (а можно и несоседними), на первый кадр указывает указатель вершин, а на второй -- атрибутов (с размерностью вершин) и в uniform коэффициент интерполяции, простейший верш. шейдер.

Mikle
>Я имел ввиду увеличение переключений стейтов, если не использовать очередь.
Хм. Какое увеличение?
Вот есть 5 материалов. И 5 octree (5 измерений). Деревья, в принципе разные (у каждого может не быть каких-то пустых поддеревьев, не содержащих тр-ки, если их отбрасывать при построении дерева).
Ставим стейты для первого материала. Обходим 1-е дерево и рисуем тр-ки. Никаких доп. переключений стейтов. Ставим стейты для 2-го материала. Обходим 2-е дерево и т.д. Каждый материал ставится ровно один раз.
Ну, ещё можно учесть ситуации, когда видны будут тр-ки не из всех материалов (т.е. тр-ки из какого-либо материала/-ов вообще не видны). Тогда просто надо ввести один флаг. Перед каждым обходом дерева сбрасывать его, а при обходе как только нашли видимый лист с тр-ками проверяем, установлен ли флаг. Если флаг сброшен, то ставим стейты материала (перед обходом дерева очередного материала делать это не нужно) и устанавливаем флаг.

#82
10:49, 1 апр. 2005

tav
>Да это элементарно, в принципе. Кадры в буфере последовательно положить, один
>за другим, и при выводе модели с интерполяцией между соседними кадрами (а можно
>и несоседними), на первый кадр указывает указатель вершин, а на второй --
>атрибутов (с размерностью вершин) и в uniform коэффициент интерполяции,
>простейший верш. шейдер.

Прикинь, 50 водомерок на костях (используя только один меш, как основу в видеопамяти) и 50 твоих вариаций прокачать по шине :) Думаю тут тебе нечего будет возразить.

#83
11:14, 1 апр. 2005

tav
"Вот есть 5 материалов. И 5 octree (5 измерений)."
Нет. Это одно измерение (материалы), плюс еще три (X,Y,Z). Причем мы не делаем между ними разницы, и поэтому получаем вместо октри хекстри (2^4=16). Я имел ввиду это. Так мы сильно увеличиваем число переключений, ЕСЛИ НЕ ИСПОЛЬЗУЕМ НИКАКОЙ ПОСЛЕДУЮЩЕЙ ОПТИМИЗАЦИИ, например очередь по материалам.

А тормозит там ужасно тупой, неоптимизированный и ламерский код из HL2 :)

#84
12:01, 1 апр. 2005

tav
По моим расчетом жаба будет занимать 15 мегов со всеми анимациями. 30 fps (даже 15 мало!!) и 5 анимаций. 10 монстров - 150 мегов. А еще супер монстры и жук.

А тормозят в скелетной анимации тысячи умножений матрицы на матрицу.

#85
12:14, 1 апр. 2005

Zulus
>Прикинь, 50 водомерок на костях (используя только один меш, как основу в видеопамяти) и 50 твоих вариаций прокачать по шине :) Думаю тут тебе нечего будет возразить.
По какой шине?
Вообще-то обработка GPU и подразумевает сей факт, что по AGP передавать ничего не надо. Все данные хранятся в видеопамяти, а GPU их обрабатывает.
Можешь спросить Флая. Я не совсем понял, о чём речь.

Mikle
>Нет. Это одно измерение
Ага. Это я затупил.
>Причем мы не делаем между ними разницы
Как это не делаем??? Т.е. делим по материалам, чтоль, т.е. подпространство делили на 8 частей, а так ещё на материалы? Не. Я чё-то не догоняю. Это ж бессмысленно.
>Так мы сильно увеличиваем число переключений
Переключений чего?
>А тормозит там ужасно тупой, неоптимизированный и ламерский код из HL2 :)
Ага. :-)))

#86
12:38, 1 апр. 2005

Fly
>По моим расчетом жаба будет занимать 15 мегов со всеми анимациями
Ну и ладно. Прорвёмся. Хранить в ОЗУ и всего делов. Жаб ведь не сто в кадре. А AGP довольно быстрое.
(Кстати, этот расчёт делался в half float надеюсь, ну во всяком случае можно fixed point использовать, этот формат вроде есть в D3D, хотя я не знаю точно)
>30 fps (даже 15 мало!!) и 5 анимаций
Ну 24 хватит за глаза в любом случае (это же интерполяция, а не FPS игры, когда в кваке 50-ти мало чтобы реагировать нормально). Реально до 20 можно спокойно уменьшать (я проверял анимацию хотьбы для перса морфингом на 5 кадров в сек. -- с интерполяцией нормально выглядело, так сразу и не скажешь, что 5 фпс, и шёл он довольно быстро).
>10 монстров - 150 мегов
Я ж не предлагаю всех монстров сразу на кадры разбивать, и тем более в ресурсах хранить в таком виде.
А просто расжимать из скелетной анимации в морфинг монстры, которые появятся скоро, а те кот-е не появятся удалять из памяти (ведь у вас водомерки в конце не появляются? Или нет?).
>А тормозят в скелетной анимации тысячи умножений матрицы на матрицу.
Так она на CPU или GPU? Или всего по маленьку?

#87
12:57, 1 апр. 2005

tav
Именно про это я тебе и сказал - прокачать по AGP 100 жаб будет сложно. И чего было не понятного :) сам не понял, сам себе ответил. :)
Короче, уже Флейм пошел. То, что ты предлагаешь - малоэффективно и имеет массу ограничений (т.е. до определенного количества треугольников, а потом грабли). Именно поэтому на современном железе бестольково использовать Лоды, которые эфективно работали на tnt-gf2. Т.к. обработака ускорителем геометрии - не самое узкое место. И давай на этом закругляться.
Даже если предположить, что минимальная карта - direct7 hardware comp. - все равно глупо начинать с оптимизации геометрии. Счет уже идет на сотни тысяч в кадре (даже филрейт не самая сложная грабля для такого железа). А вот CPU загрузить - как нефиг делать. Медленный скрипт, плохая физика, сложное AI... еще перечислять? Так что забудь про оптимизацию графики в век 6800. Это просто глупо.

#88
14:31, 1 апр. 2005

tav
Раньше быдо N деревьев октри (N - кол-во материалов). А теперь ОДНО хекстри.
Размер одного материала равен размеру одного листа по X,Y,Z.

#89
17:07, 1 апр. 2005

5 копеек.

1. увеличивать кол-во батчей смешно. Ну, если мин. требования - tnt2, то не смешно. Но это не тот случай. Предлагать какой-то вариант "оптимизации", предварительно не проверив, что в данной ситуации он будет работать хорошо - тоже смешно. Теоретические выкладки работают хорошо, пока не видишь реализацию.

2. морфинг на GPU вместо скелетной анимации - это круто. :) Не смущает огромный набор передаваемых данных? Если один кадр весит A mb, то при N водомерках в кадре надо передавать N*2A mb (на каждую водомерку - 2 кадра). При скелетной анимации на CPU - N*A. При скелетной анимации на GPU вообще ничего не надо динамически обновлять, в (видео)памяти хранится A mb (начальное состояние). Теоретически, если N не очень маленькое, а кол-во кадров не очень большое, то можно уменьшить кол-во данных (близкие кадры считать равными), но... см. пункт 1.

3.
> А тормозят в скелетной анимации тысячи умножений матрицы на матрицу.
вектора на матрицу? Или узкое место - расчет матриц костей?

Страницы: 1 2 3 4 5 6 7 Следующая »
ФлеймФорумОбщее

Тема в архиве.