УДК 004.415.2.22 © 2010 р. В.С.Семенякін, Т.М.Заболотня

Національний технічний університет України «Київський політехнічний інститут», м.Київ, Україна МОДИФІКОВАНИЙ ОБ’ЄКТНООРІЄНТОВАНИЙ ПІДХІД ДО ПОБУДОВИ ПРОГРАМНИХ ЗАСОБІВ МОДЕЛЮВАННЯ ФІЗИЧНИХ ПРОЦЕСІВ

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

This article is devoted to the question of development of the architecture for physical processes modeling. The new SIM approach to the organization of simulation space’s objects is pro- posed. It is oriented to the maximum abstraction of the latter. Basic steps of software creating accord- ing to the described approach are defined. SIM architecture of the is implemented and its modification for enhance the effectiveness of physical objects processing algorithms on the criteria of speed performance is considered. The software implementation of major classes of the physical en- gine is done based on the SIM architecture.

Вступ грамного моделювання фізичних процесів є У галузі створення сучасної анімації і розро- актуальною задачею. бки комп’ютерних ігор все частіше виникає З огляду на вищезазначене метою даної ро- необхідність у побудові програмних систем, боти є створення відкритого до розширення здатних реалістично відтворювати різні фізичні функціонального ядра програмних засобів для явища. Використання таких систем сприяє зна- моделювання фізичних процесів. чному прискоренню процесу створення Відповідно до вказаної мети в роботі поста- комп’ютерної мультиплікації, оскільки автома- влені і розв’язані такі задачі: тизована обробка «фізики» знімає необхідність - визначення підходу до побудови та роз- відтворення останньої вручну. В комп’ютерних робка базової архітектури фізичного движка; іграх програмне моделювання фізичних проце- - модифікація отриманої архітектури для сів дозволяє зробити графічне зображення вір- забезпечення реалізації ефективних за критері- туального світу максимально подібним до реа- єм швидкодії алгоритмів обробки фізичних льного світу. об’єктів. Існуючі у даній галузі програмні рішення здатні відтворювати закони динаміки, статики, 1. Огляд існуючих рішень гідродинаміки, фізики газів, тканин тощо. Всі Програмний комплекс, що реалізує симуля- вони мають оптимізований щодо часу виконан- цію фізичних законів реального світу з деякою ня код і, як правило, можуть виконувати моде- ступінню апроксимації, називається фізичним лювання фізичних законів в реальному часі. движком [1]. Під симуляцією в даному випад- Їх спільним недоліком є архітектура, що до- ку будемо розуміти програмну імітацію фізич- зволяє працювати з описами лише заданого за- ного процесу або об’єкта [2]. здалегідь спектра законів фізики. Робота з да- Поняття архітектура програмного забезпе- ними, які стосуються інших областей фізики, чення включає в себе: або неможлива, або потребує перебудови дви- 1. Набір значущих рішень з приводу ор- жка. Тому пошук нових рішень у галузі про- ганізації системи програмного забезпечення.

