Д СУЧАСНИХ ВІДЕОСИСТЕМ ДЛЯ РС

1.Визначення стану об'єктів (Situation modeling) – ця частина програми не має прямого відношення до комп'ютерної графіки, вона моделює той світ, що буде відображатися надалі. Наприклад у випадку ігрових 3D програм це - правила ігри і фізичні закони переміщення гравця, штучний інтелект монстрів і т.д.

2.Визначення відповідних поточному стану геометричних моделей (Geometry generation) – ця частина конвеєра створює геометричне представлення поточного моменту нашого маленького "віртуального світу".3.Розбивка геометричних моделей на примітиви (Tesselation) – ця перша дійсно залежна від "заліза" стадія. На ній створюється зовнішній вигляд об'єктів у виді набору визначених примітивів, зрозуміло, на основі інформації з попереднього кроку конвеєра. Найбільш розповсюдженим примітивом у наш час є трикутник, і більшість сучасних програм і прискорювачів працюють саме з трикутниками. Не вдаючись у математичні подробиці скажу, що на трикутники завжди можна розбити будь-який плоский багатокутник, і саме трьома крапками можна однозначно задати площина в просторі. До того ж, усі ми знаємо, що в Царя було три сини, а в Горинича - три голови [1].

4.Прив'язка текстур і висвітлення (Texture and light definition) – на цій стадії визначається, як будуть освітлені геометричні примітиви (трикутники), а також які і як на них надалі будуть накладені текстури (Textures: зображення, що передають зовнішній вигляд матеріалу об'єкта, тобто негеометричну візуальну інформацію. Гарний приклад текстури – пісок на абсолютно рівному пляжі). Як правило, на цій стадії інформація обчислюється тільки для вершин примітива [2].

5.Видові геометричні перетворення (Projection) – тут визначаються нові координати для усіх вершин примітивів виходячи з положення спостерігача і напрямку його погляду. Сцена як би проектується на поверхню монітора, перетворюючись в двомірну, хоча інформація про відстань від спостерігача до вершин зберігається для наступної обробки.

6.Відкидання невидимих примітивів (Culling) – на цій стадії зі списку примітивів виключаються цілком невидимі ( щозалишилися за чи збоку від зони видимості).

7.Установка примітивів (Setup) – тут інформація про примітиви (координати вершин, накладення текстур, висвітлення і т.д.) перетвориться у вид, придатний для наступної стадії. (Наприклад: координати крапок буфера чи екрана текстур - у цілі числа фіксованого розміру, з якими працює апаратура).

8.Зафарбування примітивів (Fill) – на цій стадії, власне, і відбувається побудова в буфері кадру (пам'яті, відведеної під результуюче зображення) картинки на основі інформації про примітиви, сформованою попередньою стадією конвеєра, і інших даних. Таких, як текстури, таблиці тумана і прозорості й ін. Як правило, на цій стадії для кожної крапки зафарбовуваного примітива визначається її видимість, наприклад, за допомогою буфера глибин (Z-буфера) і, якщо вона не закрита більш близької до спостерігача крапкою (іншого примітива), обчислюється її колір. Колір визначається на основі інформації про висвітлення і накладення текстур, визначеної раніше для вершин цього примітива. Більшість характеристик прискорювача, який можна почерпнути з його опису, відносяться саме до цієї стадії, тому що в основному саме цю стадію конвеєра прискорюють апаратно (у випадку недорогих і доступних плат).

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-платформи. Істотним, але недоліком, що швидко виправляється - відсутність її повного варіанта для деяких розповсюджених прискорювачів.