Скажімо, я хочу зобразити квадрат; її текстура - "square.png."
Чи легше комп'ютеру відтворити його, якщо текстура - просто звичайний колір?
А як бути, якщо це там і там дуже галаслива текстура з абсолютно випадковими кольорами?
Або що, якщо ця текстура шумеє в тому сенсі, що кожен піксель в ній відрізняється від одного до іншого, але лише крихітним шматочком?
Відповіді:
Як і більшість речей в розробці ігор, і особливо в ігровій графіці, відповідь "це залежить"
Роздільна здатність текстури може впливати на швидкість візуалізації. Чим більше в ньому пікселів, тим більше необроблених даних для завантаження в графічний процесор, і тим менше текстури ми можемо вмістити в кеш за один раз, тому шейдер може вражати більше пауз, поки він чекає на потрібну частину текстури потрапити в кеш.
Використання міповідтворення може зменшити вплив цього. За допомогою mipmap-файлів ми зберігаємо ланцюжок зменшених версій текстури, що спочатку звучить як ще більше пам’яті. Але це дозволяє нам читати з менших версій, коли текстура відображається на невеликому розмірі на екрані (як віддалений об’єкт в перспективі), тому наші зразки краще використовують кеш текстури, а не стрибаючи по всьому. Це також зменшує згладжування.
Вміст текстур не впливає на ефективність візуалізації більшості часу.
Колір - це лише купа чисел, що стосується графічного процесора, так що це не дуже важливо, що це за цифри, він просто перетворює їх через математику таким же чином. Це не робить нічого фантазійного, як згадати "О, я раніше бачив піксель у цьому зеленому кольорі, я просто повторно використовую той же вихід, який я підрахував минулого разу, коли я бачив цей ввід", тож чи ваша текстура є одним кольором або випадкові блискітки, ваш GPU виконує ту саму роботу.
На відміну від таких форматів, як PNG та JPG, які стискають ефективніше в передбачуваних областях зображення і з'їдають більше біт у складних регіонах, текстурні графічні формати GPU, такі як BTC, ETC, PVRTC або навіть сирі RGBA, використовують фіксовану кількість біт на блок пікселів. Таким чином, якщо ваша текстура буде більш-менш деталізованою, зберігаючи той самий формат стиснення, не змінить її розмір даних або вплине на передачу даних та ефективність кешу.
Але якщо ви використовуєте певний тип деталей, який попереднє стиснення не зберігає добре, можливо, ви будете змушені змінити все своє зображення на інший формат, який може знову змінити його розмір даних.
Ось найбільша зірочка в цій ситуації: ви можете використовувати цей колір текстури для прийняття рішень, як if()гілка. Тут детально важливі значення швидкості.
Блоки затінення GPU працюють над блоками пікселів у партіях, виконуючи ті самі інструкції паралельно на кількох потоках даних. Отже, коли деякі пікселі в блоці беруть одну гілку, ifа інші пікселі - іншу, вся партія повинна пройти через обидві гілки (маскування результатів, які не стосуються одного набору пікселів чи іншого).
Якщо ваш вклад змінюється плавним / передбачуваним способом, ви, ймовірно, матимете багато блоків, для яких потрібно взяти лише одну гілку, і ці випадки обох гілок будуть обмежені вузькими смугами навколо межі переходу. Але якщо ваш внесок є випадковим результатом, ми очікуємо, що більшість блоків займе обидві гілки та сповільнить візуалізацію.
Це також може статися, якщо ви використовуєте одну текстуру для управління пошуковими документами на другу текстуру, як спотворення або індексну карту. Якщо перша текстура скаче навмання, то ми будемо відбирати вибірку з розкиданих випадкових плям другої текстури, менш послідовно використовувати наш кеш текстури і чекати довше, щоб отримати в середньому потрібні нам дані.
Отже, загалом: ні, вміст текстури не має великого впливу на швидкість візуалізації, за винятком випадків, коли це відбувається. ;)
nго пікселя, вам доведеться пройти кожен піксель перед ним. При постійній ширині байтів пікселів це просто start_of_buffer + width * n, що набагато швидше, особливо для великих n.
Поряд з DMGregory's відмінною відповіддю вище, мабуть, є один випадок, коли складність "текстури" може вплинути на ефективність візуалізації, і саме тоді результати попереднього візуалізації використовуються як джерело в наступному, наприклад, тіньові карти / відображення / карти довкілля.
Деякі сучасні апаратні засоби можуть застосовувати стиснення без втрат до цих буферів: наприклад, PowerVR має PVRIC , AMD, Delta Color Compression , а ARM має щось подібне. Мета цих методів стиснення - зменшити загальну пропускну здатність, що, в свою чергу, може покращити ефективність візуалізації.
Чим простіші дані, будь то глибина або колір (ціле число або плаваюча точка), тим краще ці схеми будуть працювати. Звичайно, я б не пропонував навмисно спростити ваш показ рендерінгу лише для того, щоб вони краще функціонували, але уникнення використання галасливих даних може допомогти в деяких обставинах.
Крім того, проведення розрізненої вибірки буферів фрейму / глибини, які використовують ці схеми, у марній спробі зменшити пропускну здатність не допоможе, оскільки вони, ймовірно, блокуються.
Далі ви можете знайти ці два запитання та відповіді, що цікавлять SE: