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

Текстурный кэш (2 стр)

Страницы: 1 2 3 4 5 Следующая »
#15
13:03, 21 окт. 2013

> а далее никто читать не стал.
SoulSharer, а чего там дальше читать-то? Тебе надо грзуить 2д-уровень. Какой бы большой он ни был - ЕСЛИ он сделан нормально, то его вполне можно предзагрузить полностью и больше уже не тягать ни с диска, ни из памяти. Другой вопрос если он сщделан через одно место - но это уже тогда не проблема кэша, загрузки или чего-то ещё - это проблема того, что уровень сделан через одно место и эту проблему и надо решать первой.

По анимациям - абсолютно то же самое.

Ну и естественно (но это надеюсь ты и сам знаешь) надо всё загонять в аталсы, максимально плотно там упаковывая.


#16
13:10, 21 окт. 2013

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

Загрузи все анимации уровня в оперативу, а КЭШ сделай только для видяхи.

#17
13:11, 21 окт. 2013

slava_mib
> SoulSharer, а чего там дальше читать-то? Тебе надо грзуить 2д-уровень. Какой бы
> большой он ни был - ЕСЛИ он сделан нормально, то его вполне можно предзагрузить
> полностью и больше уже не тягать ни с диска, ни из памяти.
Вот, опередил меня:)

#18
13:11, 21 окт. 2013

slava_mib
Игра Full-HD, уровень/сцена здесь не причем, все анимации загрузить не возможно, их много и весят они много! Все в атласах упаковано и обрезано донельзя.
Главная проблема: анимации, которые используют кучу атласов.

Даже если в оперативку грузить это много выйдет. Есть вариант все это сжать (пока оно в оперативке), но если это допустим shared memory в случае нетбука (и около гига оперативы в лучшем случае), то тут стена недалеко.

#19
13:15, 21 окт. 2013

>Проблема не в подгрузке уровня/сцены. А в непредсказуемости требуемых анимаций.
каждый кадр анимации - 2048х2048? или это все кадры в одном атласе?
может тогда попробовать держать в памяти заранее первые кадры всех анимаций, а если скрипт начинает проигрывать одну, то начинать подгружать следующие необходимые кадры (пока первые ещё отыгрываются)?

#20
13:18, 21 окт. 2013

> их много и весят они много!
SoulSharer, я думаю, тут кстати было бы привести кокнертные цифры. И заодно указать на какое железо рассчитывается ПО - объём видео/оперативки хотя бы. Если текстуры не влезаюдт в видео-память (хотя я не представлю ЧТО там должно быть для этого) - можно попробовать их держать в оператике (можно даже пожатыми) и заливать в видео при еобходимости. Если в вижео-памяти есть УЖЕ СОЗДАННАЯ текстура и надо просто обновить её содержимое - это вполне нормально ложится на обычный конвейер и работает без каких-либо тормозов.

В общем, хватит ходить вокруг да около - дай ВСЕ необходимые данные и цифры - и может кто-то может выродить нужное тебе решение...

#21
14:07, 21 окт. 2013

Глянул в одном из (мобильных) проектов, которым занимался:
- исходники арта 400 Мпих
- кроп 108 Мпих
- разбиение на части и кроп 49 Мпих (итог: 49 атласов 1024*1024)
- общий размер атласов в RGB = 196 Мб
- в ETC (это аналог DDS для OpenGL) = 26 Мб + 26 Мб для альфы
- пожато в архив = 10.6 Мб (включая альфу)

Т.е. если озадачиться - можно пожать данные почти в 20 раз, до состояния 5 Мпих -> 1 Мб в памяти. Сколько мегапикселов (кропнутого и упакованного в атласы) арта у тебя ?

#22
17:00, 21 окт. 2013

Если взять iPad (куда хотелось бы тоже портировать), то у нас есть всего 1 GB оперативки (это в лучшем случае, 3 и 4 поколения), из этого гига спокойно можно будет использовать только половину - считай 512 MB.
Поскольку отдельной видео памяти для графики нет, используется общая (shared memory).

21 текстура 2048х2048 занимает порядка 21 * 16 = 336 MB в несжатом состоянии (это вся сцена + анимации которые будут использованы всегда, например анимация хотьбы).
У нас остается 512 - 336 = 176 MB на звуки, музыку (которую можно застримить), анимации которые не были загружены ранее (и которые мы будем хранить в оперативке, ссылаясь на ваши предложения) и все остальное.
Но все вместе это не уместиться.

Почему?
Допустим у меня 3 персонажа на экране, у каждого персонажа пусть даже всего 10 дополнительных циклов анимации (хотя их может быть и больше), каждый из которых занимает 1-2 атласа (возьмем 1) 2048х2048, что равно 16 MB.
Считаем: 3 * 10 * 16 = 480 MB без сжатия. Не вмещается.
Хорошо давайте сожмем, получается максимум (считаю по PNG сжатию) 2 мб за атлас 2048х2048.
Пересчитываем: 3 * 10 * 2 = 60 MB со сжатием

Сколько остается памяти, учитывая сжатие?
176 - 60 = 116 MB - это в лучшем случае
И все оставшиеся ресурсы мы обязаны уместить в эти оставшиеся гроши.

Почему я не сжимаю текстуры для GPU?
Если я начну скейлить, без MipMapов, Lossy (какой является DXT) текстуру, то вылезут артефакты.

И еще данный подход хранения текстур в оперативке и передача GPU при shared memory странно выходит. Хотя может я чего не догоняю.

#23
17:14, 21 окт. 2013

