Засоби технології Microsoft XNA як основа розробки тривимірних ігрових додатків

ВСТУП

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

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

В свою чергу технологія Microsoft XNA надає доступ програмісту до великого набору спеціальних системних бібліотек та інструментів, спрямованих на поліпшення та спрощення процесу створення високоякісних ігрових додатків для всіх продуктів сімейства Microsoft.

Зважаючи на все вищесказане можна зробити висновок, що проектування та розробка ігрових додатків на базі технології Microsoft XNA, а також наборів класів і програмних компонентів які прискорять і полегшать розробку ігрових додатків в наш час має значну актуальність.

Об'єкт дослідження. Розробка тривимірних ігрових додатків.

Предмет дослідження. Засоби технології Microsoft XNA як основа розробки тривимірних ігрових додатків.

Мета дослідження. Розробка та реалізація тривимірного ігрового додатку з використанням засобів технології Microsoft XNA.

У відповідності з метою дослідження ставляться наступні завдання:

Дослідити та описати поняття тривимірної графіки та математичні основи її побудови.

Проаналізувати процес візуалізації тривимірних сцен.

Дослідити принцип роботи та можливості використання вершинних та піксельних шейдерів.

Розробити концепцію механіки ігрового процесу, та ігрового додатку в цілому.

Створити набір програмних компонентів для роботи з тривимірними сценами, та двовимірними об'єктами, логікою ігрових об'єктів, та їх взаємодією.

Розробити набір шейдерних ефектів засобами мови HLSL.

Методи дослідження. В дипломній роботі були використані такі методи дослідження як аналіз літературних джерел, порівняння при дослідженні сучасних АРІ для програмування тривимірної графіки, абстрагування при розробці логіки ігрового додатку, та аналіз і синтез при створенні класів ігрових об'єктів.

Практичне значення. В роботі було реалізовано тривимірний ігровий додаток який складається з набору взаємодіючих між собою класів та програмних компонентів які можуть бути використані в подальшій розробці та удосконаленні ігрових технологій на базі Microsoft XNA.

Апробація роботи. Результати досліджень розробки графічної частини ігрового додатку доповідались на VIII Всеукраїнській студентській науковій конференції «Сучасні проблеми фізико-математичних наук та методики їх викладання» (Ніжин, НДУ ім. М. Гоголя, 17−18 квітня 2013 р.).

Структура дипломної роботи. Дипломна робота складається зі вступу, 2 розділів, висновків, списку використаних джерел із 16 найменувань, 24 додатків. Загальний обсяг роботи 74 сторінки.

РОЗДІЛ 1. ПРОГРАМУВАННЯ ТРИВИМІРНОЇ ГРАФІКИ

1.1 Тривимірна графіка

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

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

Для одержання тривимірного зображення на площині потрібні наступні кроки:

Моделювання — створення тривимірної математичної моделі сцени і об'єктів в ній.

Сцена (віртуальний простір моделювання) включає в себе кілька категорій об'єктів:

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

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

