Колись очищення буферів кольору та глибини насправді потребувало часу. Зрозуміло це означало, що відеокарта повинна буде проходити кожен піксель фреймбуфера і записувати на нього значення.
Через це розробники ігор виявили, що було б ефективніше просто припустити, що кожен піксель буде повторюватися заново. Вони розробили багато методик для цього.
Колірний буфер найпростіше ігнорувати. Менш легкий буфер глибини, тому що він буде забруднений старими даними. Тож те, що вони зробили, було простим.
На кадрі 0, вони будуть надавати з glDepthRange(або D3D еквівалент) (0, 0,5), і вони будуть використовувати glDepthFuncз GL_LESS(або GL_LEQUAL). Це означає, що найменше значення глибини, яке ви коли-небудь отримали в буфері глибини, становить 0,5. Отже, найбільше значення в буфері глибини в кінці кадру 0 дорівнює 0,5 (якщо припустити, що ви писали до кожного пікселя).
На кадрі 1 вони змінили б діапазон глибини на (1, 0,5). Зауважте, що в цьому випадку значення близької глибини більше, ніж далека глибина. Але вони також змінять функцію глибини на GL_GREATER(або GL_GEQUAL), що змінює значення тесту на глибину. Оскільки найбільше значення в буфері глибини становить 0,5, все ви пишете матиме значення більше , ніж це. Оскільки тест на глибину був зворотним, це фактично означає, що все, що було написано на кадрі 0, тепер далече, ніж усе, що могло бути записано на кадрі 1. Наприкінці кадру 1 найменше значення в буфері глибини зараз становить 0,5.
А потім повторюють.
На будь-якому обладнання, виготовленому приблизно з 2003 року, це вже не є оптимізацією. Дійсно, це негативна оптимізація . Очищення буфера глибини насправді робить апаратне забезпечення швидшим . Насправді ні.
В основному, те, що відбувається - очищення буферів насправді нічого не пише. Вони зберігають деякі біти в кешах графічного процесора, які дозволяють системі знати, якого кольору / глибини вони очищені. Коли система намагається записати в кеш-рядок framebuffer, вона не турбується читати, що там є, тому що вона вже знає, що це порожнє поле чіткого значення кольору / глибини. Якщо ви спробуєте поєднатись з тим, що там, або зробите глибинний тест, знову ж таки, не потрібно читати: він знає, яке значення для суміші / тесту з / проти.
Таким чином, кожне перше читання / зміна / запис, яке ви робите в кожному рядку кешу після чіткого, - це в основному запис. Це безкоштовно .
Крім того, наявність нерівного буфера глибини може працювати проти Hyper-Z / Hierarchial-Z / будь-яких оптимізацій Z-culling в апаратному забезпеченні. Так, ваша сцена буде працювати проти тих, з часом, коли ви додасте деталі. Але якщо ваш глибинний буфер зазубрив попередні візуалізації, навіть якщо ці фонові об’єкти знаходяться у фоновому режимі, це може вплинути на ефективність методів Z-купірування. І це не допоможе виступі.
Тож ніколи не слід застосовувати цю техніку повернення глибини в сучасних іграх.
Примітка: Jari робить хороший результат у архітектурному відображенні на основі плиток (як це зустрічається на більшості мобільних платформ). Якщо не очистити глибину, це також може зробити неприємні речі.