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

Архитектура рендеринга сцены - что уменьшает FPS?

Страницы: 1 2 3 4 5 Следующая »
#0
1:33, 21 апр. 2010

Доброго всем времени!
Прошу уважаемую общественность поделиться знанием о том, как оптимально рендерить сцену, так, что бы свести к минимуму тормоза.
Конкретно, я столкнулся со следующей проблемой - есть небольшой ландшафт, который рендерится в редакторе. Если его рендерить целиком, двумя DIP-ами как два объекта (суша и вода) то FPS максимальный, совпадает с частотой монитора. Однако, задача не предполагает работу с таким ландшафтом целиком - его решено разбить на квадраты, что бы при близком к земле положении камеры все невидимые квадраты не рендерились и не кушали ресурс.

Изображение

И вот какая вышла странность - если этот вот ландшафт (видимый на экране почти целиком!) просто разбить на 64 квадрата (8х8) то FPS падает в два раза. Т.е. вместо двух DIP-ов мы имеем всего 128, а FPS уже упал!
Из-за чего такое в принципе может быть и где можно узнать, как с этим бороться?


#1
2:31, 21 апр. 2010

>а FPS уже упал
О ужас! Теперь вместо 1к - 500!
Никак не бороться, 60 на среднем компе выдает - значить норм.
FPS упадет, это не неизбежно.

>Т.е. вместо двух DIP-ов мы имеем всего 128 а FPS уже упал
А чего хотел? Это не странность. Это такая операция, чем больше вызываешь тем
больше времени требуется, даже при том же количестве геометрии, так как там есть дополнительные
расходы на сам вызов. Поэтому и стараются всякими сортировками(геометрии с одинаковыми текстурами и т.д.) и прочим добиться меньшего количества
вызовов.

>что бы при близком к земле положении камеры все невидимые квадраты не рендерились
Вот так и бороться, что хотели - то и делайте, смотрите что попало во фруструм - то и рендерите, остальное скипайте.
Но зачем это нужно было если и так не тормозило?

P.S.
Ой мои глаза. А фильтрация текстур есть? почему всё так жестко "шумит"?
Или это в пейнте отмасштабировано?

#2
3:12, 21 апр. 2010

Zakus
> Поэтому и стараются всякими сортировками(геометрии с
> одинаковыми текстурами и т.д.) и прочим добиться меньшего количества
> вызовов.
Это я знаю. В том то и дело, что сортировки произведены, вызовы соптимизированы, текстуры и шейдеры используются одни и те же на весь массив фрагментов ландшафта и устанавливаются один раз. НО видимо этого не хватает. FPS падает с 75 до 23.

> Но зачем это нужно было если и так не тормозило?
Это лишь пример небольшого ландшафта, причем речь идет пока только о ландшафте. На картинке он показан с деревьями, есть еще несколько групп не отображаемых объектов. Т.е. оптимизация нацелена в перспективу.

> Ой мои глаза. А фильтрация текстур есть? почему всё так жестко "шумит"?
> Или это в пейнте отмасштабировано?
Да, поскольку картинка целиком была бы великовата, она отмасштабирована, правда не в пейнте, а всего навсего в фотошопе билинейкой.

#3
5:07, 21 апр. 2010

Если это OpenGL, то рендер из одного буфера почти не зависит от числа команд на отрисовку, главное чтобы буферы при этом не переключались.

#4
5:46, 21 апр. 2010

Синий Дракон
> то FPS падает в два раза
Не измеряй производительность в  фпс ,    измеряй её в понятии "время отрисовки"  ,  аля 1/фпс.  Тогда успокоишься.

#5
8:31, 21 апр. 2010

ksacvet777
Если фпс упал в два раза, то время отрисовки увеличилось в два раза. В чём разница?

#6
9:13, 21 апр. 2010

BUzer
> В чём разница?
Тяжелее следить за бюджетом времени? И смотреть где сколько съедено?

#7
9:30, 21 апр. 2010

а зачем бить то, что целиком в экран влазит? больше дипов - меньше фпс, тысячу раз уже обсуждалось.

#8
9:46, 21 апр. 2010

>а зачем бить то, что целиком в экран влазит? больше дипов - меньше фпс, тысячу раз уже обсуждалось.