1 2. Набір структурних елементів та їх Слід помітити також, що в системі класів інтерфейсів, за допомогою яких компонується усіх движків, що розглядаються, існує поняття система, разом з їх поведінкою, що визначаєть- зв’язків (joints), які описують взаємодію між ся взаємодією між цими елементами. двома об’єктами. Але для жодного з движків 3. Компоновку елементів у підсистеми, можливість створення користувацьких joints-ів що поступово розширюються. не розглядалася як головна ідея побудови архі- 4. Стиль архітектури, котрий спрямо- тектури движка. вує цю організацію – елементи та їх інтерфей- Таким чином, можна зробити висновок, що си, взаємодії та компоновку [3]. за ідеєю розробників архітектура вищезгада- Статичною будемо називати таку архітек- них движків є статичною. туру фізичного движка, що не підтримує (або  APE [10] – відкритий, дещо застарілий робить складною) можливість підключення до фізичний движок. нього бібліотек обробки даних щодо фізичних Побудова: Движок не має структури, що законів або колекцій законів з цілих розділів описує об’єкт фізичного простору. Є набір ал- фізики. горитмів і класів для фізичного моделювання, Проаналізуємо існуючі фізичні движки з то- та пошук колізій між формами, що описуються чки зору їх архітектури: багатокутниками. З метою спрощення роботи у  – зручний у використані та ефе- APE введене поняття груп, у які розробник мо- ктивний з точки зору швидкодії движок з відк- же об’єднувати об’єкти. ритим кодом. Існують його реалізації різними Архітектура движка є незакінченою: взагалі мовами, у тому числі ActionScript. Вважається не описане поняття фізичного об’єкту. На ос- одним з кращих двовимірних движків [4, 5]. нові движка можлива реалізація гнучкої до ро-  NAPE [6, 7] – новий відкритий движок; зширення архітектури, але на досліджуваному зараз закінчується розробка, але вже йде широ- етапі розробки APE фактично є лише калькуля- ке застосування. Автор движка анонсував реа- тором фізичних законів. лізацію широкого спектру фізичних законів – Примітка 1: У даному огляді не наведена ін- не лише механіки, зокрема йдеться про симу- формація про комерційні движки через те, що ляцію води [8]. їх програмний код є закритим, а, отже, немож-  ODE (Open Dynamics Engine) [9] – відк- ливо детально розглянути їх архітектуру. Од- ритий, частково безкоштовний тривимірний нак, слід згадати такі движки як PhysX і , фізичний движок, орієнтований на реалістичне що є одними з найкращих комерційних рішень відтворення складних з’єднань (шарнірів, пру- в області моделювання фізичних об’єктів (вони жин, тощо). використовують апаратну оптимізацію і пара- Побудова вищезгаданих движків. Головний лельне програмування для прискорення обчис- контейнер містить у собі менеджери, напри- лень). клад: менеджер обробки колізій, розподільник Судячи з прикладів коду програмних проду- пам’яті движка (потрібен для реалізацій движ- ктів, що їх використовують [11, 12], архітекту- ків на нескриптових мовах програмування), а ра цих движків також є статичною. також список об’єктів та список осей, що їх фі- Примітка 2: Також слід згадати програмний ксують. Вищезгадані менеджери описані в продукт Phun та його комерційну версію – окремих класах. Програмні об’єкти, що збері- [13]. Останній здатен моделювати гають динамічні властивості, містять велику процеси, напевне, найбільшого спектру розді- кількість даних щодо фізичних властивостей лів фізики серед усіх сучасних систем програм- тіла і одночасно виконують роль об’єктів вірту- ного моделювання: динаміки, статики, гідроди- ального простору. Це робить опис нових для наміки та оптики. Мінусом є закритість систе- движка властивостей незручним у використан- ми. ALGODOO не є бібліотекою моделювання ні. «фізики», це закінчений програмний продукт з Відтворення фізичного впливу на об’єкт мо- реалізованим графічним інтерфейсом. делювання у коді здійснюється за допомогою Таким чином, доцільним є проведення дос- виклику спеціальних функцій додавання сил та лідження можливості створення програмної імпульсів. системи моделювання фізичних процесів з об’єктами, що є максимально абстрагованими.

