Правильная реализация текстурного атласа
В настоящее время я работаю вместе с программным обеспечением, которое генерирует игровые карты, снимая несколько изображений, а затем объединяя их в игровую карту. Сейчас я работаю с OpenGL, чтобы нарисовать эти карты. Как вы знаете, переключение состояний в OpenGL и выполнение нескольких вызовов отрисовки обходится дорого. Я решил реализовать систему атласа текстур, которая позволила бы мне рисовать всю карту за один вызов рисования без переключения состояний. Однако у меня возникла проблема с реализацией текстурного атласа. Во-первых, лучше ли хранить каждую ПЛИТКУ в текстурном атласе или сами изображения? Во-вторых, не все изображения гарантированно будут квадратными или даже степенями двойки. Я дополняю их до ближайшей степени двух, квадрата или обоих? Еще одна вещь, которая меня беспокоит, это то, что изображения могут быть довольно большими, и я беспокоюсь о превышении ограничения размера OpenGL для текстур, что вынудило бы меня разделить карту, разрушив всю концепцию.
Вот что у меня пока концептуально:
-Генерировать текстуру
-Связать текстуру
-Создайте изображение, достаточно большое для размещения текстур (учитываете отступы?)
-Сортировать текстуры?
-Загрузить подтекст на пустую текстуру, сохранить смещения
-Убрать текстуру
Решение
Это не столько прямой ответ, но я не могу ответить прямо, потому что вы задаете много вопросов одновременно. Я просто постараюсь дать вам как можно больше информации по смежным вопросам.
Ниже приведен список соображений для вас, позволяющий вам переосмыслить, каковы ваши приоритеты и как вы хотите их выполнить.
Прежде всего, по моему опыту (!!), использование текстурных массивов намного проще, чем использование текстурного атласа, и производительность примерно одинакова. Массивы текстур делают именно то, что, как вы думаете, они будут делать, вы можете сэмплировать их в шейдерах на основе имени переменной и индекса, а не только имени (то есть: mytexarray [0]). Одним из больших недостатков является наличие одинакового размера текстуры для всех текстур в массиве, преимуществами которого являются: легкая индексация подтекстур и привязка в одном вызове отрисовки.
Во-вторых, всегда используйте степени 2. Я не знаю, допускают ли некоторые последние системы не-мощность двух текстур полностью без проблем, но (опять же по моему опыту) лучше использовать степени 2 везде. Одной из проблем, с которыми я столкнулся при текстуре 500 * 500, были черные линии при рисовании текстурированных квадратов, эти черные линии были точно такого размера, который был необходим для заполнения до ближайшей степени двойки (12 пикселей по x и y). Так что OpenGL несколько создает эту проблему для вас даже на новейшем оборудовании.
В-третьих (это даже английский?), Что касается размера. Все ваши проблемы, кажется, обрабатывают изображения, текстуры. Возможно, вы захотите взглянуть на текстурные буферы, они позволяют передавать большие объемы данных в ваш ГХ и обновляются легче, чем текстуры (это учитывает системы карт LOD). Это в основном хорошо, если вы используете текстуры, но вам нужны только данные, представленные в их цветах, а не цвета.
Наконец, вы можете захотеть взглянуть на «разбрызгивание текстуры», это способ увеличить детализацию без увеличения данных. Я не знаю точно, что вы делаете, поэтому я не знаю, можете ли вы его использовать, но это легко, и его часто используют в игровой индустрии. Вы создаете набор текстур (камень, песок, трава и т. Д.), Которые вы используете повсюду, и одну большую текстуру, отслеживающую, где и где применяется меньшая текстура.
Я надеюсь, что по крайней мере одна из вещей, которые я здесь написал, поможет вам,
Удачи!
PS: ограничения размера текстур openGL зависят от видеокарты пользователя, поэтому будьте осторожны с размерами, превышающими 2048 * 2048, даже если ваш компьютер работает нормально, у других могут возникнуть серьезные проблемы. Безопасные значения — что угодно, вплоть до 1024 * 1024.
PSS: извините за любые грамматические ошибки, попросите разъяснений, если это необходимо. Кроме того, это мой первый ответ, извините за отсутствие протокола.
Другие решения
Других решений пока нет …