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

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

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

Страницы: 1 2 3 412 Следующая »
#15
18:56, 2 июня 2012

BorisV
> Скорость рендеринга очень низка из-за громадного числа объектов, текстур,
> треугольников в сумме около 3 миллионов (и это не учитывая тени). Кроме уже
> существующих адских тормозов (на процах sandy bridge разумеется терпимо, на на
> amd 15-25 фпс)
а что тормозит-то ? сколько fps с отключеным рендером ? без текстур ? сколько fps если в каждом dip ограничить количество треугольников до 1шт например,
отключить антиалязинг, отключить тени


#16
19:02, 2 июня 2012

>Прошу подкинуть любые идеи оптимизации, даже самые абсурдные.
Разбить рисование статичной геометрии по кадрам (каждый N-ный рисовать 1/N часть геометрии), если она гарантированно не перекрывает то, что обновляется каждый кадр.
Скиннед геометрию рисовать каждый кадр. При движении камеры добавить мыльца.

#17
19:27, 2 июня 2012

>Прошу подкинуть любые идеи оптимизации, даже самые абсурдные.
Или даже вот так: если камера неподвижна и нет теней, то разбить экран сеткой и обновлять те ячейки, на которые приходится изображение bbox'a перерисовываемого объекта

#18
19:56, 2 июня 2012

wawan
25 мс рендеринг в цвет, 8 мс в тень, 20 мс на всю подготовку объектов (изначально, было 38, но еще думаю выжать 10-15 удастся), еще немного для всякого ерунды типа анимации растительности и частиц. Сколько без текстур, с отключенным рендером и т.п. уже не помню, давно экспериментировал и пришел к выводу, что в количество дипов и в вершинную производительность упёрся (поровну на тестовом железе). Некоторой экономии можно достичь за счет перехода на деффер, меньше констант засылать придется, но это все мелочи, которые в сумме не дадут необходимого радикального прироста. Обычная проблема из-за дипов, усложненная безконтрольным энтузиазмом мэпперов.

axiom

Разбить рисование статичной геометрии по кадрам (каждый N-ный рисовать 1/N часть геометрии), если она гарантированно не перекрывает то, что обновляется каждый кадр.

Не понял смысла, а что это даст? Ведь если нарисовать сцену сразу и не перерисовывать статические области, будет проще (о подобном читал кажется в пейпере от ати). Хотя не понимаю, как сделать, деревья колышатся, даже если без них отрисовать, отделить перекрытия как, без понятия. Объектов же немерянно много.
Или даже вот так: если камера неподвижна и нет теней, то разбить экран сеткой и обновлять те ячейки, на которые приходится изображение bbox'a перерисовываемого объекта

Интуиция подсказывает, что-то в этом есть интересное, пойду подумаю.

To all
Рассмотрю также предложения в духе приделать dof вдали и там рисовать спрайтами, но к сожалению непонятно как будет работать из-за высокой активности действий на всей карте, взрывов, дыма и т.п.

#19
20:14, 2 июня 2012

>Не понял смысла, а что это даст? Ведь если нарисовать сцену сразу и не перерисовывать статические области, будет проще
При движении камеры перерисовывать статику придется неминуемо. Если, например, рисовать в четный кадр половину статики, в нечетный кадр другую половину и блендить, то получаем уменьшение числа DIP'ов для статики на кадр в два раза, и прирост fps в до двух раз. При этом удастся поднять fps для динамики/анимации, а для статики фактически сохранившийся для нее fps все-таки менее страшен. Те части на кадрах, где происходит обновление (ячейки, где изображение bbox'a обновляемых объектов) перерисовывать каждый кадр.

#20
20:20, 2 июня 2012

Т.е., если камера неподвижна, то перерисовывать ячейки только по необходимости, а если движется, то рисовать статику полукадрами и включить моушен блюр.

#21
20:27, 2 июня 2012

axiom
> Если, например, рисовать в четный кадр половину статики, в нечетный кадр другую
> половину и блендить
картинка будет смещаться на экране частями, это разрушит мозжечок игроку на подсознательном уровне )

#22
20:33, 2 июня 2012

wawan
За время  между двумя кадрами при ограниченной скорости(линейной и угловой) камеры вроде бы сильно не сместится, плюс блюр.
Но, даже если это и так, можно это обставить как багофичу, подчеркнув и напихав побольше постэффектов во время движения.

Типа, как в google maps
google maps frame blending | Помогите с идеями оптимизации в "сложных условиях"

#23
20:35, 2 июня 2012

интересная тема.
насчёт дипов - что если попробовать обломки объектов склеить в большие кучи по одному дипу, но каждому обломку повесить в вертексы номер этого объекта, а затем трансформить их в VS, считывая по этому номеру данные из флоатовой текстуры? флоатовую текстуру - обновлять только нужные пиксели когда объекты движутся.
т.е. это даст больше объектов, чем если сувать массив матриц и не будет инстансингом, если инстансинг медленный. только будет ли VTF быстрее? хз
если получаются слишком жирные VB, то ничего не приходит в голову лучше чем стримить их по мере продвижения камеры.

#24
20:46, 2 июня 2012

думаю что нужно моделеров насточиво попросить поучаствовать в увеличении fps, без них задача выглядит как впихнуть невпихуемое
хотя это все не более чем гадание по скришоту )

#25
21:17, 2 июня 2012

мегатекстуру? Кол-во дипов сразу станет меньше.

#26
21:57, 2 июня 2012

BorisV
> http://i.imgur.com/KG1rr.jpg
ппц сетка. нужно геометрию оптимизировать в редакторе. на крышу здания должно уходить 4 полигона а у тебя ппц.
на забор должно уходить 2 полигона (имеется ввиду на кусок).
если ландшавт у тебя всё время плоский то юзай под него тоже 2 полигона, если нет то прикручивай какие нибудь ROAM алгоритмы
да у тебя там всю геометрию нужно оптимизировать. такая для игр не годится особенно для rts.
на уровне кода обязательно нужно прикрутить лоды, octree и инстансинг.

#27
22:02, 2 июня 2012

За заборы и крыши надо отрывать что-то такое нужное и важное у моделлеров.
Выбросить такие крыши, показывать только когда разрушены.
Убрать внутренности домов, показывать когда разрушены (процентов 20 поликов точно).
При таком количестве полигонов в кадре никакие дефферы не помогут.

#28
22:34, 2 июня 2012

1. Сделать более агрессивным переключение лода - на скрине явно дистанция завышена. Мелкие объекты лучше вообще выкидывать на средней дистанции.
2. Объединять видимую статическую геометрию блоками (ячейками или квадтри) в одном ВБ, как ты и делаешь. Пересчет блоков только при перемещении камеры. Памяти наест, но это только для относительно крупных объектов. Совсем мелкие можно лить в динамический буфер в софте.
3. Почему такие низкие требования? Счас ни у кого такого хлама нет, надо их поднять и тупо использовать инстансинг. Если будет тормозить, то бюджет превышен и надо проредить карту. Это быстрей, чем переделать объекты.
4. Проверить шаринг текстур. По-моему, что-то не так с ними - по картинке их должно быть мало.
5. Наказать непричастных за контент.

#29
22:44, 2 июня 2012

Чем обусловлена такая сетка земли? Неужели нельзя слить в несколько квадов? Тогда и скорость возрастет.

Кстати сетка крыши домов - тоже адь! Это кто там налепил 100500 треугольников?

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

Используется сортировка? Т.е. сперва отрисовываем дома, а только потом землю. Это позволит отдохнуть видеокарте от растеризации перекрытых обьектов.

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

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