Object
> То есть по-твоему в видюху может быть загружено одновременно лишь 8 (или
> сколько там слотов) текстур?
Хм. Интересное замечание, мне нужно переосмыслить процесс.
при переключении на текстуру никакого копирования не происходит, меняется указатель и производится выборка уже из другого места
Skyblade
> Я смену текстур (даже если у них одинаковые текстурные координаты) не
> рассматриваю....
это одно из важных свойств атласа и к переключению никоим боком не относится
clc
Частично поправил текст. Но всё равно до конца не понимаю, какую ситуцию про быструю смену вы описывали. То есть быстрая смена - это биндим другую текстуру, но оставляем те же текстурные координаты?
это стандарный способ
2ой: не переключаясь заменять часть или всю текстуру
с атласом:
предположим: имеем атлас с набором анимаций (разных юнитов, кадров "видеозаписи")
задача: быстро сменить анимацию (юнит превратился в другого, смена плёнки)
решение: меняем текстурную матрицу или просто передаём смещение в шейдер
clc
Ну, собственно, про второй способ я в начале второго абзаца и написал. Только кратко, это же термин, а не статья.
Про смену текстуры не вижу смысла говорить, так как именно к атласу, как к уникальной сущности, она действительно не относится, и, в общем случае, не даёт выгоды (то есть цена смены текстуры что для атласа, что для не атласа одинакова, так как атлас сущность логическая). Просто кол-во смен (привязок) текстур может уменьшиться, но это я уже исправил в тексте.
А есть качественный софт для генерации текстурных атласов? У меня есть как раз задача по объединению 50 картинок в одну текстуру, причем некоторые из них нуждаются в обрезке, а некоторые и вовсе одинаковые.
правко: не, нафиг
RPG
фотожоп же
не ну есть просмотрщики, но придётся писать батники и одинаковые они не ловят(я думаю) IrfanView
Попробуйте в фотошопе уложить 50 объектов разного размера в текстуре 512*512 максимально оптимальным образом и для каждого из них указывая координаты.
Нужно учитывать не только то, сколько времени отнимает собственно сама смена текстуры. Количество используемых в кадре текстур, например, напрямую влияет на минимальное количество батчей, необходимых для отрисовки кадра, что тоже будет влиять на производительность, и вовсе не из-за ограниченного количества текстурных слотов, или копирования или еще чего-то там текстур при переключении.
Так что первый пункт в статье все таки нехорошо сформулирован. Лучше было бы просто сказать, что помогает минимизировать количество смен состояний. А конкретные детали и подробности в общем случае могут и несколько отличаться в зависимости от гапи, его версии, и используемого железа.
По видеопамяти могу добавить, что в некоторых случаях (когда допустим поддерживаются только текстуры с размерами степени двойки), атласы помогают уменьшить и объем используемой памяти, не только фрагментацию.
...каждое из которых является текстурой для какой-то части трехмерного объекта
И вот это неверно. Не обязательно трехмерного. Не обязательного одного объекта, может быть и нескольких разных объектов. Тем более сам же в качестве примера приводишь шрифт, который под такое узкое определение не подходит)
Насчет ограничения текстурных слотов - есть движок с которого начинал я (LOVE) - в нем поддерживаются шрифты TTF. НО там для каждого глифа создавалась отдельная текстура. Итог печален- жуткие тормоза с рендером шрифтов, но дискомфорта от того что движок генерит тысячи тысяч текстур не доставлял дискомфорта. Именно тормоза с таким рендерером заставили сделать свой упакованный шрифт (у нас в игре тысячи глифов разного размера) а после и вовсе свой движок так как разработчики не и не чешутся исправлять баги.
Lutik
потеряный объём это и есть фрагментация
он нечётко излагает, ему говорили
> помогает минимизировать количество смен состояний
да, там есть уточнение, у него это называется "привязками текстур"
RPG
> Попробуйте в фотошопе уложить 50 объектов разного размера....
ооо это совсем другая задача
что есть глифы? разный шрифт? где понадобилось использовать 1000(ТЫСЯЧУ!) разных начертаний не представляю
> ооо это совсем другая задача
ну да это задача bin packing, а та задача - решается не фотошопом а ImageMagick причем в одну строчку
> что есть глифы? разный шрифт? где понадобилось использовать 1000(ТЫСЯЧУ!) разных начертаний не представляю
Каждый символ определенного шрифта определенного размера. Особенность их метода состоит в генерации 9000 готовых текстур с каждым символом, а учитывая приведение размера получаемых текстур к степени двойки получился дикий рендерер шрифтов. Причем разрабы фиксить этот performance issue не торопятся, и за то время, что прошло с момента публикации бага на их сайте, я написал свой love-совместимый движок, шрифтовый генератор и т. д.:)
Ну и вернемся к сути вопроса. Глифов в игре может быть дочерта, особенно если работать с символами плавающего размера. В игре разрешение может меняться путем банального резайса окна, а шрифт автоматичеси под него подстраивается. Для каждого размера шрифта движок генерил 256 текстур "на лету" что приводило буквально к замусориванию карточки текстурами. Я мог бы использовать один большой шрифт и затем уменьшать его до нужного размера как это делается во многих играх, но в итоге шрифт выглядит уныло, а если размер меньше 12 пикселей то и вовсе выглядит нечитабельно, в то время как в своем растровом шрифте я нагенерил все размеры от 6 pt до 13 pt и уместил на текстуру 256*256 и упаковал в dds.
Получаем сабж, хотя он и выглядит как каша, но результат лучший:
Убрал слово "трёхмерного". Оставил "объект" в единственном числе, так как если мы можем текстурировать один объект, то логично, что можем и несколько (если бы это было не так, написал бы подробнее).
"Привязок текстуры" заменил на "смен состояний".
выходит что это тоже атлас (из местной статьи)
но это не так
clc
> но это не так
Почему? Где находится эталон мер и весов каноничное определение атласа?