2 2. Обґрунтування ідеї побудови движка нього: правила можна додавати до об’єкту, але Об’єкт віртуального простору доцільно їх набір не може бути фіксованим. визначати, включаючи до його структури екзе- Поставлені задачі не можуть бути реалізова- мпляри класів-контролерів, що описують певні ні з використанням лінійних відношень між ідейно різні сутності об’єкту - зони відповіда- класами. Вони потребують розробки більш роз- льності. Така побудова проекту робить код галуженої, ієрархічної архітектури програмних проекту більш структурованим і зручним. засобів. У нашому випадку об’єкт віртуального про- стору включатиме в себе екземпляр графічного 3. SIM підхід об’єкту, зоною відповідальності якого є оброб- У даній статті пропонується підхід до побу- ка зовнішнього вигляду об’єкту (графічний дови архітектури програмних комплексів, реа- об’єкт не буде розглянутий детально у даній лізація якого дозволить гнучко редагувати на- статті), і екземпляр фізичного об’єкту, що буде бори використовуваних властивостей та мето- здійснювати контроль фізичної складової дів об’єктів. Новий підхід – SIM підхід (Shell- об’єкту. Influence-Model) – побудований на основі Фізичним об’єктом будемо називати суку- об’єктноорієнтованої парадигми програмуван- пність двох складових: набору властивостей ня, ідеї так званого предметноорієнтованого об’єкту (положення у просторі, маса, швидкість підходу до програмування (subject-oriented тощо), і законів (правил), що впливають на programming) [14] та використанні шаблону об’єкт (закон тяжіння, правило пружного зітк- проектування стратегія [15]. В межах SIM по- нення твердих тіл тощо). ведінка об’єктів і групи властивостей (принцип Найбільш поширеним підходом щодо реалі- об’єднання вказаний нижче) розглядаються як зації фізичних об’єктів є об’єктноорієнтований окремі сутності. підхід (див. архітектуру будь-якого фізичного Підхід має такі особливості: движка), відповідно до якого програмний опис 1. Відокремлені групи властивостей забез- об’єкту постає у вигляді класу. Поля такого печують збереження стану об’єкту, описуючи класу є фізичними властивостями об’єкту, а параметри останнього з точки зору певного методи – функціями моделювання впливу на підрозділу предметної області. останні (приклад: вплив на об’єкт силою або 2. Відокремлена поведінка визначає вплив імпульсом). на включені до об’єкта властивості та може ре- Перевагою використання вказаної структури алізовувати одну або декілька функцій впливу програмного об’єкту є швидке створення архі- на властивості - функцій збудження. Інтерфей- тектури проекту, мінусами – відсутність гнуч- си цих функцій є спільними для усіх об’єктів кості розробки і реалізація лише фіксованого, відокремленої поведінки. визначеного заздалегідь спектру способів впли- Головна ідея підходу полягає у: ву на фізичні властивості. Така реалізація мож- 1) мінімізації розмірів коду за рахунок лива в програмних комплексах, що не потре- внесення засобів обробки складного впливу на бують відтворення складної поведінки об’єктів об’єкт (систему об’єктів) безпосередньо до або покладають її реалізацію на користувача. структури об’єкта – включенням відокремленої Реалізація більш складної поведінки об’єктів поведінки у об’єкт; базується на врахуванні законів з різних розді- 2) універсалізації опису об’єктів за раху- лів фізики та (або) відтворенні більш складних нок можливості включення до них будь-якої відношень між об’єктами. Вона потребує гнуч- комбінації властивостей без необхідності по- кої, здатної до розширення архітектури движка, двійного (або множинного) успадкування. а отже, постає необхідність максимального абс- Центральним елементом нового підходу є трагування фізичного об’єкту. Для цього: головний клас-оболонка – shell-class (у нашому 1) фізичний об’єкт не може мати однозна- випадку – фізичний об’єкт), що виступає у ролі чного набору властивостей: користувач сам по- контейнеру, який зберігає списки класів- винен визначити цей набір, включаючи їх у методів (influence-class) і класів-властивостей об’єкт за необхідності; (model-class), які будемо надалі називати напо- 2) фізичний об’єкт не може мати однозна- вненням shell-class-у (або просто наповнен- чного набору правил, що будуть впливати на ням). При цьому shell-class здійснює мінімаль- ний контроль свого наповнення: реалізовує фу-

