Огляд сучасних відеосистем для РС (стр. 4 из 7)

9. Фінальна обробка (Post processing) – обробка всієї результуючої картинки як єдиного цілого якими-небудь двовимірними ефектами.

Деякі стадії цього конвеєра можуть бути переставлені місцями, розбиті на чи частині сполучені. По-друге, вони можуть бути відсутнівзагалі (рідко) чи можуть з'явиться нові (часто). І, по-третє, результат роботи кожної з них може бути посланий (в обхід інших стадій) назад. Наприклад, картинку, отриману на останній стадії, можна використовувати як нову текстуру для 8-ий, реалізуючи в такий спосіб ефект поверхонь, що відбивають, (дзеркал). Таких, як мармуровий піл у грі Unreal.

3D API

Для одержання результату треба визначиться з двома речами – хто які стадії буде виконувати і як він це буде робити. У нас є три основних кандидати на роботу – сама програма (як правило, початкові стадії конвеєра), бібліотека прикладного програмування (інтерфейс, API) і сам прискорювач. Утім, програми, що не використовують прискорювач (Doom, Quake у програмному режимі і т.д.), усі стадії конвеєра виконують самостійно. У поняття бібліотеки в даному контексті можна

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

• OpenGL – створена спочатку для професійних графічних станцій і програм тривимірного моделювання бібліотека. Поступово вона прийшла на платформу PC, в основному завдяки стрімкому прогресу в області "заліза" і грі Quake, що використовувала урізаний варіант цієї бібліотеки. Наявність підтримки цієї бібліотеки в прискорювача вкрай бажано через велике число нових ігор, орієнтованих на неї. Бібліотека є в деякому роді високорівневою, тому що бере на себе всі дії, починаючи із середини 4-ої ступіні нашого конвеєра. З одного боку, це здорово полегшує роботу програмістам, з іншого боку - здатно трохи ускладнити її ж, особливо при реалізації нестандартних чи ефектів необхідності використовувати нові можливості прискорювача, що виходять за рамки OpenGL. Гарний приклад корисності подібного підходу – можливість випустити версію OpenGL, що значно прискорює (конкретно – геометричні перетворення) роботу ігор на нових процесорах з SIMD наборами команд – AMD 3Dnow! і Intel Katmai New Instructions (MMX2). Очевидним достоїнством також є переносимість програм на інші, не Wintel-платформи. Істотним, але недоліком, що швидко виправляється - відсутність її повного варіанта для деяких розповсюджених прискорювачів.
• Direct3D – бібліотека, що є частиною Microsoft Direct і поддерживаемая зараз практично всіма прискорювачами. Фактично являє собою дві бібліотеки – низькорівневу (починаючи з 7 стадії) і високоурівневу (з 5-ої). Результат – велика гнучкість для програміста в реалізації його ідей і, як наслідок, головний біль для нього ж через безліч зв'язаних з конкретною реалізацією прискорювача параметрів. Зараз йде бурхливий розвиток цього продукту Microsoft, і, зважаючи на все, версія 6 Direct3D (яка вже офіційно вийшла) буде цілком гідним конкурентом OpenGL по своїх можливостях і швидкості.
• Glide – власна низькорівнева бібліотека (стадія 7 конвеєра і далі) фірми 3Dfx, що домоглася популярності завдяки великому поширенню перших, дійсно успішних прискорювачів (на базі набору чіпів Voodoo). Але, швидше за все, ця бібліотека піде зі сцени в найближчі кілька років. Вона не підтримується іншими прискорювачами і не буде ними підтримуватися (без дозволу 3Dfx це є незаконним), до того ж усі нові ігри, розраховані на неї, працюють, як мінімум, ще з однієї з раніше описаних бібліотек. Творці неприємного виключення з цього правила (а саме, гри Unreal) вже анонсували доповнення до гри з підтримкою Direct3D і OpenGL[3].

Щеіснуєблизько 10 бібліотекнизькогорівня, створенихрозроблювачамирізнихприскорювачів; такихяк: R-Redline фірми Rendition, S3D Toolkit фірми S3 іт.д. Яківипливалоочікувати, програми, написаніспеціальнодляних, поступовозникають[2].

Хочабільшістьсучаснихприскорювачівберутьнасебелишедві-триостанністадіїконвеєра, існуєважливеішвидкопрогресуючевиключеннязцьогоправила: з'явилисяпершідоступнічіпизпідтримкоюгеометричнихперетворень, здатнізначнозбільшитишвидкістьпобудовизображеннянакомп'ютерахзнедостатньоюобчислювальноюпотужністю(а вона, потужність, недостатня по визначенню - інакше не було би потреби в прискорювачах узагалі).

3D акселерація

Отже, самийзагальнийприскорювачскладаєтьсязгеометричногопроцесора (Geometry Processor, покипрактичнозавждивідсутній), механізмуустановки (Setup engine, стадія 7 конвеєра) імеханізмувідмальовкипримітивів – зафарбування (Fill engine, стадії 8 і 9), щопридетальномурозглядівиявляєтьсякомбінацієюдвохблоків – обробкитекстур (Texel engine) іобробкибуферакадру (Pixel engine). Продуктивність прискорювача залежить від процесора, продуктивності пам'яті, шини і самих обробних блоків. Як правило, приводяться два числа – максимальна пропускна здатність (трикутників у секунду, triangle throughput) і максимальна продуктивність зафарбування (крапок у секунду, fill rate). Такий підхід можливий, але не дуже коректний. Та й усі ми знаємо, що кращим тестом є швидкість гри, у яку ми любимо грати (fps, кадрів у секунду на якомусь стандартному наборі дій) і якість зображення (у цифрах не вимірити). Саме ці параметри і необхідно довідатися в першу чергу в Internet чи, може бути, у сусіда в під'їзді, але не коштує при цьому забувати про сильну залежність числа кадрів від обсягу пам'яті і потужності процесора комп'ютера цього самого сусіда.