И да, и нет. Если дип слишком крупный (примитивов много) сам по себе, он будет рисоваться дольше, чем если его распилить пополам. Отсюда назревают следующие проблемы - подобрать размер дип'а, чтобы он рисовался максимально эффективно, и как не рисовать то, что рисовать не обязательно.

>И вот какая вышла странность - если этот вот ландшафт (видимый на экране почти целиком!) просто разбить на 64 квадрата (8х8) то FPS падает в два раза. Т.е. вместо двух DIP-ов мы имеем всего 128, а FPS уже упал!
- Куда делся FPS?
- Он упал.

ФПС падает и ничё не попишешь. Причём падает он нелинейно - чем ближе ты будешь приближаться к отметке в 30-40 фпс, тем медленней он будет падать. Посему сравнивать число фпс на пустой сцене, сцене с кубиком, сцене с ландшафтом и нагруженной сцене с ландшафтом, объектами, кучей света и тени - невозможно. Часто тут возникает вопрос -

ОЙ, Я НАРИСОВАЛ КУБИК, И У МЕНЯ ВМЕСТО 1000ФПС СТАЛО 500, ЧТО ЖЕ ДЕЛАТЬ, КАК ЖЕ БЫТЬ? Ведь моя суперновая видеокарта рассчитана на триллионы треуголников в секунду, а тут 12 треугольников и уже половина ФПС нетути...

А ничего не делать. Нарисовать второй кубик и убедиться, что он съел не вторые 500ФПС, а существенно меньше.

#9
12:34, 21 апр. 2010

SNVampyre
> Если это OpenGL
Нет, это DirectX.

ksacvet777
> Не измеряй производительность в фпс , измеряй её в понятии "время
> отрисовки", аля 1/фпс. Тогда успокоишься.
Так и делаю, измеряю только время рендера, исходя из этого делаю оценку по FPS.

sildc
> а зачем бить то, что целиком в экран влазит?
Такова специфика задачи. Рендер делается для редактора, в котором данный ландшафт во-первых может быть и в 100 раз больше, а во-вторых редактирование объектов на поверхности ландшафта просто невозможно, когда ландшафт виден целиком - для удобной работы камеру надо приближать. Разбиение на фрагменты делается для последующего отсечения по видимости, что бы не рендерить все 100 км квадратных, когда в камере видно только 100 метров.

Cyclone
> Для начала отключить VSync, и убедиться что падение обусловлено только и именно
> этим разрезанием.
Перед созданием темы я в этом очень обстоятельно убедился - в том, что падение связано именно с разрезанием.

#10
13:35, 21 апр. 2010

может в редакторе по-отключать временно не нужные эффекты? если в игре весь ландшафт виден не будет, то не пофиг?

#11
14:27, 21 апр. 2010

Cyclone
Ты видел мониторы с частотой 500Гц? :)

#12
14:47, 21 апр. 2010

Cyclone, еще полезнее внимательно читать тему. :) VSync может ограничить FPS по верхнему пределу, и об этом я написал - в первом посте, однако.
Теперь дальше - будем рассуждать логично: у нас есть программа, которая при прочих равных условиях воспроизведения может обладать только двумя различными состояниями - либо объект разрезан, либо цел. VSync в обоих случаях не меняется. Более того, никакие иные параметры графики не меняются, текстуры остаются в том же разрешении, новые мипмапы не генерятся, параллельные потоки не запускаются, касперский, аська и винамп отключены, вобщем эксперимент проводится в маскимально чистых условиях.

#13
15:06, 21 апр. 2010

Синий Дракон
> VSync может ограничить FPS по верхнему пределу
Не только. Если не вписался до следующей вертикальной синхронизации (т.е. фпс чуть-чуть ниже, чем частота вертикальной развертки), то vsync заставит тебя подождать до следующей синхронизации.
В результате - падение фпс в два раза.

#14
15:32, 21 апр. 2010

Ок.
VSync ON: FPS 75 (целый объект) -> 25 (разрезанный объект).
VSync OFF: FPS 200...250 (целый объект) -> 35...45 (разрезанный объект).
Факт падения фпс независимо от vsynс налицо. Продолжаю искать причину...

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

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