3 нкції включення та вилучення екземплярів необхідності – методів, з якими повинен взає- influence та model –class-ів з контейнеру, а та- модіяти модуль, що розробляється. кож методи виклику спільних для класів- SIM підхід має сенс використовувати у ви- методів функцій збудження. Останній слугує падках, коли програмний комплекс, що розроб- для ініціалізації процесу обробки стану об’єкту ляється, розрахований на: включеними до нього екземплярами influence- - роботу з предметною областю, що має class-ів. багато (більше трьох) підрозділів; Розглянемо основні кроки створення проек- - здійснення стратегічного контролю ко- ту відповідно до SIM підходу: ристувачем програмного забезпечення - корис- 1. Описати абстрактні класи: базова влас- тувач задає (описує сам) блоки, що будуть тивість і базовий метод (base influence-class і впливати на стан комплексу, й після цього зда- base model-class). Вони мають описувати функ- тен викликати лише функції обробки усіх бло- ції роботи з ієрархією проекту (наприклад, з ків, не маючи безпосереднього впливу на окре- посиланнями на батьківський контейнер shell- мі складові об’єкту; class), а базовий метод повинен містити ще як - реалізацію великого спектру складних мінімум одну функцію збудження. алгоритмів у кожній окремо визначеній пред- 2. Виділити логічно відокремлені підроз- метній області. діли в обраній предметній галузі. Розглянемо побудову архітектури фізичного 3. Формалізувати виділені підрозділи, роз- движка відповідно до запропонованого SIM пі- глядаючи властивості (характеристики, параме- дходу. три) кожного з них як поля model-class-у, що його описують, а закони – як функції збуджен- 4. Розробка базової архітектури движка ня influence-class-ів. Вищезазначені компоненти Відповідно до SIM підходу роль model-class- реалізують відповідні абстракції, описані у пу- ів в архітектурі виконують описи згрупованих нкті 1. Слід відмітити, що model-class може за певними розділами (динаміка, гідродинаміка, включати деякі елементарні операції впливу на електрика, оптика тощо) фізичних властивостей власні властивості, які будуть викликатись для об’єкту (далі будемо називати їх пакетами реалізації складної поведінки в тілі функцій властивостей); influence–class-си описують збудження influence-class-ів. фізичні закони, які моделюються (закон пруж- 4. Описати shell -class, керуючись його ви- ності, закон Стокса, закон Ома, закон відбиван- значенням (див. вище). ня світла. Далі називаються законами). Shell- 5. Розробити системи перевірки валідності class-ом буде слугувати фізичний об’єкт. включень (див. розділ 4.1), орієнтовану на об- рану предметну галузь. 4.1. Перевірка валідності включень Архітектура програмних засобів, побудова- Побудована відповідно до запропонованого них відповідно до SIM підходу, є гнучкою і від- підходу архітектура движка є досить гнучкою, критою для розширень: фактично, в основі ар- але, водночас, вразливою до помилок. Для її хітектури лежить реалізація динамічного класу, коректної роботи необхідна система перевірки до якого можна у будь-який час під’єднувати валідності включення нових законів до фізич- методи і властивості, а також легко виключати ного об’єкту. їх. Така архітектура є зручною у роботі: Владним включенням будемо називати дію - для користувача: не потрібно бути обіз- включення до фізичного об’єкту такого нового наним у предметній області для створення наповнення, що не протирічить зробленим ра- складних взаємодій між об’єктами, адже доста- ніше включенням (наприклад, подвійне вклю- тньо включити у проект бібліотеки їх реаліза- чення опису однакових областей), й має у фізи- цій; чному об’єкті необхідні для коректної роботи - для розробника системи: нові закони компоненти. Прикладом, коли може виникати потребують реалізації лише конструктору, фу- помилка, є така ситуація: користувач намага- нкції збудження й опису властивостей закону. ється додати у фізичний об’єкт закон, що реалі- Відсутні проблеми з читанням величезної до- зує силу тяжіння, не додавши перед цим пакет кументації до продукту. Достатньо знати осно- властивостей динаміки. вні принципи організації і функціонування У статті пропонується два способи перевір- движка, а також структуру model-class-ів та – за ки валідності включень:

