Game development: Фізика в іграх / Можливості існуючих движків

МОЖЛИВОСТІ ІСНУЮЧИХ Движки

НЕ МАЄ СЕНСУ БАГАТО ГОВОРИТИ ПРО ТЕ, ЩО В СУЧАСНИХ ІГРАХ ДУЖЕ ЧАСТО ВИКОРИСТОВУЮТЬСЯ ФІЗИЧНІ СИМУЛЯЦІЇ РІЗНОГО РОДУ. ФІЗИКА ВЖЕ ДАВНО (І НАДОВГО) протоптав стежку в симуляторі, В ОСНОВНОМУ АВТОМОБІЛЬНІ

Фізика використовується і як основний елемент геймплея (хардкорні симулятори), і як засобу до отримання додаткових емоцій у гравця (різного роду руйнування). Також є ряд жанрів, в яких масове застосування фізики почалося порівняно недавно – це перш за все шутери та ігри з видом від третьої особи. Спектр використання фізичних ефектів в них дуже широкий: від досить простих rag-dolls і пінанія скриньок до спроб зав'язати частина геймплея на фізику (Half-life 2, Psi-ops і т.д.). Крім усього перерахованого, існує ряд ігрових жанрів, в яких фізика не потрібна в принципі, наприклад в покрокових глобальних стратегіях. У цілому на сьогодні фізика в іграх є найважливішим елементом, але незважаючи на це розкручена не так, як графіка.

трохи термінології

фізичний движок (ФД)

ФД – бібліотека, яка розраховує фізичні взаємодії між об'єктами ігрового світу (симулюється фізика, описувана законами Ньютона). Фізичні рушії, використовувані при розробці ігор, як правило, не симулюють фізичні процеси ігрового світу з 100% точністю, а лише виробляють достатньо точну апроксимацію фізичних законів. Сучасні ігрові фізичні рушії складаються з двох частин: підсистеми визначення зіткнень і підсистеми розрахунку фізичних взаємодій.

підсистема визначення зіткнень

Основні два параметри підсистеми визначення зіткнень: швидкість роботи і точність визначення зіткнень. Недостатня точність призводить до появи різних артефактів, таких як перекриття об'єктів, невизначення зіткнень при істотно різних розмірах і швидкостях об'єктів і т.д. Для прискорення роботи підсистеми зіткнень використовують різного роду розбиття простору на підпростору, такі як quadtree (рекурсивне розподіл простору на чотири підпростору) або осtree (поділ на вісім підпросторів), для зниження кількості перевірок зіткнень. Системи зіткнень працюють дискретно – зіткнення розраховуються через певні проміжки часу. Отже, такого роду системи можуть приводити до того, що зіткнення з участю швидко рухомих об'єктів не фіксуються – для боротьби з подібного роду артефактами деякі системи зіткнень підтримують так званий continuous collision detection (CCD) (системи безперервного відстеження зіткнень). Суть методу continuous collision detection полягає в тому, що перевірка зіткнень між двома об'єктами проводиться не між ними самими в дискретні моменти часу, а між витягнутими обсягами, які представляють рух об'єктів протягом усього часового кроку.

підсистема симуляції (пс)

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

Переважна більшість фізичних движків може (з різним успіхом) симулювати фізику твердого тіла (Rigid body simulation). Тверде тіло – це тіло, яке не змінює свою форму (до них можна віднести цегла, стіл, стіну і т.д.). На даний момент переважна більшість ігор використовує саме фізику твердого тіла, головним чином тому, що з прийнятною продуктивністю може обраховуватися лише фізика твердого тіла. Для представлення об'єму твердих тіл, в залежності від движка, можуть використовуватися як різні примітивні тіла (прямокутники, сфери, циліндри, конуси тощо), так і більш складні (карти висот, опуклі багатогранники або неопуклі багатогранники). Якщо використовуються тільки примітивні тіла, більш складні тіла описуються за допомогою апроксимації примітивами. Для опису властивостей твердих тел використовується поняття матеріалу, який описується параметрами: коефіцієнт тертя (може бути два: коефіцієнт тертя спокою, який показує, як важко зрушити тіло, і коефіцієнт тертя руху, який показує, як важко утримувати тіло в русі), пружність (скільки енергії залишається після зіткнення з іншим тілом). Крім цих параметрів, можуть бути й інші. Тверде тіло також має масу. Рух твердих тіл описується за допомогою лінійної, кутовий швидкості і прискорення. Хоча Пакети дозволяють встановлювати ці параметри безпосередньо, впливу на тіла, як правило, здійснюють за допомогою програми або фізичних сил (впливають на прискорення тіл), або імпульсів (впливають на швидкості).

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