додаткові ефекти (об'єкти, що імітують атмосферні явища: світло у тумані, хмари, полум’я і т.д.)

Завдання тривимірного моделювання — описати тривимірні об'єкти і розмістити їх у сцені за допомогою геометричних перетворень відповідно вимогам до майбутнього зображення.

Візуалізація — побудова проекції відповідно до обраної фізичної моделі. На цьому етапі математична (векторна) просторова модель перетворюється на плоску (растрову) картинку. Як структура даних, зображення на екрані представлено матрицею точок, де кожна точка визначена принаймні трьома числами: інтенсивністю червоного, синього і зеленого кольору. Таким чином візуалізація перетворює тривимірну векторну структуру даних у плоску матрицю пікселів. Цей крок часто вимагає дуже складних обчислень, особливо коли потрібно створити ілюзію реальності.

Виведення отриманого зображення на пристрій виведення — дисплей або принтер.

1.2 Сучасні API для програмування тривимірної графіки

На сьогоднішній день існує два основних API для програмування тривимірної графіки в ігрових додатках: Direct3D, OpenGL.

DirectX — це набір API функцій, розроблених для простого і ефективного вирішення завдань, пов’язаних з ігровим і відео-програмуванням під Microsoft Windows.

Практично всі частини DirectX API є набором COM-сумісних об'єктів.

В цілому, DirectX підрозділяється на:

DirectX Graphics, набір інтерфейсів, що раніше (до версії 8.0) ділилися на:

DirectDraw — інтерфейс виведення растрової графіки;

Direct3D (D3D) — інтерфейс виведення тривимірних примітивів;

DirectInput: інтерфейс для обробки даних, що надходять з клавіатури, миші, джойстика тощо ігрових контролерів;

DirectPlay: інтерфейс мережевої комунікації ігор;

DirectSound: інтерфейс низькорівневої роботи із звуком (формату Wave);

DirectMusic: інтерфейс відтворення музики у форматах Microsoft;

DirectShow: інтерфейс для вводу/виводу аудіоі/або відеоданих;

DirectSetup: частина, відповідальна за установку DirectX;

DirectX Media Objects: реалізує функціональну підтримку потокових об'єктів.

Для роботи з тривимірною графікою призначений інтерфейс Direct3D.

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

Взаємозв'язок між додатком, Direct3D і апаратурою комп’ютера показані на (рис. 1.1).

Рис. 1.1 — Взаємозв'язок між додатком, Direct3D та апаратурою На рис. 1.1 блок з назвою Direct3D представляє набір документованих інтерфейсів і функцій, які Direct3D надає додаткам і програмістам. Ці інтерфейси і функції охоплюють повний набір функціональних можливостей, пропонованих даною версією Direct3D.

На рис. 1.1 також зображена проміжна стадія між Direct3D і графічним пристроєм — рівень абстрагування від апаратури (Hardware Abstraction Layer, HAL). Direct3D не може безпосередньо взаємодіяти з апаратурою, оскільки продаються сотні різних відеокарт і кожна відеокарта відрізняється набором підтримуваних функцій і способом реалізації тих функцій, які підтримуються.

Наприклад, дві різні відеокарти можуть зовсім по-різному виконувати очищення екрану. Тому Direct3D вимагає, щоб виробники обладнання реалізували рівень абстрагування від устаткування (HAL), який являє собою залежний від апаратури код, що вказує пристрою як виконувати ті чи інші операції. Завдяки цьому Direct3D не потрібно знати специфіку конкретних пристроїв, і його специфікації не залежать від використовуваного обладнання[4].

OpenGL — специфікація, що визначає незалежний від мови програмування крос-платформовий програмний інтерфейс (API) для написання додатків, що використовують 2D та 3D комп’ютерну графіку. Цей інтерфейс містить понад 250 функцій, які можуть використовуватися для малювання складних тривимірних сцен з простих примітивів.

Як було зазначено вище, OpenGL — це всього лиш специфікація, тобто, просто документ, який описує набір функцій і їх точну поведінку. На основі цих специфікацій виробники апаратного забезпечення створюють реалізації - бібліотеки функцій, які відповідають заявленій в OpenGL специфікації. Ці реалізації проектуються для того, щоб коли це можливо використовувати можливості апаратного забезпечення. Коли апаратне прискорення не допускається, виконання функцій здійснюється за допомогою програмного забезпечення. Виробники повинні пройти спеціальні тести на відповідність, перш, ніж їхню реалізацію класифікуватимуть, як реалізацію OpenGL. Таким чином, розробникам програмного забезпечення необхідно всього лиш навчитися використовувати описані у специфікації функції, і лишити їхню реалізацію за розробниками апаратного забезпечення[5].

Ефективні реалізації OpenGL існують для операційних систем Linux, MacOS X, Microsoft Windows та багатьох UNIX-подібних ОС.

1.3 Microsoft XNA

Microsoft XNA — набір інструментів з керованим середовищем часу виконання (.NET), створений Microsoft для полегшення розробки ігрових додатків. Мета XNA в спробі звільнити розробників ігрових додатків від написання «повторюваного шаблонного коду» і об'єднати різні аспекти їх розробки в одній системі.

XNA Framework грунтується на реалізації .NET Compact Framework 2.0 для розробки під Xbox 360 і .NET Framework 4.0 на Windows. Він включає великий набір бібліотек класів, специфічних для розробки ігор, що підтримує максимальне повторне використання коду на всіх цільових платформах. Фреймворк виконується на модифікації загального середовища виконання мов (CLR), що оптимізоване для ігрових додатків. CLR доступне для Windows XP, Windows Vista, Windows 7 і Xbox 360. Так як додатки XNA пишуться для CLR, вони можуть бути запущені на будь-якій платформі, яка підтримує XNA Framework з мінімальними змінами або взагалі без них. Ігрові додатки, які запускаються на фреймворку, технічно можуть бути написані будь-якою .NET-сумісною мовою, але офіційно підтримується тільки мова програмування C# та середовище швидкої розробки XNA Game Studio Express і всі версії Visual Studio 2008, Visual Studio 2010.

Умовно всі компоненти XNA Framework можна розділити на 4 рівні абстракції (рис 1.2) :

Platform (Платформа) — найнижчій рівень, що містить платформно-залежні API, такі як некерований DirectX. У переважній більшості випадків додаток може нічого не знати про існування цього рівня, використовуючи компоненти вищих рівнів абстракції. Більш того, пряме звернення до рівня Platform неминуче звузить діапазон платформ, підтримуваних додатком.

Core Framework (Основний Каркас) — нижній платформно-незалежний рівень XNA, що забезпечує базову функціональність. Розміщується в збірці Microsoft.Xna.Framework.dll і містить 5 компонентів: Graphics (робота з графікою), Audio (робота зі звуком), Input (робота з пристроями введення-виведення), Math (математичні розрахунки), Storage (робота з файловою системою). На платформі Windows перші три компонента (Graphics, Audio, Input) є надбудовами над DirectX, а компонент Storage — надбудовою над класами. NET Framework для роботи з файловою системою.

Extended Framework (розширений каркас) — набір високорівневих класів, для вирішення типових завдань, що постають перед розробником ігрових додатків: ініціалізація графічного пристрою, організація циклу обробки повідомлень, експорт моделей і текстур з графічних редакторів. Розміщується в збірці Microsoft.Xna.Framework.Game.dll.

Game — власне сам додаток користувача.

Рис. 1.2 — Рівні XNA

Слід зазначити Не дивлячись на те, що в другому розділі буде описано процес програмування тривимірної графіки виключно засобами Microsoft XNA, в теоретичній частині будуть дуже часто описуватись саме принципи роботи DirectX. Це пов’язано з тим, що як було вище сказано компоненти XNA які відповідають за роботу з графікою є надбудовами над Direct3D який в свою чергу є одним із інтерфейсів DirectX. Тому те що є вірним для DirectX є вірним і для XNA, у випадку наявності певних розбіжностей в принципах роботи цих двох API про них буде обов’язково зазначено в тексті.

1.4 Математичні основи тривимірної графіки

1.4.1 Вектори в тривимірному просторі

Геометричним представленням вектора є напрямлений відрізок прямої лінії як показано на рис 1.3. У кожного вектора є дві властивості: довжина (модуль вектора) і напрямок. Завдяки цьому вектори дуже зручні для моделювання фізичних величин, які характеризуються модулем і напрямком. Наприклад, часто потрібно вказати напрям поширення світлових променів, орієнтацію грані або напрямок камери, що дивиться на тривимірний світ. Вектори забезпечують зручний механізм завдання напряму в тривимірному просторі.

Рис. 1.3 — Набір векторів які визначені незалежно від системи координат Оскільки місце розташування не є характеристикою вектора, два вектори які мають однакову довжину і вказують в одному і тому ж напрямку вважаються рівними, навіть якщо вони розташовані в різних місцях. Наприклад, на рис. 1.3 вектори u і v рівні. На рис. 1.3 також видно, що вектори не прив’язані до системи координат, оскільки всю потрібну інформацію, довжину і напрямок, вектор містить у собі. Додавання системи координат не додає інформації в вектор, радше можна говорити, що вектор, значення якого є його невід'ємною частиною, просто описаний відносно конкретної системи координат. І якщо ми змінимо систему координат, ми тільки опишемо той же самий вектор відносно іншої системи.

Оскільки місцезнаходження вектора не змінює його властивостей, можна перенести вектори таким чином, щоб початок кожного з них збігався з початком координат обраної координатної системи. Коли початок вектора збігається з початком координат, кажуть, що вектор знаходиться в стандартній позиції. Таким чином, якщо вектор знаходиться в стандартній позиції, можна його описати, вказавши тільки координати кінцевої точки. Ці координати називають компонентами вектора. На рис. 1.4 показані вектори, зображені на рис. 1.3, які були переміщені в стандартні позиції.

Рис. 1.4 — Вектори в стандартній позиції

Існує багато тривимірних систем координат, але в програмуванні тривимірної графіки найбільш розповсюдженими є правостороння та лівостороння системи координат, вони відрізняються лише напрямком осі Z. На рис 1.5 Лівостороння система координат зображена зліва, вісь Z занурюється в екран, в правосторонній системі координат вісь Z направлена на користувача, вона зображена відповідно справа.

Рис. 1.5 — Лівостороння та правостороння системи координат В XNA використовується правостороння система координат, тепер введемо чотири спеціальні вектори які показані на рис 1.6.

Рис. 1.6 — Нульовий та базові вектори тривимірної системи координат Перший з них називається нульовим вектором, і значення всіх його компонентів дорівнюють нулю: v0 = (0,0,0).

Наступні три спеціальних вектора називаються одиничними базовими векторами тривимірної системи координат. Ці вектори, спрямовані вздовж осей X, Y і Z координатної системи, модуль цих векторів дорівнює одиниці, а визначення виглядає наступним чином: i = (1, 0, 0), j = (0, 1, 0), k = (0, 0, 1).

В XNA для представлення векторів в тривимірному просторі використовується структура Vector3.

Приклад: Vector3 i = new Vector3(1, 0, 0);

Так само, як і у скалярних величин, у векторів є власна арифметика, далі будуть представлені основні арифметичні операції над векторами які можуть знадобитись в програмуванні тривимірної графіки.

Рівність векторів Вектори рівні, якщо вони мають однакову довжину та їх відповідні компоненти рівні. Наприклад (ux, uy, uz) = (vx, vy, vz) якщо ux = vx, uy = vy і uz = vz.

В XNA для перевірки рівності векторів використовується перевантажений оператор рівності «= =».

Приклад:

Vector3 u = new Vector3(1, 1, 0);

Vector3 v = new Vector3(1, 1, 0);

if (u==v)

return true;

Обчислення модуля вектора В геометрії модулем вектора, називається довжина спрямованого відрізка лінії. В алгебрі, знаючи компоненти вектора ми можемо обчислити його модуль за наступною формулою: .

В XNA модуль обчислюється за допомогою методу Length.

Приклад:

Vector3 i = new Vector3(1, 0, 0);

double u = i. Length ();

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

В XNA для нормалізації вектора достатньо використати метод Normalize.

Приклад:

Vector3 u = new Vector3(2, 0, 0);

u.Normalize ();

Додавання, віднімання векторів Для того щоб додати два вектори, потрібно додати їх відповідні компоненти; причому розмірність цих векторів повинна бути однаковою:

.

Геометрична інтерпретація додавання векторів зображена на рис. 1.7.

Рис. 1.7 — Геометрична інтерпретація додавання векторів В XNA для додавання векторів використовують перевантажений оператор додавання «+».

Приклад:

Vector3 u = new Vector3(2, 0, 1);

Vector3 v = new Vector3(0, -1, 5);

// (2.0 + 0.0, 0.0 + (-1.0), 1.0 + 5.0)

Vector3 sum = u + v; // = (2.0f, -1.0f, 6.0f)

Віднімання виконується аналогічно, за формулою:

В XNA для віднімання векторів використовують перевантажений оператор віднімання «-».

Множення вектора на скаляр Внаслідок множення вектора на скаляр відбувається масштабування вектора. Якщо масштабний множник позитивний, напрям вектора не змінюється. Якщо ж множник від'ємний, то напрям вектора змінюється на протилежний (інвертується). Множення відбувається за формулою:

В XNA для множення вектора на скаляр використовується перевантажений оператор множення «*».

Приклад:

Vector3 u = new Vector3(1, 0, 1);

int k=2;

u=k*u; // =(2.0f, 0.0f, 2.0f)

Скалярний добуток векторів Скалярний добуток векторів — це перша з двох визначених у векторній алгебрі операцій множення. Обчислюється такий добуток наступним чином:

.

У наведеної вище формули немає очевидної геометричної інтерпретації. Використовуючи теорему косинусів, ми отримаємо відношення, з якого слідує, що добуток двох векторів дорівнює добутку косинуса кута між векторами на модуль векторів. Отже, якщо u і v — одиничні вектори, їх скалярний добуток дорівнює косинусу кута між ними.

В XNA для отримання скалярного добутку векторів використовують метод Dot.

Приклад:

Vector3 u = new Vector3(1, -1, 0);

Vector3 v = new Vector3(3, 2, 1);

Float x = Vector3. Dot (u, v); // = 1.0

Векторний добуток векторів Векторним добутком двох векторів u і v буде інший вектор, p, який є взаємно перпендикулярним для векторів u і v. Це означає, що вектор p перпендикулярний вектору u і одночасно вектор p перпендикулярний вектору v. Векторний добуток розраховується по наступній формулі:

.

Геометрична інтерпретація векторного добутку зображена на (рис. 1.8).

Рис. 1.8 — Геометрична інтерпретація векторного добутку В XNA для отримання векторного добутку векторів використовують метод Cross.

Приклад:

Vector3 u = new Vector3(0, 0, 1);

Vector3 v = new Vector3(1, 0, 0);

Vector3 p = Vector3. Dot (u, v); // p = (0,1,0)

1.4.2 Матриці

Матрицею m Ч n називається прямокутний масив чисел, що складається з m рядків та n стовпців. Кількість рядків і стовпців визначає розмір матриці. Окремий елемент матриці ідентифікується шляхом зазначення його рядка і стовпця в списку індексів який складається з двох елементів, перший індекс визначає рядок, а другий — стовпець. Іноді матриці складаються з єдиного рядка або єдиного стовпця, такі матриці відповідно називають вектор-рядок і вектор-стовпець.

Дії над матрицями Для опису та пояснення дій над матрицями введемо наступні 4 матриці

Рівність матриць Дві матриці вважаються рівними, якщо вони мають однакову розмірність і їх відповідні елементи рівні. Наприклад, A = C, оскільки матриці A і C мають однакову розмірність і їх відповідні елементи рівні, в той же час A? B і A? D оскільки у цих матриць або різна розмірність, або не рівні відповідні елементи. В XNA для перевірки рівності матриць використовують перевантажений оператор рівності «= =».

Додавання, віднімання матриць Для того щоб додати дві матриці потрібно додати їх відповідні елементи, причому додати дві матриці можливо тільки тоді коли вони маються однакову розмірність.

Приклад: Додати матриці А і В В XNA для додавання двох матриць використовують перевантажений оператор додавання «+».

Аналогічно можна виконувати віднімання двох матриць однакової розмірності.

Приклад: Відняти від матриці А матрицю В В XNA для віднімання матриць використовують перевантажений оператор віднімання «-».

Множення матриці на скаляр Для того щоб помножити матрицю на скаляр необхідно помножити кожний елемент матриці на даний скаляр.

Приклад: Помножити матрицю D на скаляр k = 2

В XNA для множення матриці на скаляр використовують перевантажений оператор множення «*».

Множення матриць Множення матриць це найбільш важлива операція, яка постійно використовується в тривимірній комп’ютерній графіці. Саме множення матриць дозволяє здійснювати перетворення векторів і комбінувати кілька перетворень в одне. Перетворення будуть розглянуті в наступному розділі.

Якщо A — це матриця m Ч n, а B — матриця n Ч p, то результатом їх множення буде матриця C, розміром m Ч p, в якій елемент cij знаходиться як скалярний добуток i-го вектора-рядка матриці A і j-го вектора-стовпця матриці B: .

У даній формулі ai позначає i-ий вектор-рядок в матриці A, а bj — j-ий вектор-стовпець матриці B.

Слід також зауважити що множення матриць можливо лише тоді коли кількість стовпців матриці А буде рівна кількості рядків матриці В.

Приклад: Помножити матрицю, А на матрицю В В XNA для множення матриць використовують перевантажений оператор множення «*».

1.4.3 Основні перетворення

При програмуванні тривимірної графіки за допомогою Мicrosoft XNA для представлення перетворень застосовують матриці 4Ч4. Ідея полягає в наступному: Ініціалізуються елементи матриці X розміром 4 Ч 4 таким чином, щоб вони описували необхідне перетворення. Потім координати точки або компоненти вектора переміщуються в стовпці вектора-рядка v розміром 1Ч4. Результатом множення vX буде новий перетворений вектор v'.

Наприклад, якщо матриця X являє собою переміщення на 10 одиниць уздовж осі X, і v = [2,6,-3,1], множення vX = v' = [12,6,-3,1].

Слід пояснити декілька моментів. В програмуванні тривимірної графіки використовуються матриці розміру 4 Ч 4 з тієї причини, що вони дозволяють представити всі необхідні нам перетворення. На перший погляд матриці розміром 3 Ч 3 здаються більш придатними для тривимірної графіки. Однак, з їх допомогою не можна представити ряд перетворень, які можуть знадобитися, такі як переміщення, перспективна проекція і відображення. Слід пам’ятати, що використовується множення вектора на матрицю в результаті цього виконання перетворень обмежене правилами множення матриць. Доповнення матриці до розміру 4 Ч 4 дозволяє за допомогою матриці описати більшість перетворень.

Також вище було зазначено, що координати точки будуть зберігатись в стовпцях вектора-рядка розміром 1 Ч 4. Справа в тому що, потрібно доповнити наші тривимірні точки / вектори до чотиривимірного вектора-рядка 1 Ч 4 щоб мати змогу проводити множення вектор рядка на матрицю, так як помножити вектор-рядок 1 Ч 3 на матрицю 4 Ч 4 не можливо.

Зазначимо, що значення четвертої компоненти вектора-рядка 1 Ч 4 може набувати значення 1 або 0 в залежності від того які дані потрібно відобразити в вектор-рядку. Коли вектор-рядок 1 Ч 4 використовується для представлення точки, значення четвертої компоненти дорівнюватиме 1. Це дозволяє коректно виконувати переміщення точки. Оскільки вектор не залежить від місця розташування, операція переміщення векторів не визначена і результат спроби перемістити вектор не має сенсу. Щоб запобігти переміщенню векторів, поміщаючи компоненти вектора у вектор-рядок 1 Ч 4, четвертому компоненту надають значення 0.

Наприклад, точка p = (p1, p2, p3), поміщена в вектор-рядок 1 Ч 4 буде виглядати як [p1, p2, p3, 1], а вектор v = (v1, v2, v3), поміщений в вектор-рядок 1 Ч 4 буде виглядати як [v1, v2, v3, 0]. [7]

Матриця переміщення Можна перемістити вектор (x, y, z, 1) на px одиниць по осі Х, py одиниць по осі Y і pz одиниць по осі Z помноживши його на наступну матрицю:

Геометрично множення векторів які задають координати точок на матрицю переміщення можна представити наступним чином (рис 1.9). [7]

Рис. 1.9 — Переміщення на 12 одиниць по осі Х і на 10 одиниць по осі Y

В ХNA для створення матриці переміщення використовується метод CreateTranslation ().

Приклад:

Matrix MTranslation;

MTranslation = Matrix. CreateTranslation (12,10,0);

Матриці обертання Використовуючи наведені нижче матриці можна повернути вектор на ц радіан навколо осей X, Y або Z. Причому, якщо дивитися вздовж осі обертання по напрямку до початку координат, то кути вимірюються за годинниковою стрілкою.

Геометрично множення матриці обертання на вектори які задають координати точок можна представити наступним чином (рис 1.10).

Рис. 1.10 — Поворот на 30 градусів проти годинникової стрілки по осі Z.

В ХNA для створення матриці обертання використовують наступні методи: CreateRotationX (), CreateRotationY (), CreateRotationZ (). Слід також зауважити що параметр обертання в даних методах задається не в градусах, а в радіанах.

Приклад: матриця обертання на 30 градусів по осі Z.

Matrix MRotation;

MRotation = Matrix. CreateRotationZ ((float)(30*Math.PI/180));

Матриця масштабування Можна масштабувати вектор з коефіцієнтом qx по осі Х, коефіцієнтом qy по осі Y і коефіцієнтом qz по осі Z, помноживши його на наступну матрицю:

Геометрично множення векторів які задають координати точок на матрицю масштабування, можна представити наступним чином (рис 1.11).

Рис. 1.11 — Масштабування з коефіцієнтом Ѕ по осі Х і 2 по осі Y

В ХNA для створення матриці обертання використовують метод CreateScale.

Приклад:

Matrix MScale;

MScale = Matrix. CreateScale (0.5f, 2, 0);

1.5 Представлення моделей

Весь тривимірний простір який виводиться на екран називають сценою, сама по собі сцена — це набір певних об'єктів і моделей. Модель представляється за допомогою сітки з трикутними комірками які називають полігонами (відповідно сітку називають полігональною). Окремі трикутники сітки (полігони) задаються набором вершин і являються будівельними блоками за допомогою яких моделюються об'єкти (рис 1.12.).

Рис. 1.12 — Складові частини тривимірної моделі

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

Рис. 1.13 — Полігон (трикутник) заданий трьома вершинами Наведене вище визначення вершин вірне з математичної точки зору, але в контексті програмування в XNA є неповним. Це викликано тим, що в XNA у вершини можуть бути додаткові властивості, крім її місцеположення. Наприклад, вершині може бути призначений колір, або координати текстури.

Приклад: ініціалізації трьох вершин кожна з яких містить інформацію про її колір.

VertexPositionColor[] verts;

verts = new VertexPositionColor[3];

verts[0] = new VertexPositionColor (new Vector3(0, 1, 0), Color. Blue);

verts[1] = new VertexPositionColor (new Vector3(1, -1, 0), Color. Red);

verts[2] = new VertexPositionColor (new Vector3(-1, -1,0), Color. Green);

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

Менеджер ресурсів Microsoft XNA підтримує два формати для збереження тривимірних об'єктів .х і .fbx, але якщо потрібно програміст сам може створити код який дасть змогу використовувати і інші формати файлів.

X — формат файлу для зберігання 3D об'єктів, створений компанією Microsoft. Цей формат зберігає інформацію про геометрію 3D об'єкту (координати вершин і координати нормалей), текстурні координати, опис матеріалів, шляхи і назви текстур, які використовуються. Зберігається ієрархія об'єктів, зберігається анімація, і зберігаються прив’язки вершин до «кісток» з описом ваги. У X файлі може бути відсутня деяка інформація про об'єкт (наприклад в X файлі можуть міститися тільки координати вершин).

X файл може бути текстовим або бінарним.

FBX — технологія і формат файлів (.fbx) розробляються компанією Autodesk. Використовується для забезпечення сумісності різних програм тривимірної графіки. Як і .X формат може зберігати інформацію про геометрію 3D об'єкту (координати вершин і координати нормалей), текстурні координати, опис матеріалів, шляхи, назви текстур які використовуються, і т.д., але на відміну від .X може зберігати як 2D так і 3D дані та аудіо та відео дані.

1.6 Віртуальна камера

Для створення тривимірного зображення крім опису тривимірних об'єктів обов’язково потрібна віртуальна камера. Камера визначає яку частину віртуального тривимірного простору може бачити користувач, вона позиціонується і орієнтується в просторі і визначає видиму область простору, для якої потрібно створювати двовимірне зображення. Схема моделі камери показана на рис. 1.14.

Рис. 1.14 — Схема моделі камери Область видимого простору представляє собою усічену піраміду і визначається кутами поля зору, передньою і задньою площинами. Причини використання усіченої піраміди стануть зрозумілими, якщо взяти до уваги, що екран на якому відображається сцена — прямокутний. Об'єкти, які не перебувають всередині заданого простору невидимі і повинні бути виключені з процесу подальшої обробки. Процес виключення таких даних називається відсіченням.

Вікно проекції - це двомірна область на яку проектуються тривимірні об'єкти, що знаходяться всередині області видимого простору для створення двовимірного зображення, що представляє тривимірну сцену.

1.7 Конвеєр візуалізації

Конвеєр візуалізації відповідає за створення двовимірного зображення на підставі геометричного опису тривимірного світу і віртуальної камери, яка визначає точку з якої користувач дивиться на цей світ. На рис. 1.15 показано результат роботи конвеєра візуалізації. Ліва частина зображення показує кілька об'єктів, що утворюють тривимірну сцену і націлену на них камеру, права частина демонструє двомірне зображення, створене на підставі того, що «бачить» камера.

Рис. 1.15 — Результат роботи конвеєра візуалізації

1.7.1 Фіксований конвеєр візуалізації

В старих версіях API DirectX і OpenGL всі етапи конвеєра візуалізації були фіксованими. Це означало, що до всіх переданих на візуалізацію даних застосовувалася заздалегідь запрограмована обробка. В результаті всі тривимірні додатки були змушені використовувати один і той же процес візуалізації, що дозволяє змінювати тільки декілька фіксованих параметрів.

В XNA не використовується фіксований конвеєр візуалізації, але слід приділити йому увагу з тої причини, що саме на прикладі фіксованого конвеєра найпростіше показати і пояснити як саме з набору даних генерується тривимірне зображення.

На рис1.16 представлена спрощена схема фіксованого конвеєра візуалізації яка використовувалась в DirectХ до версії 8.0.

Рис. 1.16 — Фіксований конвеєр візуалізації

Локальний простір Локальний простір або простір моделювання — це та система координат, в якій ми описуємо об'єкт у вигляді списку трикутних граней. Локальний простір корисний тому що він спрощує процес моделювання. Створювати модель в її власній, локальній системі координат простіше ніж вбудовувати її безпосередньо в сцену. Локальний простір дозволяє нам створювати моделі не піклуючись про їх розташування, розмір або орієнтацію щодо інших об'єктів сцени. На рис 1.17 зображена модель описана в її власній системі координат Рис. 1.17 — Модель в локальному просторі.

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

Рис. 1.18 — Декілька моделей в світовому просторі

Простір виду У світовому просторі геометрія об'єктів і камера описані відносно однієї світової системи координат. Однак, проекція та інші операції стануть більш важкими і менш ефективними, якщо камера не займає певне місце розташування і не орієнтована потрібним чином. Щоб спростити обчислення камера переміщується в початок координат і повертається таким чином, щоб вона була спрямована уздовж позитивного напрямку осі Z. Разом з камерою переміщаються і повертаються всі що утворюють сцену об'єкти, так що вид сцени залишається незмінним. Дане перетворення називається перетворенням простору виду (рис. 1.19) і після нього говорять, що об'єкти розташовані в просторі виду.

Рис. 1.19 — Перетворенням простору виду Видалення невидимих поверхонь У полігону є дві сторони; одна з них називається лицьовою, а інша зворотною. Зазвичай зворотні сторони полігонів ніколи не видно. Це відбувається через те, що більшість об'єктів сцени є суцільними об'ємними тілами, такими як ящики, циліндри, цистерни, персонажі і т.д. і камера ніколи не потрапляє всередину займаного об'єктом простору. Тому камера ніколи не може побачити зворотні сторони полігонів. Це дуже важливо знати, тому що, якщо ми дамо можливість бачити зворотні сторони полігонів, видалення невидимих поверхонь не буде працювати.

На рис. 1.20 показаний об'єкт в просторі виду, лицьова сторона кожної грані якого позначена стрілкою. Полігон, лицьова сторона якого звернена до камери, називається фронтальним полігоном, а полігон, лицьова сторона якого звернена від камери, називається зворотним полігоном.

Рис. 1.20 — Об'єкт з фронтальними і зворотними полігонами Дослідивши рис. 1.20 можна побачити, що фронтальні полігони приховують зворотні полігони, що знаходяться за ними. Тому зворотні полігони виключаються з подальшої обробки, цей процес називається видаленням невидимих граней. На рис. 1.21 показаний той же самий об'єкт, але вже після видалення невидимих граней. Камера буде все одно показувати ту ж саму сцену, оскільки зворотні грані приховані і в будь-якому випадку їх не можна побачити.

Рис. 1.21 — Сцена після відкидання невидимих граней Освітлення Джерела світла описуються в світовому просторі, але потім перетворяться в простір виду при відповідному перетворенні сцени.

У просторі виду джерела світла застосовуються для освітлення об'єктів сцени, що дозволяє одержати більш реалістичний вигляд.

Відсічення Після виконання попередніх кроків необхідно відкинути геометрію, яка знаходиться поза видимим простором, цей процес називається відсіченням.

Є три варіанти розміщення трикутної грані щодо усіченої піраміди видимого простору:

Повністю всередині - якщо трикутник повністю знаходиться всередині області видимого простору, він переходить на наступний етап.

Повністю зовні - якщо трикутник знаходиться повністю поза пірамідою видимого простору, він виключається з процесу подальшої обробки.

Частково всередині (частково зовні) — якщо всередині піраміди видимого простору знаходиться тільки частина трикутника, то він розбивається на дві частини. Частина, яка знаходиться всередині піраміди видимого простору залишається, а частина, яка знаходиться зовні - відкидається.

Всі три розглянутих варіанти зображені на рис. 1.22.

Рис. 1.22 — Відсічення геометрії яка знаходиться поза видимим простором Проекція Після виконання попередніх етапів залишається завдання отримання двомірного представлення тривимірної сцени. Процес переходу від n-мірного простору до (n-1)-мірного називається проекцією. Існує безліч способів виконати проекцію, але в даному випадку використовується лише один спосіб, який називається перспективною проекцією. Перспективна проекція виконується таким чином, що об'єкти, розташовані далі від камери виглядають меншими, ніж об'єкти того ж розміру, що знаходяться ближче до камери. Цей тип проекції дозволяє представити тривимірну сцену у вигляді двомірного зображення. На рис. 1.23 показана точка в тривимірному просторі, що проектуються на площину проекції з використанням перспективної проекції.

Рис. 1.23 — Проекція точки у тривимірному просторі в вікно проекції

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

Рис. 1.24 — Прямокутник порту перегляду Растеризація Після перетворення вершин в екранні координати, утворюється список двовимірних трикутників. Етап растеризації відповідає за обчислення кольорів окремих пікселів, що утворюють трикутники (рис. 1.25).

Рис. 1.25 — Растеризація трикутника на екрані

Процес растеризації вимагає виконання величезного обсягу обчислень для виконання яких завжди використовується процесор відеокарти. Кінцевим результатом етапу растеризації є двовимірне зображення, що виводиться на екран монітора.

1.7.2 Програмований конвеєр візуалізації

З появою графічних процесорів стало можливим програмування деяких етапів конвеєра візуалізації. Програмування цих етапів здійснюється шляхом створення невеликих програм, які називаються шейдерами. Шейдери дозволяють визначити вхідні і вихідні дані кожного програмованого етапу в графічному процесорі, а також яка обробка буде виконуватися всередині кожного етапу. Застосовуючи шейдери можна створити безліч нових ефектів які були неможливі при використанні фіксованого конвеєра.

В XNA без використання шейдерів не можлива візуалізація будь-якого тривимірного об'єкта, тому що XNA не підтримує фіксований конвеєр візуалізації. Це викликано тим, що XNA призначений для цільових платформ Windows і Xbox 360, а апаратура Xbox 360 не підтримує повністю фіксований конвеєр візуалізації[9].

Схема програмованого конвеєра візуалізації який використовується в Microsoft XNA зображена на рис. 1.26.

Рис. 1.26 — Конвеєр візуалізації XNA

1.8 Шейдери

Шейдер — це програма для одного із ступенів графічного конвеєра, що використовується в тривимірній графіці для визначення остаточних параметрів об'єкта чи зображення. Вона може включати в себе довільної складності опис поглинання та розсіювання світла, накладення текстури, віддзеркалення і заломлення, затінення або освітлення, зміщення поверхні чи ефекти пост-обробки та ін.

На даний момент шейдери поділяються на три типи: вершинні, геометричні, і піксельні (фрагментні).

Вершинний шейдер оперує даними вершин багатогранників. До таких даних, зокрема, відносяться координати вершини в просторі, текстурні координати, тангенс-вектор, вектор бінормалі, вектор нормалі та ін. Вершинний шейдер може бути використаний для видового і перспективного перетворення вершин, генерації текстурних координат, розрахунку освітлення і т. д.

Геометричний шейдер, на відміну від вершинного, здатний обробити не лише одну вершину, але і цілий примітив. Це може бути відрізок (дві вершини) і трикутник (три вершини), а за наявності інформації про суміжні вершини може бути оброблено до шести вершин для трикутного примітиву. Крім того геометричний шейдер здатний генерувати примітиви «на льоту», не залучаючи при цьому центрального процесора. Вперше почав використовуватися на відеокартах Nvidia серії 8.

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

1.8.1 Вершинні шейдери

При візуалізації тривимірної графіки інформація про вершини передається графічному обладнанню через API візуалізації. Як тільки ця інформація отримана, відеокарта виконує програму вершинного шейдера для кожної вершини. На рис. 1.27 показана обумовлена специфікацією функціональна діаграма реалізації вершинних шейдерів 2.0.

Рис. 1.27 — Функціональна діаграма архітектури обладнання для вершинних шейдерів Як видно на рис. 1.27, вершини надходять потоком, який надається розробником через API тривимірної візуалізації. Потік містить всю інформацію, необхідну для правильної обробки геометрії в процесі візуалізації, таку як координати місця розташування, кольору і координати текстури. Інформація яка надійшла поміщається у відповідні вхідні регістри від v0 до v15 і може використовуватися програмою вершинного шейдера. Це означає, що кожна вершина обробляється індивідуально і її опис може містити до 16 блоків інформації, переданих через вхідні регістри. Програма вершинного шейдеру має доступ до багатьох інших регістрів, необхідних їй для виконання свого завдання, що складається в отриманні вхідних даних, їх обробці та перетворенні у форму, яка використовується піксельним шейдером для виконання підсумкової візуалізації.

1.8.2 Піксельні шейдери

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

Рис. 1.28 — Функціональна діаграма архітектури обладнання для піксельних шейдерів Як видно з діаграми на рис. 1.28, апаратура передає обчислені пікселі через вхідні регістри кольору і регістри текстури. Ці значення обчислюються шляхом перспективної інтерполяції значень, сформованих вершинним шейдером. Регістри v0 і v1 призначаються для інтерполяції розсіюючих і відбиваючих компонентів освітлення. Регістри з t0 по tN містять інтерпольовані координати перегляду текстури. Можна помітити, що на рис. 1.28 до регістрів текстури йдуть двонаправлені стрілки. Це пояснюється конструкторським рішенням, яке дозволяє виконувати запис у регістри текстури і використовувати їх в якості тимчасових регістрів. І, нарешті, регістри з s0 по sN вказують на текстури з яких піксельний шейдер здійснюватиме вибірку під час обробки пікселя. Хоча призначення цих регістрів явно зазначено, вони можуть застосовуватися для передачі від вершинного шейдера до піксельного будь-якої інформації.

Вихідні регістри, такі як oC0 і oDepth, використовуються апаратурою при візуалізації підсумкового пікселя. Вони визначають підсумковий колір, затуманення і глибину. Після того, як дані пікселя пройшли через піксельний шейдер, вихідна інформація використовується для змішування з вмістом вторинного буфера, який потім буде показано на екрані.

1.9 Шейдерні мови програмування

Як видно із назви пункту, шейдерні мови програмування створені виключно для програмування шейдерів, вони зазвичай містять спеціальні типи даних, такі як матриці, семплери, вектори, а також набір вбудованих змінних і констант для зручної інтеграції зі стандартною функціональністю 3D API. Оскільки комп’ютерна графіка має безліч сфер застосування, для задоволення різних потреб було створено велику кількість різноманітних шейдерних мов.

Найпершою з реалізованих шейдерних мов була мова RenderMan, яка є фактичним стандартом для професійного рендеринга. API RenderMan, розроблений Робом Куком, використовується з 1986 р. у всіх роботах студії Pixar.

Проте дана мова програмування як і її ідейні нащадки (такі як наприклад мова NVIDIA Gelato) використовується виключно у професіональному рендирингу, а це значить, що ці шейдерні мови орієнтовані на досягнення максимальної якості візуалізації. Обробка шейдерів написаних на цих мовах зазвичай є ресурсномістким завданням. Сукупна обчислювальна потужність, необхідна для забезпечення їх роботи, може бути дуже велика, оскільки шейдери написані на даних мовах використовується для створення фото реалістичних зображень. Основна частина обчислень при подібній візуалізації виконується великими комп’ютерними кластерами. Для роботи з тривимірною графікою яка генерується в реальному часі використовують дещо інший набір шейдерних мов.

Шейдерна мова Cg

Розроблено nVidia спільно з Microsoft. Cg розшифровується як C for Graphics. Мова дійсно дуже схожа на C, вона використовує схожі типи даних наприклад int, float, а також спеціальний 16-бітний тип з плаваючою комою — half. Підтримуються функції і структури. Незважаючи на те, що мова розроблена nVidia, вона без проблем працює і з відеокартами ATI.

Шейдерна мова GLSL

В OpenGL використовується шейдерна мова GLSL яка заснована на мові ANSI C. У мову включені додаткові функції і типи даних, наприклад для роботи з векторами і матрицями. Однак через її специфічну спрямованість, також було виключено багато можливостей, з метою спрощення мови та підвищення продуктивності.

Шейдерні мови DirectX

DirectX підтримує дві шейдерні мови, низькорівневу DirectX ASM та високорівневу HLSL.

Низькорівнева шейдерна мова DirectX ASM по синтаксису подібна до асемблера. Існує кілька версій, що розрізняються по набору команд, а також по необхідному устаткуванню.

Високорівнева мова HLSL є надбудовою над DirectX ASM. По синтаксису мова HLSL подібна до C, дозволяє писати код з використанням структур, процедур і функцій, після написання код транслюється в асемблер, який розуміється графічним пристроєм.

Так як компоненти XNA які працюють з графікою є надбудовою над Direct3D, вся тривимірна і частково двовимірна графіка яка створюється з використанням Microsoft XNA містить в собі шейдери написані на мові HLSL. Слід зауважити, що в бібліотеці класів XNA є клас BasicEffect, який дозволяє програмувати шейдери, не використовуючи HLSL, Однак насправді цей клас просто передає дані внутрішньому процесу HLSL.

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

В результаті досліджень сучасних API для програмування тривимірної графіки, і деяких особливостей роботи з ними, а саме програмування тривимірних сцен, віртуальної камери, робота з конвеєром візуалізації і т.д. встановлено, що найбільш ефективним для швидкої розробки тривимірного ігрового додатку є використання технології Microsoft XNA.

Досліджено поняття і можливості використання вершинних та піксельних шейдерів з метою удосконалення графічної частини ігрового додатку, за результатами якого реалізована система постобробки зображення та система динамічного накладання текстур на тривимірні об'єкти.

РОЗДІЛ 2. РОЗРОБКА ТА РЕАЛІЗАЦІЯ ІГРОВОГО ДОДАТКУ

2.1 Технічне завдання

2.1.1 Опис проекту

Розробка тривимірного ігрового додатку з використанням технології Microsoft XNA, який включає в себе високоякісну тривимірну графіку реалізовану з використанням набору шейдерних ефектів, пост обробкою зображень, та системами часток, і реалізує нестандартний ігровий процес зав’язаний на маніпулюванні гравцем об'ємними сферами в тривимірному просторі.

2.1.2 Етапи розробки

Розробка концепції ігрового додатку, технічне завдання;

Проектування та розробка основних програмних компонентів для роботи з тривимірною та двовимірною графікою;

Розробка механізму пост обробки зображень;

Реалізація систем часток;

Проектування та розробка об'єктів ігрового процесу;

Програмування механізмів взаємодії ігрових об'єктів між собою та безпосередньо з гравцем;

Програмування логіки ігрового процесу;

Проектування та реалізація користувацького інтерфейсу;

Тестування та усунення недоліків програмного коду.

2.1.3 Характеристика ігрового процесу

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