4 1. Використання класів-заголовків. Кожен 2) підвищується загальна складність сис- пакет властивостей і кожне правило оснащу- теми внаслідок наявності великої кількості до- ються заголовком, що описує умови та інфор- даткових зв’язків у ієрархії об’єктів; мацію, необхідні для валідного включення да- 3) виникає необхідність у виконанні зай- ного пакету властивостей / правила. вих обчислень або в ускладненні ієрархії (див. Переваги: Швидка реалізація класів- пояснення у Примітці 3). заголовків. Також останні можна використову- Примітка 3: Перевірка колізій шляхом пов- вати для уточнення режиму обробки правил у ного перебору потребує фізичному об’єкті. Приклад: необхідною є об- A B C N*(N-1) операцій пошуку робка сумарної швидкості після обчислення A (матриця, без головної діа- сили тертя - остання повинна зменшити швид- гоналі). Пошук можна оп- кість у декілька разів. B тимізувати, спираючись на Недоліки: Фіксованість полів у заголовку факт, що якщо А зіткнувся внаслідок того, що алгоритм обробки полів є C з В то й В зіткнувся з А статичним, призводить до необхідності розроб- (світліша область). За ра- ки складної системи додавання надбудованих хунок цього час пошук зіткнень буде зменшено алгоритмів перевірки валідності включення. у два рази. 2. Використання спеціальної функції При використанні звичайного SIM підходу у setParent( ) у пакетах властивостей і правилах. даному випадку подібну оптимізацію зробити За допомогою даної функції можна перевірити дуже складно. Можна, наприклад, ввести пра- валідність включення. Функція повертає булеве порець, що буде зберігати статус обробки зітк- значення в залежності від результату перевірки. нення і не оброблятиме надалі колізії між Переваги: Як завгодно гнучка перевірка ва- об’єктами, що зіткнулися, однак таке рішення є лідності включення – її реалізація покладається очевидно громіздким. Подібні труднощі будуть на розробника наповнення. виникати з усіма правилами, що залежать від не Недоліки: Необхідність реалізації додаткової тільки від стану об’єкту, на який впливає дане функції для розробника бібліотек движка. правило, але від стану всієї системи в цілому. На думку авторів, найбільш зручним є ком- Таким чином, реалізація простору моделю- бінований метод перевірки. У такому випадку вання у вигляді лише списку фізичних об’єктів заголовок зберігає інформацію щодо особливо- не є оптимальною. Потрібен додатковий меха- стей включення і обробки законів, а метод нізм – обгортка навколо списку об’єктів – що setParent( ) – перевіряє валідність включення. буде здійснювати менеджмент і оптимізацію Розглянемо можливість розширення отри- роботи з простором моделювання. маної базової архітектури движка з метою за- З цього слідує необхідність введення понят- безпечення ефективної за критерієм часу вико- тя фізичної системи. нання глобальної обробки фізичних об’єктів. 5.2. Фізична система 5. Модифікована SIM архітектура фізич- Фізичною системою будемо називати клас- ного движка контейнер, що включає список фізичних 5.1. Складність обробки загальних правил об’єктів, список служб та глобальних законів. Нехай є динамічна система твердих пружних Службою будемо називати деякий математич- тіл. Дана система має обмеження: об’єкти не ний (геометричний) алгоритм, обгорнутий кла- можуть проходити один через одного. Для цьо- сом на зразок правила, що здійснює обчислення го потрібен алгоритм, що буде обробляти зітк- допоміжних параметрів системи. Результат ро- нення. В чистій SIM системі подібна модель боти служби може бути використаний як пра- може бути реалізована за допомогою включен- вилом, так і деяким зовнішнім для фізичної мо- ня правил обробки зіткнень у кожний об’єкт делі об’єктом. В останньому випадку службу системи. Внаслідок цього: можна розглядати як диспетчер подій, а резуль- 1) порушується принцип інкапсуляції, тат його роботи – як подію. оскільки буде мати місце звертання до списку Глобальний закон – це influence-клас, функ- об’єктів безпосередньо із правила, що є зайвим ція збудження якого реалізує відтворення фізи- посиланням до області відповідальності іншого чних законів, що впливають одразу на всі класу; об’єкти фізичної системи.

5 Рис.1. Загальна UML-діаграма архітектури SIM движка Примітка 4: Прикладом служби може бути Запропоновано новий SIM підхід до ство- алгоритм обробки колізій. Даний алгоритм пе- рення програмних комплексів опису складних редбачає пошук геометричних перетинів тіл, систем фізичних об’єктів, розроблено базову описаних в пакеті динамічних властивостей SIM архітектуру фізичного движка, дано визна- кожного об’єкту системи. Однак результат ро- чення основних складових архітектури. Отри- боти цієї служби – список перетинів тіл - є ду- мана архітектура дозволяє спростити додавання же важливим для реалізації будь-якої динаміки до фізичного движка елементів, що описують твердих тіл. Закони, що обробляють дії об’єктів різні розділи фізики. моделі при зіткненні, можуть включати в свою Проведено першу модифікацію SIM архітек- структуру посилання на цю службу. тури з метою забезпечення реалізації ефектив- Приклад глобального закону: обробка ре- них за критерієм швидкодії алгоритмів обробки зультату зіткнень твердих тіл. Обробка повинна фізичних об’єктів, а також даних щодо загаль- виконуватись для всіх об’єктів системи, що ного стану системи, що моделюється. Результа- включають в свої описи пакети динамічних том модифікації стало введення додаткових властивостей. елементів до архітектури: фізичної системи, служби, глобального закону. Висновки Серед напрямків подальшого вивчення та На основі дослідження існуючих програм- розвитку запропонованого підходу можна виді- них засобів моделювання фізичних процесів лити такі: аргументовано доцільність модифікації загаль- - створення програмних бібліотек законів і новживаного об’єктноорієнтованого підходу до властивостей для моделювання конкретних об- створення такого роду ПЗ з метою реалізації ластей фізики; відкритого до розширення фізичного движка. - аналіз можливості побудови та викорис- тання додаткових контролерів, що описують

