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: 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>

*

*