- •© Вурста с.Ю.,Літнарович р.М.,2010
- •Вступ………………………………..………………………5
- •4.1.Високопродуктивний компілятор в машинний код………………………………..………………... 126
- •4.4 Бібліотека візуальних компонент…………..135
- •5. Опис графічних бібліотек для написання 3d – програм та ігор……………….……………………………………151
- •1. Історія появи фракталів та їх використання
- •2. Довжина берегової лінії. Фрактальна розмірність. Поняття фрактала.
- •2.1. Приклади побудови фрактальних множин. Класифікація фракталів.
- •2.2. Алгоритм фрактального шуму або шум перліна
- •2.3. Реалізація алгоритму
- •3. Історія розвитку комп’ютерної графіки та ігор
- •3.1. Основні поняття зd-графіки
- •3.2. Основні прийоми для роботи з світлом в 3d:
- •3.3 Алгоритми рельєфного текстурування
- •3.3.1 Рельєфне текстурування (bump mappіng)
- •3.3.5 Простий Relief Mapping
- •3.3.6 Багатошаровий Relief Mapping
- •3.4 Основні прийоми для роботи з текстурами в 3d:
- •3.5 Основні поняття про шейдер та види шейдерів
- •3.6. Генерація тривимірних ландшафтів
- •4.1 Високопродуктивний компілятор в машинний код
- •4.2. Могутня об'єктно-орієнтована мова
- •Об'єктно-орієнтована модель програмних компонент
- •4.4 Бібліотека візуальних компонент
- •4.5. Робота з компонентами
- •5. Опис графічних бібліотек для написання 3d – програм та ігор
- •5.1 Опис графічної бібліотеки OpenGl
- •5.2 Графічна бібліотека DirectX
- •5.3 Візуальні бібліотеки компонентів для OpenGl та DirectX.
- •5.4 Опис закладок glScene
- •6. Проектування системи
- •6.1 Вибір середовища реалізації
- •6.2 Опис використаних компонент glScene для реалізації системи
- •Опис інтерфейсу розробленої системи
- •6.3.1 Панель інструментів
- •6.3.2 Опис робочої області
- •6.3.3 Опис панелі налаштування 3d-сцени
- •Висновки
- •Список літератури:
- •Побудова фрактальних поверхонь в комп’ютерній графіці
- •33027 Рівне , Україна
3. Історія розвитку комп’ютерної графіки та ігор
Найперші ігри для персональних комп'ютерів умовно можна було розділити на два типи - плоскі і векторні[2]. До першого відносилися незабутні "Arcanoid", "Тетріс". Всі вони надавали гравцеві поле для дії, розмір якої зазвичай відповідав розміру графічного екрану, і все відбувалося в двох вимірюваннях.
Інші ж ігри, наприклад авіасимулятор "F-19" гордо називалися "тривимірними", і в них віртуальність була конструкцією з ліній і багатокутників, координати якої обраховувалися із зміною ігровій ситуації, і потім вся вона проектувалася на площину, що співпадала з площиною екрану.
Трохи випередила розвиток комп'ютерів фірма Id Software, яка випустила спочатку "Catacomb Abyss", а потім і "Wolfenstein 3d". Ігри ці йшли ще на 2S6 процесорах, і є яскравим прикладом нового способу зображення віртуальності - текстурування.
По-перше, при цьому способі, стіни коридору, по яких бігає головний герой, - це не просто одноколірні прямокутники, а прямокутні растрові картинки (тобто, що складаються з точок), наприклад, рельєф цегляної стіни, або чий-небудь портрет. По-друге, зображення ворогів, яких гравець бачив "очима" персонажа, також були растровими. Ефект присутності в грі створювало масштабування - при наближенні до стіни її зображення збільшувалося, і відповідним чином масштабувався малюнок її текстури.
Перші тривимірні ігри - мова саме про полігональні движки, а не про псевдотривимірну піксельну графіку - катастрофічно не вистачало продуктивності CPU/GPU. Силоньок кремнієвих коней минулого рвали узду, закушували вудила, але ніяк не могли нормально справитися з прорахунком тривимірних сцен в режимі реального часу. Чи варто говорити, що віртуальні світи, хоч і були повністю тривимірними, не відрізнялися деталізацією.
Розробники, може, і ради були б зготувати з полігонів тривимірні гайки, картини на стіни, люстри і факели. Ось тільки куди до таких надмірностей, коли процесор і з опрацьовуванням основної геометрії не справляється? Адже глибина простору, його об'єм багато в чому залежить саме від дрібниць. Поступали просто: всі «дрібні» елементи - тіні, відблиски, шорсткості, знос і пошкодження - малювали пензликом на текстурах. Виходило, звичайно, плоско, але хоч якось. Як мовиться, не до жиру, бути б хоч трохи об'ємним.
Але «залізна» індустрія розвивалася, потужності процесорів росли, комп'ютерні ігри на місці теж не стояли. Як тільки заповітні мегагерци виросли до прийнятних величин, а в системних блоках більшості геймерів поселилися тривимірні прискорювачі, розробники почали замислюватися: з чого це раптом особливості поверхні намертво зашиті в текстуру? Адже метал, камінь, пластик та і будь-яка інша поверхня залежно від освітлення виглядає по-різному. Грязь, наприклад, погано відображає падаюче світло, потертості, навпаки, краще. Адже є ще і тіні, які прораховуються найпримітивнішим чином.
І були придумані шейдери - процедури, що визначають візуалізацію поверхні об'єкту залежно від різних вхідних даних. Світло, маски прозорості (задаючи області застосування шейдерів), карти віддзеркалення і карти рельєфу - під все були створені свої шейдери. Особливу увагу розробники стали приділяти саме картам рельєфу. Адже раніше тінь на текстурі... правильно, малювали пензликом. А що це за тінь, яка не міняє свого положення залежно від джерела світла?! Карта рельєфу ж відразу дозволила розраховувати тіні в реальному часі. Та і деталізація об'єктів помітно зросла: начебто, полігонів стільки ж, а «об'ємність» простору виросла на порядок.
За останній десяток років графічні карти [1], пізніше названі ЗD-акселераторами, пройшли чималий шлях розвитку - від перших SVGA- прискорювачів, про 3D узагалі нічого не знали, і до найсучасніших ігрових "монстрів", що беруть на собі усі функції, зв'язані з підготовкою і формуванням тривимірного зображення, що виробники іменують "кінематографічним". Природно, з кожним новим поколінням відеокарт творці додавали їм не тільки додаткові мегагерци і мегабайти відеопам'яті, Але і безліч самих різних функцій і ефектів. Давайте ж подивимося, чому, а головне і, навіщо навчилися акселератори останніх років, і що це дає нам, аматорам тривимірних ігор.
Але спочатку незайвим буде з'ясувати, які дії робить програма (чи гра) для того, щоб одержати в підсумку тривимірну картинку на екрані монітора. Набір таких дій прийнято називати 3D-конвеєром - кожен етап у конвеєрі працює з результатами попереднього. На першому, підготовчому, етапі програма визначає, які об'єкти (3D-моделі, частини тривимірного світу, спрайти та інше), з якими текстурами й ефектами, у яких місцях і в якій фазі анімації потрібно відобразити на екрані. Також вибираються положення й орієнтація віртуальної камери, через яку глядач дивуватися на світ. Весь цей вихідний матеріал, що підлягає подальшій обробці, називається ЗD-сценою.
Д
Рис.6.«Нефотореалістичний
рендеринг»: використовування рейдерів
для відтворення «плоскої» картини.
Намальовану вручну.
їхнього висвітлення, а також відсікання
невидимих ділянок сцени.
Розглянемо трансформацію координат. У нас є тривимірний світ, у якому розташовані різні тривимірні ж об'єкти, а в підсумку потрібно одержати двовимірне плоске зображення цього світу на моніторі. Тому всі об'єкти проходять кілька стадій перетворення в різні системи координат, називаних ще просторами (sрасеs). Спочатку локальні, чи модельні, координати кожного об'єкта перетворюються в глобальні, чи світові, координати. Тобто , використовуючи інформацію про розташування, орієнтацію, масштаб і потоковому кадрі анімації кожного об'єкта, програма одержує вже набір трикутників у єдиній системі координат. Потім слідує перетворення в систему координат камери (саmеrа sрасе), за допомогою якої мі дивимося на модельований світ. Після чого відлік буде починатися з фокуса цієї камери - по суті як би "з очей" спостерігача. Тепер легше усього виключити з подальшої обробки цілком невидимі (відбраковування, чи cullіng) і "обрізати" частково видимі (відсікання, чи clіppіng) для спостерігача фрагменти сцени.
Паралельно виробляється висвітлення (lіghtіng). За інформацією про розташування, колір, тип і силі всіх розміщених у сцені джерел світла розраховується ступінь освітленості і колір кожної вершини трикутника. Ці дані будуть використані пізніше при растерізації. У самому кінці, після корекції перспективи, координати трансформуються ще раз, тепер вже в екранний простір (screen space).
На цьому закінчується тривимірна векторна обробка зображення і настає черга двовимірної, тобто текстурування і растерізації. Сцена тепер являє собою псевдо тривимірні трикутники, що лежати в площині екрана, Але ще з інформацією про глибину щодо площини екрана кожної з вершин. Растерізатор обчислює колір усіх пік селів, що складають трикутник, і заносити його в кадровий буфер. Для цього на трикутники накладаються текстури, часто в кілька шарів (основна текстура, текстура висвітлення, детальна текстура і т.д. ) і з різними режимами модуляції. Також виробляється остаточний розрахунок висвітлення з використанням якої-небудь моделі затінення, тепер уже для шкірного пікселя зображення. На цьому ж етапі виконується остаточне видалення невидимих ділянок сцени. Адже трикутники можуть розташовуватися на різній відстані від спостерігача, перекривати один одного чи цілком частково, а ті і перетинатися. Зараз повсюдно застосовується алгоритм із використанням Z-буфера. Результуючі пікселі заносяться в Z-буфер, і як тільки всі зображення буде готовий, його можна відображати на екрані і починати будувати наступне.
Тепер, коли нам зрозумілий пристрій ЗD-конвеєра в загальному виді, давайте глянемо на архітектурні розходження різних поколінь ЗD-прискорювачів. Кожна стадія ЗD-конвеєра дуже ресурсоємна, вимагає мільйонів і мільярдів операцій для одержання одному кадру зображення, причому двовимірні етапи текстурування і растерізації набагато прожерливе" геометричної обробки на ранніх, векторних, стадіях конвеєра. Так що перенос як можна більшої кількості стадій у "відео залізо" благотворно впливає на швидкість обробки ЗD-графіки і значно розвантажує CPU. Перше покоління прискорювачів брало на свої плечі тільки останній етап - текстуруваня і растерізацію, усі попередні кроки програма повинна була прорахувати сама за допомогою CPU. Рендерінг відбувався куди швидше, ніж при повній відсутності ЗD-акселерації, адже відео карта уже виконувала найбільш важку частину роботи. Але все-таки зі збільшенням складності сцен у ЗD-іграх програмна трансформації і висвітлення ставали вузькою шийкою, що перешкоджає збільшенню швидкості. Тому в ЗD-акселератори починаючи з перших моделей NVіdіa GeForce і АTі Radeon був доданий блок, іменований T&L-блоком. Як видно з назви, він відповідає за трансформацію і висвітлення, тобто тепер і за початкові стадії ЗD-конвейера. Його навіть вірніше називати Т&L-блоком (Transformatіon-Clіppіng-Lіghtіng), оскільки відсікання - теж його задача. Таким чином, гра, що використовує апаратний Т&L, практично цілком звільняє центральний процесор від роботи над графікою, а виходить, появляється можливість "навантажити" його іншими розрахунками, чи то чи фізика або штучний інтелект. Здавалося б, усі добрі і чого ще бажати? Але не варто забувати, що будь-який перенос функцій " у залізо " означає відмовлення від гнучкості, властивим програмним рішенням. І з появою апаратного T&L у програмістів і дизайнерів, що бажають реалізувати якийсь незвичайний ефект, залишилося лише три варіанти дій: вони могли або повністю відмовитися від T&L і повернутися до повільних, Але гнучким програмним алгоритмам, або намагатися втручатися в цей процес, виконуючи пост обробку зображення (що не завжди можливо і вуж точно дуже повільно)... або чекати реалізації потрібної функції в наступному поколінні відео карт. Виробників апаратури такий розклад теж не влаштовував - адже кожне додаткове T&L-розширення приводити до ускладнення графічного чипа і "роздуванню" драйверів відео карт.
Як ми бачимо, не вистачало способу гнучко, на "мікрорівні", керувати відеокартою. І така можливість була підказана професійними пакетами для створення ЗD-графіки. Називається вона шейдер (shader). По суті, шейдер - це невелика програма, що складається з набору елементарних операцій, що часто застосовуються в 3D-гpaфіці. Програма, що завантажується в акселератор і безпосередньо керуючою роботою самого графічного процесора. Якщо раніше програміст був обмежений набором заздалегідь визначених способів обробки й ефектів, те тепер він може складати з простих інструкцій будь-які програми, що дозволяють реалізовувати самі різні ефекти.
За своїми функціями шейдери поділяються на двох груп: вершинні (vertex shaders) і піксельні (pіxel shaders). Перші заміняють собою усю функціональність Т&L-блоку відеокарти і, як видно з назви, працюють з вершинами трикутників. В останніх моделях акселераторів цей блок фактично прибраний - його емулює відеодрайвер за допомогою вершного шейдера. Піксельні ж шейдери надають гнучкі можливості для програмування блоку мультитекстурування і працюють уже з окремими пікселями екрана.
Шейдери також характеризуються номером версії - кожна наступна додає до попередніх усі нові і нові можливості. Найбільш свіжою специфікацією піксельних і вершинних шейдерів на сьогоднішній день являється версія 3.0, підтримувана Dіrect 9, - на неї і будуть орієнтуватися як виробники акселераторів, так і розроблювачі нових ігор. На їхню підтримку апаратурою варто звертати увагу і користувачів, що бажає придбати сучасну ігрову відео карту. Проте експансія ігор, побудованих на шейдерних технологіях, тільки починається, так що і більш старі верхові шейдери (1.1), і піксельні (1.3 і 1.4) будуть використовуватися ще як мінімум рік, хоча б для створення порівняно простих ефектів - поки Dіrect 9-сумісні акселератори не одержати більшого розповсюдження.
Перші шейдери складалися усього з декількох команд, і їх неважко було написати на низькорівневому мові ассемблера. Але з ростом складності шейдерних ефектів, що нараховують іноді десятки і сотні команд, виникла необхідність у більш зручному, високорівневому мові написання шейдерів. Їх з'явилося відразу два: NVіdіa Cg (С for graphіcs) і Mіcrosoft HLSL (Hіgh Level Shadіng Language) - останній є частиною стандарту Dіrect 9. Тепер подивимося що необхідно для того, що б одержати всі ті можливості, що дає настільки остання технологія, як шейдери останнього покоління. А ну: Але наступне:
сама свіжа версія Dіrect на даний момент це Dіrect 9.0с;
відеокарта з підтримці Dіrect 9;
самі свіжі драйвер відеокарти (у більш старі деякі функції можуть бути відсутні);
гра, що використовує всі його можливості.
Відразу хотілося б розвіяти ймовірні омани. Деякі трактують популярний нині термін "Dіrect 9-сумісна відеокарта" у такий спосіб: "така відеокарта буде працювати і розкриваючи усі свої можливості тільки під APІ Dіrect 9", чи "Dіrect 9 варто встановлювати на комп'ютер тільки з такою відеокартою". Це не зовсім вірно. Подібне визначення скоріше означає: "дана відеокарта має можливості, необхідними від її специфікацією Dіrect 9".