6 закони взаємодії між набором об’єктів і конт- 13. ALGODOO wiki [Електронний ресурс/ ролеру макросів фізичної імітації, що реалізо- http://www.algodoo.com/wiki/Home], дата візиту вують послідовну генерацію сил протягом де- 17.11.2010 якого часу (приклад: м’язи людини під час бі- 14. Subject-oriented programming [Електронний ре- гу); сурс/ http://en.wikipedia.org/wiki/Subject- oriented_programming], дата візиту 7.11.2010 - подальше удосконалення архітектури з то- 15. Pattern Strategy [Електронний ресурс чки зору зручності розробки коду на її основі. http://ru.wikipedia.org/wiki/Strategy], дата візиту Програмна реалізація движка виконана на 7.11.2010 базі мови ActionScript3. 16. Семенякін В.С, Заболотня Т.М. Узагальнений алгоритм моделювання фізичних процесів на базі СПИСОК ЛІТЕРАТУРИ мови програмування C# // "Прикладна математи- 1. Физический движок [Електронний ресурс / ка та комп"ютинг ПМК-2010": Зб.тез доповідей. - http://ru.wikipedia.org/wiki/Физический_движок], К.:Просвіта, 2010. - с.353-356. дата візиту 27.10.2010 17. Non-core joints [Електронний ресурс / 2. Е.М.Пройдаков, Л.А.Теплицький Англо- http://www.box2d.org/forum/viewtopic.php?f=4&t= український тлумачний словник з обчислюваль- 3970], дата візиту 1.12.2010 ної техніки, Інтернету і програмування. – Вид.1 – V.Semenyakin, T.Zabolotnia Modified object- К.: Видавничий дім «СофтПрес», 2005. – 552с. oriented approach to building software tools for 3. Что такое архитектура программного обеспече- modeling physical processes. ния? [Електронний ресурс / http://www.ibm.com/developerworks/ru/library/eele В.С.Семенякин, Т.Н.Заболотняя Модифициро- s/#notes], дата візиту 30.11.2010 ванный объектноориентированный подход к по- 4. Физика на Flash. Box2D Engine. [Електронний строению программных средств моделирования ресурс / http://habrahabr.ru/blogs/flash/76611/], да- физических процессов та візиту 15.11.2010 В статье рассматривается вопрос построения ар- 5. Документація до відкритого движка Box2D хитектуры программных средств моделирования (Box2D v2.1.0 User Manual) [Електронний ресурс физических процессов. Предлагается новый SIM / http://www.box2d.org/manual.html] , дата візиту подход к организации объектов пространства моде- 20.11.2010 лирования, ориентированный на максимальное аб- 6. Физика на Flash. Создание Ragdoll в Nape на AS3 страгирование последних. Определяются основные [Електронний ресурс / шаги создания программного обеспечения в рамках http://habrahabr.ru/blogs/Flash_Platform/104176/], описанного подхода. Разрабатывается SIM архитек- дата візиту 26.11.2010 тура физического движка и проводится её модифи- 7. Документація до движка Nape на AS3. Chapter 2. кация с целью повышения эффективности алгорит- Spaces and Objects [Електронний ресурс / мов обработки физических объектов по критерию http://www.deltaluca.me.uk/doc/docs/Chapter%202. быстродействия. На основе полученной архитекту- %20Spaces%20and%20Objects.html], дата візиту ры выполнена программная реализация основных 21.11.2010 классов физического движка. 8. Polygon water [Електронний ресурс/ http://www.newgrounds.com/dump/item/8e04592be 7f7a7d4262a20483734f582], дата візиту 10.11.2010 9. Документація до відкритого движка ODE [Елект- ронний ресурс / http://opende.sourceforge.net/wiki/index.php/Manua l_(All) ], дата візиту 17.11.2010 10. Документація до відкритого движка APE (Actionscript Physic Engine), [Електронний ресурс /http://www.cove.org/ape/docs/api/org/cove/ape/pac kage-detail.html], дата візиту 2.11.2010 11. Irrlicht + PhysX example, [Електронний ресурс / http://irrlicht.sourceforge.net/phpBB2/viewtopic.php ?t=19002&sid=98ad59f05dcebf57d0b5207a3dae75a 2], дата візиту 23.11.2010 12. Havok code example [Електронний ресурс / http://director-online.com/havok/demos/demo- marble.html], дата візиту 23.11.2010.

7