Неужели подгрузка всего одной текстуры, один раз за долгое время, размером 2048х2048, непосредственного перед отрисовкой должна сопровождаться подвисанием? Ведь только поэтому приходится страдать всем выше описанным, думать о сжатиях, хранить в оперативке и т.д.

#24
17:18, 21 окт. 2013

> 480 MB без сжатия.
SoulSharer, со сжатием (PVRTC 4bpp) будет как раз 2 Мб, если я верно помню что у нас там под iOS поулчалось. 30 аталасов = 60 Мб видео-памяти.

>считаю по PNG сжатию
PNG можешь не считать сжатием, потому что как в памяти (в виде текстуры) оно всё равно будет храниться НЕ сжатым, а вот PVRTC - он как на диске 2 Мб, так и в памяти 2 Мб будет (а не 16 Мб как сейчас получается у тебя в PNG).

>21 текстура 2048х2048 занимает порядка 336 мб в несжатом состоянии (это вся сцена + анимации которые будут использованы всегда, например анимация хотьбы).
Соответственно, эти текстуры у тебя тоже пожмутся и тоже не будут жрать в памяти куча места. 21 текстура выйдет тебе всего в 42 Мб вместо 336.

Соответсвенно, таким образом задача подгрузки полностью отпадает за ненадобностью.

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

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

PVRTC для релиза надо жать на самом-самом slow-mode, тогда качество будет выше просто на порядок и куча артефактов, которые вылазят в "дебажном" (быстром) варианте компрессии - в релизном либо вообще не будут присутствовать, либо будут слабо выражены. Но я лично пошёл ещё дальше - написал в билдере атласов (он у меня тоже самописный) специальный алгоритм "зашумления" итоговой текстуры, который позволяет в итоге выжать из PVRTC ещё немного качества - потому на глаз багов практически вообще нигде не видно (у нас на данный момент 100% арта игры загнано в PVRTC/ETC).

З.Ы. Мы сначала тоже гемороились с загрузкой, многопоточностью и т.д. Но в итоге - у нас ВЕСЬ игровой арт (включая и конфиг8и анимаций и прочее) грузится около 2 сек и занимает всего около 50 Мб памяти (раньше было 30 сек и 250 Мб памяти). например, звук у нас в игре отжирает в разы больше памяти, чем вся графа. И пока ещё никто не писал про какие-то там артефакты, найденные в графике (хотя мы на глаз, и зная куда и как смотреть - конечно можем месстами рассмотреть).

#25
17:27, 21 окт. 2013

slava_mib
Я знаю что текстура используется в несжатом состоянии, если это конечно не DXT или PVRTC или еще какой-то специфичный для граф карты формат.
Использовал лишь как пример сжатия (в идеале), поскольку полагаю, что PNG > DXT в этом вопросе.

И, конечно, сжатие бы все решило, но до сих пор слишком много вопросов насчет этого.
Вот например Вы тоже скейлили графику? Меня этот момент очень волнует. Поскольку камера может приближать/отдалять и эти артефакты могут усилится. И стать более заметными?

#26
17:33, 21 окт. 2013

> Вот например Вы тоже скейлили графику? Меня этот момент очень волнует. Поскольку камера может приближать/отдалять
SoulSharer, скейлили. Масштаб примерно от 10% до 300% (на ретине получается такой).

> и эти артефакты могут усилится. И стать более заметными?
Могут. Но учитывая, что арт ужимается сразу в 8 раз - ничего не мешает его увеличить его в 1,5-2 раза по обеим осям (итого в 2-4 раза больше площадь) и при этом всё равно потреблять в 2-4 раза меньше памяти, чем несжатый формат.

> И, конечно, сжатие бы все решило, но до сих пор слишком много вопросов насчет этого.
Вопросов там реально много, но зато и задач решается сразу куча - и объём занимаемой памяти (в 8 раз меньше), и скорость зарузки (в 10-20 раз быстрее), и более шустрый рендеринг (не замерял насколько), и отстутствие необходимости в стримминге (а эта задача может затянуться не на одну неделю, если решать её толково).

#27
17:37, 21 окт. 2013

SoulSharer,
Как ты собираешься выпускать игру под мобилки влезая в 100 метров ?
2д анимация - это 2д анимация, а не набор кадров записанных в текстуры
>>Неужели подгрузка всего одной текстуры, в один кадр, размером 2048х2048, непосредственного перед отрисовкой должна сопровождаться подвисанием?
ДА


По поводу сжатия и подгрузки
1)DXT жмет хорошо и довольно качественно, пользуйся нвидевской тулой и ресолвь ситуацию с цветом прозраных областей - все будет ок.
2)на мобилках постоянно грузить что-то с диска плохой вариант потому как
    а) соотношение озу\флеш у мобилок аномально огромное по сравнению с пс.
    b) тормоза ловить никто не хочет
    с) драйвера на могилках - говно, глюки 10 летней давности вернулись.

#28
17:49, 21 окт. 2013

Arxon, ещё для Android есть:
  d) флешку, куда установленна игра, могут просто вытащить во время игры
8-)

#29
17:55, 21 окт. 2013

Arxon
С трудном воспринимаю, что написано :(
Про какие тормоза речь, какое соотношение?

Могу лишь предположить, что имеется ввиду, что скорость чтения флешки еще хуже? Хотя это вроде флеш память, разве не должно быть наоборот?

slava_mib
Они и раздолбать телефон могут во время игры, это уже на совести игроков. :)

В любом случае спасибо, буду дальше разбираться со сжатием и смотреть далее от этого.

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

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