Почему текстуры всегда имеют квадратную степень двойки? Что если они не?

Почему разрешение текстур в играх всегда равно двум (128х128, 256х256, 512х512, 1024х1024 и т. Д.)? Разве не было бы разумно сэкономить на размере файла игры и сделать текстуру точно подходящей для развернутой модели UV?

Что случилось бы, если бы была текстура, которая не была степенью двойки?

Было бы неправильно иметь текстуру размером 256х512 или 512х1024? Или это может вызвать проблемы, которые могут возникнуть из-за не-степени двух текстур?

Почему разрешение текстур в играх всегда равно двум (128х128, 256х256, 512х512, 1024х1024 и т. Д.)?

Как следует из байта 56, ограничения размера «степень двух» заключаются (были) в том, что каждое измерение должно быть независимо степенью двойки, а не то, что текстуры должны быть квадратными и иметь размеры, равные степени двойки.

Однако на современных картах и ​​в современных графических API-интерфейсах это «ограничение» было значительно ослаблено, так что размеры текстур могут быть, в пределах разумного, практически чем угодно. Тем не мение:

Разве не было бы разумно сэкономить на размере файла игры и сделать текстуру точно подходящей для развернутой модели UV? Что случилось бы, если бы была текстура, которая не была степенью двойки?

Гарантируя, что размеры текстуры являются степенью двойки, графический конвейер может воспользоваться преимуществами оптимизации, связанной с эффективностью работы с степенями двойки. Например, это может быть (и совершенно точно было несколько лет назад, когда у нас были выделенные графические процессоры и чрезвычайно умные оптимизирующие компиляторы) быстрее делиться и умножаться на степени двух. Работа в степенях двух также упрощает операции в конвейере, такие как вычисление и использование mip-карт (число, равное степени двух, всегда делится равномерно пополам, что означает, что вам не нужно иметь дело со сценариями, в которых вы должны округлять ваши размеры mipmap вверх или вниз).

Это правда, что вы «тратите» некоторое пространство таким образом, но дополнительное место обычно стоит компромисса в производительности рендеринга. Кроме того, существуют методы, такие как сжатие или упаковка нескольких изображений в одно текстурное пространство, которые могут уменьшить часть отходов хранения.

Почему текстуры всегда имеют квадратную степень двойки?

Текстуры не всегда квадратные и не всегда степени двойки . Причина, по которой они, как правило, имеют степень двойки, обычно заключается в увеличении совместимости со старыми видеокартами, наложившими это ограничение. Что касается неквадратных текстур, это обычно не проблема. Обобщить:

• Текстуры, как правило, не должны быть квадратными - хотя DirectX действительно имеет D3DPTEXTURECAPS_SQUAREONLYвозможность, но я работал с неквадратными текстурами даже на старом оборудовании без проблем.
• Текстуры должны иметь степень двойки, потому что многие старые графические карты все еще нуждаются в этом. Причиной этого ограничения было то, что они могли выполнить некоторые оптимизации для операций отображения текстуры. Большинство современных графических карт также не имеют этого ограничения.

Это относится к оптимизации видеокарты. Они были разработаны, чтобы обрабатывать их таким образом. Большинство карт в эти дни будет позволит вам загружать текстуры с размерами, которые не являются степенями двойки, но вероятно , будет иметь негативное влияние на производительность. Существует большая вероятность того, что при загрузке он фактически будет преобразован, что потребует времени загрузки и не сэкономит памяти. Неквадратные текстуры, как правило, в порядке, если их размеры равны двум.

Одним из способов работы с текстурами странного размера является использование Атласа текстур . По сути, вы помещаете несколько текстур в одну текстуру и используете текстурные координаты ваших вершин для ссылки на нужное вам изображение. Это также дает дополнительные преимущества в производительности, поскольку позволяет избежать изменений состояния. Обычно это помещает все элементы интерфейса в одну текстуру. Это означает, что если вы объединили вершины интерфейсов в один буферный объект, вы можете нарисовать все это одним вызовом, а не переключать текстуры много раз и делая отдельный колл-розыгрыш для каждого.

Проблема в том, что некоторые аппаратные средства имеют ограниченную поддержку текстур, которые не имеют мощности двух измерений.

Например, посмотрите внизу http://msdn.microsoft.com/en-us/library/windows/desktop/ff476876%28v=vs.85%29.aspx и прочитайте там сноски 3 и 4.

³ На уровнях характеристик 9_1, 9_2 и 9_3 устройство отображения поддерживает использование двумерных текстур с размерами, не равными степеням двух, при двух условиях. Во-первых, для каждой текстуры может быть создан только один уровень MIP-карты, и, во-вторых, запрещены режимы сэмплера обтекания для текстур (то есть члены AddressU, AddressV и AddressW D3D11_SAMPLER_DESC не могут быть установлены в D3D11_TEXTURE_ADDRESS_WRAP).

⁴ На уровнях характеристик 10_0, 10_1 и 11_0 устройство отображения безоговорочно поддерживает использование двумерных текстур с размерами, не равными степеням двойки.

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

Буфер кадра состоит из фрагментов, которые являются квадратными. Например, на экране с разрешением 800x600 и цветовым пространством RGB (0-255) имеется 800x600 точек с 3 байтами на каждый канал, а общее количество адресов 3x800x600 = 1440 000 байт для адресации в буфере кадров. Это означает, что имеется 1875 адресуемых фрагментов размером 256x256x3 байта. Поскольку данные текстуры являются квадратными, это значительно упрощает отображение из матрицы GRAM в матрицу экранного буфера с использованием бикубического масштабирования, где, как если бы это не было квадратным смещением для более длинной стороны, потребовалось бы больше времени для вычисления, когда это необходимо для быть масштабированным.

Многие графические API принимают данные текстуры, не имеющие квадратной формы, потому что они принимают координаты UV-отображения в качестве данных с плавающей запятой, однако, как только они отправляются в GPU, к данным текстуры добавляется заполнение, потому что фактические пропорции изображения не изменяют отображение кажется незатронутым, однако к данным текстуры добавляется заполнение, потому что графический процессор любит обращаться к нему как к идеальному квадрату.

Таким образом, если используется изображение 100x1024 и используется изображение 1024x1024, что означает, что 946,176 байт будут потрачены впустую. Тем более, если нужно выполнить компоновку, потому что необходимо добавить альфа-канал, чтобы указать, что данные заполнения не должны влиять на составную текстуру.

Наш цифровой мир работает с двоичной нумерацией, а затем в мультиплеере или делит на 2 значение, которое вы можете «переместить» влево или вправо, т.е.

<<  Left shift      x = 5 << 1    0101 << 1     1010     10
>>  Right shift     x = 5 >> 1    0101 >> 1     0010      2

Работать со значениями «мощность двух» проще для процессора.

Современное оборудование может (наконец-то) справиться с включением режимов обтекания при неиспользовании двух текстур на основе, однако неиспользование двух текстур по-прежнему имеет тенденцию тратить память графического процессора, так как они имеют тенденцию увеличиваться по ширине на некоторое количество, специфичное для аппаратного обеспечения (либо до некоторого размера плитки или округляется до следующей степени двух размеров, которая содержит текстуру).

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