2012-03-26 4 views
2

Предположим, у меня есть текстура, которая естественно не квадратная (например, фотографическая текстура чего-то с соотношением сторон 4: 1). И предположим, что я хочу использовать сжатие PVRTC для отображения этой текстуры на устройстве iOS, что требует, чтобы текстура была квадратной. Если я масштабирую текстуру так, чтобы она была квадратной во время сжатия, результат был бы очень размытым изображением, когда текстуру просматривали с расстояния.Как бороться с искажениями текстуры, вызванными «квадратичными» текстурами и взаимодействиями с mipmapping?

Я считаю, что это вызвано mipmapping. Поскольку mipmap-фильтр видит новый большой растянутый размер, он использует это, чтобы выбрать низкий уровень mip, что на самом деле неверно, поскольку эти пиксели были просто растянуты до такого размера. Если бы он посмотрел на другое измерение, он бы выбрал уровень mip более высокого разрешения.

Эта теория подтверждается (несколько) замечанием о том, что если оставить текстуру в формате, который не должен быть квадратным, версии mipmap выглядят просто денди.

Параметр LOD Bias, но документы говорят, что применяются к обоим измерениям. Похоже, что призванный является способом смещения LOD, но только в одном измерении (т. Е. Для смещения его к большему разрешению в размерности текстуры, которая была увеличена).

Кроме того, чтобы перерезать геометрию, чтобы использовать квадратные подмножества исходной текстуры (что является неосуществимым, дать наш производственный трубопровод), есть ли у кого-нибудь какие-нибудь умные хаки, которые они использовали для решения этой проблемы?

ответ

0

Мне кажется, что у вас есть несколько вариантов, в зависимости от того, что вы можете сделать, скажем, с вершинами UV.

[Хмм Просто понял, что в следующем я предполагаю, что V координаты бежать от вершины до основания ... Вы должны позволить мне быть старой школы :-)]

Первое, что приходит на ум, - это взять текстуру источника 4N * N (X * Y) и повторить ее 4 раза по вертикали, чтобы получить текстуру 4N * 4N, а затем настроить V-координаты на модели на 1/4 их текущего значения. Это не сэкономит вам столько, сколько памяти (так как это означает, что PVRTC 4bpp становится на 4 раза больше), но он будет еще сохранить пропускную способность и пространство кеша, так как другие части текстуры не будут доступны. MIP-сопоставление также будет работать вплоть до текстур 1x1.

В качестве альтернативы, если вы хотите сэкономить немного места, и у вас есть пара текстур 4N * N, вы можете попробовать их объединить в «вид» 4N * 4N атласа. Поместите первую текстуру в верхние N строк, затем следуйте за ней по N/2 верхних строк. Упакуйте нижние N/2 строки второй текстуры, а затем вторую текстуру, а затем верхние N/2 строки. Наконец, сделайте нижние N/2 строки первой текстуры. Для УФ-ов, которые получают доступ к первой текстуре, выполните то же деление на 4 для параметра V. Для второй текстуры вам нужно разделить на 4 и добавить 0.5 . Это должно работать нормально, пока уровень карты MIP не будет настолько мал, что две текстуры будут смешаны вместе ... но я сомневаюсь, что это действительно будет проблемой.

+0

Мы комбинируем текстуры вместе везде, где можем, так что это происходит только тогда, когда у нас есть повторяющаяся текстура. Первый трюк, который вы упомянули, действительно будет работать в этом случае, но второй трюк здесь не может быть и речи. Вхождение и изменение геометрии - это не то, что я хотел бы сделать (например, если есть УФ-анимация). Но я согласен, что это устранит размытие. Любые другие умные идеи? –

+0

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

+0

У вас есть ссылка на это? Я предположил, что квадратное требование исходило от аппаратного обеспечения.Я бы хотел сообщить об ошибке с Apple, если это не понадобится! –