Джоінт – це точка, яка з'єднує два твердих тіла (з'єднання зазвичай задається відносно точки джоінта) і накладає обмеження на положення тіл у просторі один відносно одного або на швидкості тіл відносно один одного. Типів джоінтов багато (деякі Пакети дозволяють писати власні). Для реалізації регдолов використовують ball-joint і hinge-joint. Ball-joint – це шарнірне з'єднання двох тіл, воно обмежує переміщення тіл один відносно одного і накладає обмеження на те, як повернені тіла відносно один одного по трьох осях (за допомогою джоінтов такого типу в регдолле кріпиться плече або голова до тіла). Hinge-joint – це петельні з'єднання двох тіл, яке обмежує повороти тіл відносно один одного однією віссю. У цілому ж спектр застосування джоінтов дуже широкий і не обмежується тільки створенням rag-dolls.

Крім фізики твердого тіла, різні фізичні рушії можуть реалізовувати додаткові можливості: спеціальну підтримку симуляції руху автомобілів, симуляцію води і інших рідин, симуляцію тканин і одягу, симуляцію частинок, додаткову підтримку для симуляції персонажів – високорівневі контролери персонажів, вбудовану підтримку rag-dolls, підтримку анімації і т.д.

фізика і розробка гри

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

Як робити фізику – це питання потребує вирішення. На одному полюсі – рішення про те, щоб писати фізику самостійно. На іншому полюсі – покупка готового рішення, яке повністю покриє спектр поставлених завдань. Десь посередині знаходиться такий варіант: модифіковані існуючий, але далеко не на 100% відповідний движок. Як і в інших областях розробки ПЗ, дане рішення залежить від безлічі факторів: наявності коштів, наявності персоналу, наявності відповідних рішень і т.д.

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

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

Додавання фізики в гру ускладнює процес розробки продукту і вимагає додаткових ресурсів.

огляд існуючих рішень