Якщо не вдаватися в глибокі технічні подробиці, зафарбування відбувається в такий спосіб: блок обробки буфера кадру визначають, чи видна зафарбовувана крапка, наприклад, за допомогою буфера глибин (Z Buffer). Якщо вона видна, блок обробки текстур обчислює колір текстури, що відповідає цій крапці примітива. Тут є кілька важливих моментів – інтерполяція (filtering, згладжування) і вибір рівня текстури (mip-mapping). Перший забезпечує зображення без різких прямокутних пікселей, навіть коли ви знаходитеся поблизу предмета і дозвіл текстури явно недостатнє. Другий усуває перекручування (дивні візерунки), що виникають при

надмірному видаленні від текстури, вибираючи аналог текстури з меншим дозволом. Фактично, існує кілька режимів комбінування цих двох методів. Зараз найбільш поширені білінійна фільтрація (bilinear filtering - спочатку визначається необхідна для цієї відстані текстура, а потім значення кольору лінійно інтерполюється між чотирма сусідніми крапками текстури, по кожній з координат на поверхні обраної текстури) і трилінійна (trilinear - дві білінійних для двох текстур, з меншим і великим дозволами, потім результат інтерполюється між ними). Остання виглядає більш приємно, але і вимагає великих витрат, тому що не реалізується за один такт на сучасних прискорювачах з одним блоком обробки текстур і, у результаті, удвічі знижує швидкість зафарбування. Зараз з'явилися перші прискорювачі з анізотропної (anisotropic - усередині куба, із двох наборів по 4 сусідні крапки текстур, разом по 8 крапкам) фільтрацією, що виглядає зовсім добре, але і займає ще вдвічі більше часу. Потім обчислений за допомогою одного з вищеописаних методів колір текстури міститься в буфер кадру, заміняючи значення, що знаходилося там раніше, або комбінується з ним за яким-небудь правилом (combination, blending, alpha-blending). Як мінімум, прискорювач повинний підтримувати режими Джерело*Приймач (Src*Dest) і Джерело+Приймач (Src+Dest). Подібні можливості дозволяють реалізувати кольорове висвітлення, ефекти типу чи металу відображення, реалізовувати трилінійну фільтрацію там, де вона не підтримується апаратно і т.д. (так називана багатопрохідна побудова зображення, multipass rendering).

Як правило, для кожної крапки текстури, крім RGB кольору, можна задати ступінь її прозорості (alpha, RGBA формат текстури), що буде використовуватися прискорювачем для регулювання впливу джерела на приймач. Подібним чином зафарбовуються, наприклад, напівпрозорі по краях вибухи й ореоли навколо джерел світла в Unreal.

Не є життєво необхідної, але дуже прискорює роботу програм, що використовують багатопрохідну побудову зображення (наприклад, Quake2 чи Unreal), можливість мультитекстурування (multitexturing). Фактично, ця наявність двох (чи навіть більш) блоків обробки текстур, здатних одночасно обчислювати два кольори по двох текстурах для однієї крапки примітива, а потім комбінувати їх між собою. Подібною можливістю володіє Vооdоо2, RivaTNT і ще трохи поки "недороблених" чіпів[1].

Важливі також точність представлення квітів (16 біт – Hi-Color чи 32 біта – True-Color, останній набагато краще) і точність буфера глибин (Z-Buffer, 16 біт гірше, 24 і 32 краще), використовуваного для визначення видимості окремих крапок примітива. Помилки у визначенні глибини здатні приводити до дивних ефектів, наприклад, до ніг, що переглядають крізь постамент, статуї в грі Unreal.

І остання дія блоку обробки буфера кадру – накладання глобальних ефектів на готову картинку. Наприклад, туман, чи серпанок темрява (з погляду прискорювача це те саме), тобто ефект, відомий як fogging. Чи використовуваний у RivaZX метод повноекранного згладжування (full screen antialiasing), коли зображення розраховується з великим дозволом, чим показується користувачу, причому сусідні крапки зображення сумуються, і саме сумарне значення демонструється користувачу як одна крапка. Подібним чином усуваються різкі границі між полігонами, зображенню надається приємний "монолітний" вид. Існує також крайове згладжування примітивів, що приводить до практично ідентичного (ледве гірше) результату [3] (edge antialiasing), але потребуюче набагато менше витрат на побудову зображення.

5.ОСОБЛИВОСТІ МОДЕЛЮВАННЯ СВІТЛА І СЦЕНИ

Фізична модель світла

Світло - це дуже складна система, щоб змоделювати її в досконалості. Саме тому ми рідко можемо бачити створені комп'ютером тривимірні зображення, що були б по сьогоденню фотореалістичні. В усіх випадках, чим складніше і реалістично створювана вами віртуальна сцена, тим більше обчислень ви повинні зробити, і тем повільніше вона буде відтворюватися на екран. Як програміст, ви повинні будете вирішити, чим ви більше готові пожертвувати: якістю чи зображення швидкістю його прорахунку на комп'ютері[4]; чи хочете ви, щоб ваша програма привела усіх у здивування своєю красою, але вимагала майже годину для промальовування одного єдиного зображення, чи могла працювати зі швидкістю виводу 60 кадрів у секунду, але при цьому була схожа на карикатуру.