Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Unity3D: имеет ли смысл создавать кастомный DynamicResolution?

Unity3D: имеет ли смысл создавать кастомный DynamicResolution?

AlerrПостоялецwww17 мая 20182:07#0
Привет всем!
Узнал, что в юнити работают над динамическим изменением разрешения в зависимости от нагрузки на комп.
Пока вроде как поддерживают только PS. Про PC в их роадмапе ничего нет.
Динамическое разрешение - вещь полезная, нет времени дожидаться пока юнити сделают, а потом исправят его под PC.
Сам пытаюсь сделать нечто подобное динамическому разрешению(меняю разрешение renderTarget), но похоже что это мартышкин труд... Хочу поинтересоваться, может кто делал его. Есть ли смысл? Получилось стабилизировать частоту кадров?
SuslikМодераторwww17 мая 20184:16#1
я делал. даёт очень большой выигрыш в случаях, когда ты fillrate-bound или ALU-bound. для игр, где нагрузка на видеокарту примерно постоянная, смысла реализовывать мало, потому что с постоянным мылом на экране играть никто не захочет. без DX11-level фич нормальный dynamic resolution тоже реалиовать едва ли получится, потому что нужно измерять конкретно тайминги видеокарты, в dx11 для этого есть специальные time query.
g-contПостоялецwww17 мая 20188:56#2
В Крае на случай резкого понижения фреймрейта хранили прошлые кадры и блендили их с новыми. Но поскольку там еще был эффект блура при резких движения камеры, то понять что проиходило было довольно затруднительно. Это вообще интересный вопрос, что лучше лаг или мыло.
AlerrПостоялецwww18 мая 201811:59#3
Suslik
g-cont

Пытаюсь сделать динамическое разрешение экрана таким образом(это скорее динамическое разрешение буфферов):
Есть 3 вида разрешений: Max, 0.75Max, 0.5Max. В случае, когда время CPU превышает максимальное значение, то качество текстуры уменьшается.
На данный момент unity не педоставляет данных для PC о том сколько времени работал GPU и CPU. Время работы CPU можно приблизительно вычислить и самостоятельно, а вот время работы GPU, похоже, невозможно вычислить. Да и наверно время GPU неважно при филлрейтах.
Проблема в чем, в резких скачках качества. Когда fps проседает, то следующая текстура его резко поднимает, и он снова проседает. И так текстуры меняют друг друга и поддерживают эту ситауцию. Если бы разница в размерах соседних буфферов была бы маленькой, то это было бы не так заметно. А так получается фигня.
Вопрос: можно ли иметь одну максимальную текстуру и указывать ее разрешение в зависимости от частоты кадров?
SuslikМодераторwww18 мая 201812:08#4
Alerr
я делал так. принимал, что время, затрачиваемое GPU, можно вычислить по формуле [cht]t = a + w*h*b[/cht], где [cht]a[/cht] — некоторый коэффициент, определяющий время рендера кадра вне зависимости от разрешения, а [cht]b[/cht] — коэффициент пропорциональности разрешению рендертаргета. далее, зная, что последний кадр считался [cht]t[/cht] времени при разрешении [cht]w, h[/cht](текущее разрешение), когда мне бы хотелось, чтобы он считался [cht]t_0[/cht](например, 60fps) , я могу легко вычислить разрешение [cht]w_0, h_0[/cht], при котором он будет считаться, сколько нужно. коэффициенты [cht]a, b[/cht] определяются на ходу, либо можно сделать только оценку снизу, принимая [cht]a=0[/cht]. я использовал один рендертаргет, просто использовал его не весь, а частично, после чего результат растягивал на весь экран.

Правка: 18 мая 2018 12:10

Che@terПостоялецwww18 мая 201813:07#5
Я делал под игру на GL ES. Замерял время swap'a кадра. Это и не особо правильно, но работает как надо.
Когда на экране начинаются взрывы или другие филлрейт-подобные штучки(телефоны это не любят) то снижаю разрешение и фпс возрастает с 10 до 50+. С учетом того, что проблема возникает в основном на телефонах с большим dpi(под 600), то падение качества не так уже и заметно.
AlerrПостоялецwww18 мая 201814:31#6
Suslik
А ты на Юнити делал? Просто я не знаю, похоже что на C# нельзя просто так работать с буффером текстуры, только стандартные операции блита и крайне медленная работа с пикселями.
DelfigamerПостоялецwww18 мая 201815:11#7
Alerr
Скорее всего, Суслик подстраивал матрицу проекции и scissor-прямоугольник так, чтобы рендеринг проходил только в часть рендер-таргета, а потом рисовал квад на весь экран с соответствующими координатами в этот рендер-таргет. То есть - никакой прямой работы, всё делается через координаты.

/ Форум / Программирование игр / Графика

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