Войти
ПрограммированиеФорумГрафика

Помогите с идеями оптимизации в "сложных условиях"

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 311 12 Следующая »
#0
16:06, 2 июня 2012

Приветствую
Прошу подкинуть любые идеи оптимизации, даже самые абсурдные. Игра (rts) на d3d9 рендере, вот пример карты:
http://i.imgur.com/dMVCy.jpg
Скорость рендеринга очень низка из-за громадного числа объектов, текстур, треугольников в сумме около 3 миллионов (и это не учитывая тени). Кроме уже существующих адских тормозов (на процах sandy bridge разумеется терпимо, на на amd 15-25 фпс) планируется еще добавить для эффектов, использующих глубину сцены, а в данных условиях препасс только в глубину не могу использовать, а в деффер переделать это значит проблемы со сглажкой, которая здесь очень важна. Суперсэмплинг примерно выдаст те же тормоза, что и отрисовка в глубину отдельно, хотя его преимущество в масштабируемости, нет bottleneck'а дипов. Использование вендорных хаков для получения глубины из z-буффера не прокатит, т.к. у нвидии хак для multisampled rt доступен только избранным. В общем как ни крути, а лучше искать альтернативы оптимизации.

Что есть, что продумывал:

  • Объединение геометрии в единый vb спасает, но это весьма значительные затраты памяти, да и не все объекты можно объединить, все равно 5000-8000 dip-ов получается (если не объединять, то 150000+). Инстансинг заметно медленнее, поэтому использовать решил только лишь чтоб уменьшить затраты памяти, не для всех объектов.
  • Назначение текстур на разные сэмплеры, они будут читаться все, но из вершинного цвета объектов выбираться только те, что соответствуют объекту. Таким образом снижаю нагрузку под draw calls, но повышаю по texel rate.
  • Автоматическая генерация атласов. Но текстуры тайловые почти все, издержки на память существенны слишком, либо надо подбирать способ хранить еще копию "краев" текстур и сэмплировать лишний раз, все равно на мипмапах вдали будет жесть.
  • Occlusion culling аппаратный спасает где-то отсекая треть объектов, притом нагрузку добавляет еще больше, чем профит, так что отключил. Неплохо бы сделать софтварный на неиспользуемом ядре, но непосильно при такой полигональности сцены (и памяти не особо, чтоб хранить геометрию для софтового рендера, разве что как-то жать).
  • Разделить геометрию на несколько сторон и не рисовать те, что обращены в обратную сторону к камере. Это на практике не такая уж большая экономия, а вот потери на просчет на цпу весьма ощутимы.
  • Импостеры для удаленных объектов это терпимые затраты памяти, но сглажка отпадает, надо делать суперсэмпинг (да и дефферед заодно). А главное, что почти все объекты разрушаемы и поэтому расположить импостеры вблизи друг друга без артефактов нереально, надо их делать сложными с попиксельной глубиной и параллаксом, нагрузка на видеокарту при суперсэмплинге неподъемная.

  • #1
    16:25, 2 июня 2012

    игра опередила время ? ) лодов не моделили ?

    #2
    16:29, 2 июня 2012

    BorisV
    > Скорость рендеринга очень низка из-за громадного числа объектов, текстур,
    > треугольников в сумме около 3 миллионов (и это не учитывая тени).
    То есть треугольников больне, чем пикселей? У вас что, LOD'а нет?
    Меш этой же сцены покажи.
    > Объединение геометрии в единый vb спасает, но это весьма значительные затраты
    > памяти, да и не все объекты можно объединить, все равно 5000-8000 dip-ов
    > получается (если не объединять, то 150000+).
    LOD должен спасти. Все эти кусты вдали рисуются один и тем же импостором, он в один батч кладётся много раз.
    > Назначение текстур на разные сэмплеры, они будут читаться все, но из
    > вершинного цвета объектов выбираться только те, что соответствуют объекту.
    > Таким образом снижаю нагрузку под draw calls, но повышаю по texel rate.

    > Автоматическая генерация атласов. Но текстуры тайловые почти все, издержки на
    > память существенны слишком, либо надо подбирать способ хранить еще копию
    > "краев" текстур и сэмплировать лишний раз, все равно на мипмапах вдали будет
    > жесть.
    А не надо мипмапы на LOD'ах. Риуешь или генеришь для них маленькие текстуры без тайлинга, сами LOD'ы лоупольные, в один батч.
    > Occlusion culling аппаратный спасает где-то отсекая треть объектов, притом
    > нагрузку добавляет еще больше, чем профит, так что отключил. Неплохо бы сделать
    > софтварный на неиспользуемом ядре, но непосильно при такой полигональности
    > сцены (и памяти не особо, чтоб хранить геометрию для софтового рендера, разве
    > что как-то жать).
    Я не думаю, что он здесь вообще нужен. Простой фрустум куллинг даст достаточное отсечение без таких затрат.
    > Разделить геометрию на несколько сторон и не рисовать те, что обращены в
    > обратную сторону к камере. Это на практике не такая уж большая экономия, а вот
    > потери на просчет на цпу весьма ощутимы.
    Это точно не надо. У тебя тормоза в DIP или в вертексном шейдере?
    > Импостеры для удаленных объектов это терпимые затраты памяти, но сглажка
    > отпадает, надо делать суперсэмпинг (да и дефферед заодно). А главное, что почти
    > все объекты разрушаемы и поэтому расположить импостеры вблизи друг друга без
    > артефактов нереально, надо их делать сложными с попиксельной глубиной и
    > параллаксом, нагрузка на видеокарту при суперсэмплинге неподъемная.
    А этот параллекс тебе точно нужен? Мне кажется, что все эти понты попиксельные нужны только когда смотришь на объект в упор, в шутерах в основном, а так бампа более чем достаточно.

    А почему у тебя вообще столько объектов, текстур и полигонов? Из сложных объектов на скрине только развалина вдали. У домов текстуры одни и те же, заборчики - кустики все одинаковые. Тут 3kk полигонов и 150k DIP это как-то слишком много.

    #3
    16:40, 2 июня 2012

    BorisV

    оооо.... очень знакомая картинка :)

    > Occlusion culling аппаратный спасает где-то отсекая треть объектов, притом
    > нагрузку добавляет еще больше, чем профит, так что отключил

    про треть не могу сказать, а ты посмотри работу OQ когда камера у земли и смотрит параллельно земле - да ещё бугорок перекрывает часть сцены

    уже перешли на sm3.0 ? я прежде всего HW инстансинг попробывал бы, ну и уменьшение переключений vb/ib, да


    > а в деффер переделать это значит проблемы со сглажкой, которая здесь очень
    > важна.

    deferred lighting тут нужен

    BorisV
    > Кроме уже существующих адских тормозов (на процах sandy bridge разумеется
    > терпимо, на на amd 15-25 фпс)

    видео какое ? 

    p.s. stlPort прикрутить ? :)

    #4
    16:43, 2 июня 2012

    Перейти на D310, там уже сами вызовы D3D (!) в 2 раза меньше потребляют ресурсов ЦПУ, чем на девятом. Плюс такие плюшки, как виртуализация видео памяти, буфер состояний и тд., которые при правильном использовании дадут еще больше производительности !
    BorisV
    > Разделить геометрию на несколько сторон и не рисовать те, что обращены в
    > обратную сторону к камере.
    Так отсечение обратной стороны полигонов присутствует ? Или тупо с двух сторон рисует ? Двухсторонний рендер нужен только для плоских объектов - листочки, травка или для прозрачных объектов.
    Использовать инстансинг для растительности. Без истансинга рендер D3D9 скорее мертв, чем жив. Опять же из-за очень дорогих вызовов D3D9 !

    Ну и лоды - это обязательно ! Для дальней травки или кустиков можно использовать простой спрайт ! Разница практически будет незаметна.

    #5
    17:23, 2 июня 2012

    Вот скрин wireframe:
    http://i.imgur.com/KG1rr.jpg

    wawan
    TelVolt
    Лоды есть, но не все объекты их имеют и могут иметь, потому что почти все разрушаемо. Этот результат уже с лодами 4-х уровней.

    У тебя тормоза в DIP или в вертексном шейдере?

    dip прежде всего, но при включении теней уже и вертекстная производительность не пустой звук.
    А не надо мипмапы на LOD'ах. Риуешь или генеришь для них маленькие текстуры без тайлинга, сами LOD'ы лоупольные, в один батч

    Интересный вариант в качестве альтернативы импостерам, но запекать придется автоматически (моделлеры отказываются), а мне кажется без артефактов на ребрах не отрендерить, но главное, что генерация развертки текстур затормозит загрузку карт жутко. Времени на реализацию тоже много, так что этот вариант в конце очереди поставлю.
    А этот параллекс тебе точно нужен?

    Не, имел ввиду что параллакс потребуется импостерам, чтоб объем фигуры иммитировать, а то спрайты плоские будут кидаться в глаза. Нормальный параллакс только для ландшафта и простой, игнорирую.
    А почему у тебя вообще столько объектов, текстур и полигонов? Из сложных объектов на скрине только развалина вдали. У домов текстуры одни и те же, заборчики - кустики все одинаковые. Тут 3kk полигонов и 150k DIP это как-то слишком много.

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

    innuendo

    про треть не могу сказать, а ты посмотри работу OQ когда камера у земли и смотрит параллельно земле - да ещё бугорок перекрывает часть сцены

    В таком режиме никто не играет в rts и с hw occlusion culling производительность равноценна и очень редко выше чем после оптимизации с отключенным occlusion culling. Рассматривать аппаратное отсечение не вижу смысла.
    уже перешли на sm3.0 ? я прежде всего HW инстансинг попробывал, ну и уменьшение переключений vb/ib, да

    Да, на 3_0. Но как уже писал, инстансинг не панацея, потому что начинает утыкаться в вертексную производительность, на видеокартах вроде gf6xxx,7xxx инстанс вообще позорно медленный.
    видео какое ?
    GF9600. Но к примеру срань вроде Radeon 2400 не на много медленнее, тупо балансирование между тормозами от дипов и количества вершин/треугольников.
    stlPort прикрутить ?

    Пардон, а что даст?


    Anika
    D3d9 это единственное подходящее апи, целевая аудитория ограничена достаточно старыми пк, это ж не шутер.

    Так отсечение обратной стороны полигонов присутствую ? Или тупо с двух сторон рисует ?

    Наверно вы допоняли, я говорю об отсечении целым блоком геометрии, при растеризации разумеется cullmode=ccw.
    #6
    17:28, 2 июня 2012

    BorisV
    Изображение
    Подозрительно напоминает "В тылу врага"

    #7
    17:30, 2 июня 2012

    BorisV
    zomg, у вас там рельеф на крыше геометрией сделан? о_О

    На скрине до жути много поликов. Крыши домов можно вообще 4 треугольника + бамп, аналогично и со стенами. Вблизи - параллакс.

    Кустики тоже можно 8 треугольников(4 квада) + альфа-тест.

    Заборчик тоже можно 2 треугольника на сторону + альфа-тест.

    #8
    17:36, 2 июня 2012

    -Eugene-
    Движок от втв2 переделанный.

    bazhenovc
    Крыши обычными нормал мапами. Но нельзя сделать проще геометрию крыш, потому что они разрушаемы и состоят из нарезок геометрии. Когда меня в проект пригласили уже дома были готовы и сказали, что каждый настраивать по месяцу при экспортировании и никто их переделывать не будет. Кусты тоже не такие и детальные, скорее наоборот.

    To all
    Забейте на кустики и растительность, она несравнимо мала по сравнению с остальным.

    #9
    17:36, 2 июня 2012

    bazhenovc
    Есть мнение, что дома смоделированы внутри + с возможностью трещин и разрушения.

    BorisV
    Как совет - без разрушений использовать максимально упрощенную модель.

    Правка:
    > -Eugene-
    > Движок от втв2 переделанный.
    Ну тогда да, там кусты вообще спрайтовые (нарезка).

    #10
    17:38, 2 июня 2012

    -Eugene-

    Как совет - без разрушений использовать максимально упрощенную модель

    Рассматривался такой вариант, но танки слишком быстро разрушают все, хватает на пару минут сносной производительности, нет смысла.
    #11
    18:05, 2 июня 2012

    > Неплохо бы сделать
    > софтварный на неиспользуемом ядре, но непосильно при такой полигональности
    > сцены (и памяти не особо, чтоб хранить геометрию для софтового рендера, разве
    > что как-то жать).

    А разве примитивы-окклюдеры займут так много памяти?

    #12
    18:18, 2 июня 2012

    А окна у домов прозрачные? На сцене всегда рисуется их содержимое (в том числе и у дальних)?
    Если смотреть на сетку, то вроде да, рисуется. Очень уж большое там скопление поликов.
    Так может разделить дома на "целые" и "обломки"? И не рисовать то, что внутри, если дом целый, а камера далеко?
    Ну то есть отделить внутреннее убранство, от наружных стен.
    Если все дома бахнут так, что они откроются, то и поликов, по идее, уже всё равно меньше будет.
    Открытые двери у дальних домов можно прикрывать черным поликом, который аккуратно  фейдится при приближении, проявляя внутреннее содержимое.

    P.S. Опередили с постом про танки, пока печатал.
    В связи с этим пара вопросов:
    - много ли поликов от дома может остаться после наезда танка (ну то есть он всегда весь разваливается или дом можно "художественно" обгрызать)?
    - и деваются ли куда-нибудь разрушенные блоки дома, заменяясь на абстрактные обломки? Или всё по-чесноку продолжает валяться в округе?

    #13
    18:18, 2 июня 2012

    BorisV
    > идеи оптимизации, даже самые абсурдные
    Уменьшить количество подозрительно круглых бочек.

    #14
    18:39, 2 июня 2012

    axiom
    100 мегабайт, которых собственно нет, уже боролся с нехваткой памяти (точнее фрагментацией) и окклюдеры почти всегда должны мертвым грузом в рамке висеть. Можно было бы еще где-то наковырять, но все равно это тупиковое решение, как можно столько поликов трансформировать на проце? 10 фпс если повезет, пусть и ядро свободное, а все равно на кэш и память влияет такое чудачество. Сгенерировать менее детализированную геометрию бесполезно, т.к. разрушаемые "детальки" и так просты до безобразия. Более удобно создать импостеры в качестве окклюдеров, но тогда софтовая растеризация станет медленнее гораздо уже из-за чтения "текстуры" глубины объекта и однобитной маски.

    MoonStone
    Окна прозрачные почти у всех домов. Но даже если их на удалении "зашторивать", определить внутреннюю часть дома затруднительно, т.к. моделлеры напрочь отказались переделывать, вроде как долго слишком, а разрушаемость очень быстро сводит на нет такие оптимизации. Уже проверял, три минуты активного боя и большинство зданий полуразрушенными стоят. Камера максимум отводится чуть ниже той высоты, что на скриншоте, т.е. высоковато, а опускать ее надо раза в 2-3, чтоб можно было говорить о какой-то эффективности occlusion culling. Кстати, внутри домов пока ничего нет, только стены пустые, будет реализовано через 3д текстуры, чтоб сэкономить на геометрии, не проблема.

    много ли поликов от дома может остаться после наезда танка (ну то есть он всегда весь разваливается или дом можно "художественно" обгрызать)?
    и деваются ли куда-нибудь разрушенные блоки дома, заменяясь на абстрактные обломки? Или всё по-чесноку продолжает валяться в округе?

    Можно "художественно обгрызать" :D, удаляется в лучшем случае половина полигонов (грубо говоря), но в среднем не так много, т.к. валяются мусором новые детальки, т.е. часть уже загруженные удаляются, часть новые подгружаются и добавляются.

    PANDA
    Бочки и т.п. объекты имеют лоды и округлостью не страдают, скорее наоборот.

    Страницы: 1 2 311 12 Следующая »
    ПрограммированиеФорумГрафика

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