До недавнього часу ситуація на ринку фізичних движків була досить стабільна. Існувало декілька безкоштовних фізичних движків (різної якості), а також ряд комерційних фізичних движків. Однак в минулому 2005 році компанія AGEIA анонсувала перший в історії ігрової індустрії прискорювач фізики, який знімає з центрального процесора завдання розрахунку фізики. Прискорювач поки ще не з'явився в продажу, але його творці стверджують, що їхній продукт буде здатний обраховувати близько 40 000 об'єктів (на даний момент кількість фізичних об'єктів, обраховується на ПК, складає десятки).

Нижче розглянемо основні фізичні рушії, які існують на сьогодні. Крім чисто фізичних движків, існує маса ігрових движків, які містять фізичні підсистеми, написані поверх однієї з бібліотек (на www.devmaster.net / engines можна ознайомитися з ігровими движками).

PhysX (www. ageia.com, комерційний)

Ця фізична технологія надається компанією AGEIA і як фізичний движок, і як АПИ для роботи з їх фізичним прискорювачем. На даний момент ряд ігрових компаній заявили про підтримку цієї технології у своїх продуктах (у тому числі Unreal Engine).

Можливості PhysX:

СИМУЛЯЦІЇ ТВЕРДИХ ТІЛ, ЯК ФІЗИЧНОГО УЯВЛЕННЯ МОЖУТЬ ВИКОРИСТОВУВАТИСЯ примітивів (ПЛОЩИНІ, БОКСИ, КАПСУЛИ) І опуклі многокутники, А ТАКОЖ ЇХ КОМБІНАЦІЇ;

Повністю настроюється ДЖОІНТИ із шістьма ступенями свободи;

Симуляція рідин;

ФІЗИЧНЕ ВЗАЄМОДІЯ МІЖ рідинами і твердими тілами;

КОНТРОЛЕРИ ПЕРСОНАЖІВ (ПЕРСОНАЖ МОЖЕ складаються з боксів та капсул), дозволяє автоматично переміщається по сходах;

АВТОМОБІЛІ НА ОСНОВІ ТРЕЙСІНГА променя;

ПІДТРИМКА КІЛЬКОХ СЦЕН;

СИСТЕМА ЗІТКНЕННЯ ПІДТРИМУЄ безперервне відстеження ЗІТКНЕНЬ;

Мультиплатформність;

Багаторівнева.

Havok (www.havok.com, комерційний)

Один з найстаріших фізичних движків. На ньому зроблені десятки ігор (подивитися їх список можна за адресою www.havok.com/content/blogcategory/29/73). Нещодавно Havok анонсував нову технологію розрахунку фізики Havok FX, яка провадить розрахунки фізики на відеокартах використовуючи шейдери 3.0.

Можливості Havok:

? ФІЗИКА ТВЕРДОГО ТІЛА;

? ДЖОІНТИ;

? СИСТЕМА ЗІТКНЕННЯ ПІДТРИМУЄ безперервне відстеження ЗІТКНЕНЬ;

? ПІДТРИМКА СИМУЛЯЦІЇ АВТОМОБІЛІВ;

? RAG-DOLLS;

? КОНТРОЛЕРИ ПЕРСОНАЖІВ (ДОЗВОЛЯЮТЬ ПЕРСОНАЖІВ ПЕРЕМІЩУЮТЬСЯ по сходах);

? Мультиплатформність;

? Багаторівнева.

Trueaxis (www.trueaxis.com)

Безкоштовний для некомерційного використання. Ісходникі закриті.

Можливості:

? ФІЗИКА ТВЕРДОГО ТІЛА;

? СИСТЕМА ЗІТКНЕННЯ ПІДТРИМУЄ безперервне відстеження ЗІТКНЕНЬ;

? В ЯКОСТІ УЯВЛЕННЯ МОЖУТЬ ВИКОРИСТОВУВАТИСЯ опуклі многокутники, КАПСУЛИ, ЦИЛІНДРИ І СФЕРИ;

? ПІДТРИМКА СИМУЛЯЦІЇ АВТОМОБІЛІВ;

? ДЖОІНТИ.

ODE (www.ode.org, BSD, вихідні коди відкриті)

Єдиний в списку движок з відкритим кодом, що дозволяє йому служити в якості бази для побудови власного фізичного движка (відомий проект STALKER використовує модифікований ODE), а також просто для вивчення того, як воно все всередині влаштовано. ODE дуже часто використовується різними ігровими движками в якості фізичного підсистеми.

Можливості:

? ФІЗИКА ТВЕРДОГО ТІЛА;

? ДЖОІНТИ;

? СИСТЕМА ЗІТКНЕНЬ Відокремлений від ФІЗИЧНОЇ СИМУЛЯЦІЇ, що дозволяє інтегрувати ODE З РІЗНИМИ СИСТЕМАМИ ЗІТКНЕНЬ.

Tokamak (www.tokamakphysics.com, безкоштовні, вихідні коди закриті)

Можливості:

? ФІЗИКА ТВЕРДОГО ТІЛА;

? ДЖОІНТИ (всього два види: BALL І HINGE – ДОСИТЬ ДЛЯ ПОБУДОВИ RAG-DOLLS).

Newton (www.physicsengine.com, безкоштовні, вихідні коди закриті)

Можливості:

? СИСТЕМА ЗІТКНЕННЯ ПІДТРИМУЄ безперервне відстеження ЗІТКНЕНЬ;

? ФІЗИКА ТВЕРДОГО ТІЛА;

? RAG-DOLLS;

? ПІДТРИМКА СИМУЛЯЦІЇ АВТОМОБІЛІВ.

фізика на прикладі

Для практичного прикладу візьмемо демонстраційну програму з OPAL (open physics abstraction layer: http://ox.slug.louisville.edu/opal/wiki) – це відкритий фізичний движок, що надає єдиний високорівнева інтерфейс для роботи з іншими фізичними движками. На даний момент існує єдина реалізація поверх ODE, в розробці знаходиться оболонка над TrueAxis. Для роботи необхідно завантажити сам движок – Http://prdownloads.sourceforge.net/opal/opal-0.3.1-src.zip?download.

Нас цікавить дему, яка знаходиться в папці opal-0.3.1-srcsamplessimple і показує базові аспекти роботи з фізичним движком OPAL, демонструючи роботу з твердими тілами. Як візуалізатора використовується бібліотека SDL (www.libsdl.org / index.php). Додаток складається з єдиного файлу main.cpp і декількох h-ков. При старті з'являється статичний бокс. При натисканні клавіші «пробіл» на цей бокс падають тверді тіла, що подаються за допомогою різних примітивів. Розгляну файл main.cpp і прокоментую ті його частини, які відносяться до фізичної симуляції.

Лістинг

набір глобальних змінних

std::vector<opalSamples::Entity*> gEntities;

opal::Simulator* gSimulator = NULL;

Змінна gSimulator типу opal:: Simulator вказує на екземпляр фізичного движка OPAL. Тип opal:: Simulator – власне, і є сам фізичний движок. Він інкапсулює всередині систему розрахунку зіткнень і підсистему розрахунку фізики. Як правило, у додатку достатньо одного примірника фізичного движка. Подібного роду архітектура, при якій існує якийсь об'єкт, що містить інформацію про всіх фізичних об'єктах ігрового світу, і виробляє обрахування фізики і використовується практично у всіх високорівневих фізичних движках.

Змінна gEntities містить список сутностей типу opalSamples:: Entity, які мають фізичне уявлення. Сам клас і його спадкоємці мало цікаві, тому що вони в даній програмі служать для відтворення сімуліруемих об'єктів. У самому класі opalSamples:: Entity цікавить нас одне поле – opal:: Solid * mSolid. Тип opal:: Solid представляє тверде тіло у фізичному движку OPAL. Тверде тіло має позицією, швидкістю, прискоренням і є базовою одиницею симуляції – такого роду сутність є в будь-якому фізичному движку. У даній програмі для малювання сутності необхідно знати позицію твердого тіла – ця інформація отримується шляхом виклику методу getTransform у mSolid.

Лістинг

вміст функції main

gSimulator = opal::createSimulator();

gSimulator->setGravity(opal::Vec3r(0, (opal::real)-9.81, 0));

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

Лістинг

1. opal::Solid* platformSolid = gSimulator->createSolid();

2. platformSolid->setStatic(true);

3. opal::BoxShapeData boxShape;

4. boxShape.dimensions = gGroundDimensions;

5. platformSolid->addShape(boxShape);

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

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

У третьому рядку створюємо екземпляр структури boxShape, яка описує тривимірний прямокутник (бокс).

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

Лістинг

Matrix44r offset;

Material material;

Поле offset задає зсув фігури відносно центру твердого тіла, поле material задає властивості матеріалу фігури. У OPAL "е матеріал має наступні властивості:

hardness – від 0 до 1. Показує, наскільки припустимо перекриття обсягів тел.

friction – від 0 до 1, тертя руху. Чим більше це значення, тим швидше буде зупинятися рухається тіло.

bounciness – від 0 до 1, пружність. Чим більше значення, тим більше енергії буде поглинатися при зіткненні.

density – щільність матеріалу. На підставі цього параметра і обсягу фігури обчислюється маса фігури.

Лістинг

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

while (!gQuit)

{

opal::real dt = (opal::real)timer.getElapsedSeconds();

gQuit = processInput();

if (!gPaused)

{

gSimulator->simulate(dt);

}

}

Нам цікавіше за все ось ця рядок:

Лістинг

gSimulator->simulate(dt);

У метод simulate передаємо єдиний параметр – час, який пройшов у «фізичному світі». Саме всередині цього виклику відбувається розрахунок зіткнень і розрахунок взаємодії фізичних об'єктів, відбувається оновлення позицій, швидкостей і т.д.

Лістинг

gSimulator->destroy();

Заключна рядок програми викликає метод destroy об'єкта-симулятора, тим самим звільняючи всі ресурси, зайняті ним, і знищуючи всі фізичні об'єкти, створені через методи симулятора, подібні createSolid.

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


Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*