Як ми перестали боятися Огра і почали робити на ньому гру

    

Як робити помилки. 2011р

Як випливає з назви, в далекому 2011 році ми здійснили третю помилку, вибравши в якості основи для ігрового движка Ogre3D. Третю, тому що першою помилкою було рішення робити гру, а другий — робити її на своєму движку. На щастя, це були ті самі помилки, з яких починається захоплююча історія. Ця пригода, в якому ми пройшли майже весь шлях розвитку ігрових движків, як зародок проходить всі етапи еволюції.
Звичайно ж, як і всі початківці розробники, ми слабо уявляли собі, що і навіщо ми збираємося робити. Нами рухало бажання розповісти свою історію, створити свій вигаданий світ, свою всесвіт, і на хвилі популярності ММО, природним позивом було зробити свою ММО з блекджек і всім належними. Позив трапився ще в 2010, а до 2011 була готова перша версія діздока. Земля була пуста та порожня, і темрява над безоднею, і Дух Фоллаута витав над нами.
Ми йшли шляхом проб і помилок, збираючи по шляху все косяки і граблі. Як і більшість проектів, ми почали з найпростішого. У плані графіки (а я буду розповідати тільки про графічної частини) перша версія движка дозволяла використовувати тільки дифузну карту і стенсільние тіні.
 
 image
 
 
2011р. Один з перших скріншотів
 
У технологічному плані з графіки ми тоді сильно орієнтувалися на ігри типу Торчлайт. Але душі вимагала більшого, адже паралельно з розвитком графічної частини движка йшов і художній пошук.
 
До осені 2012 року в плані графіки ми доросли до використання карт нормалей і спекуляров. Вплив DOOM 3 було сильно на незміцнілі уми початківців розробників.
 
 
2012р. До DOOM 3 як до Марса.
 
 

Як вибрати між Сопілка і глечик. 2013р.

Взимку 2013 року команда приросла красивим трехмерщіком і привабливим програмістом графіки. Фантазії провідного художника знайшли точку опори, і движок став приростати графічними нововведеннями. З'явилися текстура глянцевитости (вона ж карта статечного коефіцієнта спекуляра, вона ж glossiness, вона ж shininess), каскадні текстурні тіні, DoF (ефект глибини різкості), RIM-освітлення і купа глюків. У цей період стали особливо явно спливати проблеми комунікацій різних фахівців. Одні й ті ж речі для розробників з різним бекграундом називалися абсолютно по-різному, і вимагали багаторазового промовляння.
Все частіше стали затівати жаркі баталії про траєкторію розвитку движка. В умовах обмежених бюджету і часу доводилося вибирати між програмуванням геймплейні частини і візуальної. Так, RIM з'явився як компроміс між бажанням художника бачити більш явний метал, бажанням трехмерщіка мати для цього відображення і поточними можливостями движка. Все більш гостро стало вставати питання про перехід на готовий движок: Unity3D ставав все більш функціональним і популярним, стали з'являтися чутки про людські схемах ліцензування UDK.
 
 
 
 
Початок 2013р. Картинка стала трохи веселіше, але ненабагато.
 
 
 
Кінець 2013р. Картинка стала ще веселіше.
 
 

Як нарватися на неприємності. 2013р.

Восени 2013р. ми в перший раз вийшли на кікстартер. Свідчення цьому сумному досвіду миготіли навіть на Хабре. Кампанію ми прикрили протягом першого ж тижня, оскільки стало очевидно, що «не злетить». ММО до цього моменту почали дратувати ігроманів, черговий «клон ВоВ» (яким гра жодною мірою не планувалася, але переконати в цьому геймерів не вдавалося) нікого не цікавив. В якості роботи над помилками було вирішено, що ми відтепер робимо РПГ синглу з кооперативним проходженням.
 
 
Кінець 2013р. Скріншот з презентаційної сцени…
 
 

Як знайти свободу. 2014р.

Фантазія провідного художника вимагала великих і складних просторів. Реалізація цих фантазій і ведучий трехмерщік вимагали можливості оперувати НЕ п'ятьма джерелами світла, а набагато великою їх кількістю.
Обмеження в 5 (насправді 8, але фпс просідав вже на п'ятому) джерел світла було обумовлено застосуванням forward render (прямого рендера)
Прямий рендер — стандартний спосіб рендера, який використовують більшість движків. Кожен об'єкт, отриманий відкритий проходить повний шлях рендеринга. При цьому вертексний і піксельний шейдери вважаються для кожного джерела світла окремо навіть для тих пікселів, які можуть згодом перекритися іншими. Кожен додаткове джерело світла створює додаткову ітерацію розрахунків по всій геометрії. І при восьми джерелах світла в сцені з 1 мільйона видимих ​​трикутників малюється вже близько 9 мільйонів трикутників. Це призводило до дуже низького FPS на скільки-небудь складних локаціях…
 
Привид крузис з його сотнями лампочок не давав спати ночами. Було вирішено перейти на deferred render (відкладений рендер або відкладене освітлення). При відкладеному рендере формується набір «кінцевих» зображень без розрахунку тіней: зображення кольору, зображення глибини і зображення нормалей. Знаючи положення джерел світла, глибину пікселів і нормалі можна розрахувати затінення.
У порівнянні з forward-rendering ми отримали кілька булочок:
1) Підвищення фпс за рахунок того, що геометрія рендерится тільки один раз
2) Можливість працювати з безліччю джерел світла: додавання нового джерела світла слабо позначається на продуктивності.
3) Прискорення деяких видів пост-обробки, більш ефективна реалізації м'яких частинок і можливість додавання обробки screen-space reflection. М'які частинки, а також ефекти пост-обробки (DOF, SSR, SSAO) вимагають карти глибини і нормалей. Прямий рендер не дає ці карти, і їх доводиться рендерить окремо. При відкладеному освітленні ці карти нам подаються на блюдечку з блакитною облямівкою.
 
Недоліки:
1) Напівпрозорість. Напівпрозорі об'єкти не можна малювати у відкладеному освітленні, тому що буде потрібно, щоб один піксель кожної текстури (нормаль, диффуз і т.д.) містив інформацію про декілька перекриваються об'єктах. Є безліч різних способів вирішення проблеми, але найчастіше використовується один — все напівпрозорі об'єкти Рендер окремо за допомогою прямого рендера.
2) Алиасинг. При відкладеному освітленні fsaa відключається і всі трикутники малюються з явно вираженим алиасинг. Для вирішення цієї проблеми використовують різні методи, наприклад FXAA
3) Підвищений вимога до пропускної здатності пам'яті відеокарти.
 
Ми розглядали три варіанти реалізації відкладеного освітлення:
 
Варіант А:
 
Розрахунок освітлення ділиться на два етапи:
1. На першому етапі малюється вся непрозора геометрія в 4 текстури. (Диффуз, спекуляр, глянцевитость, нормаль, карта глибини і карта світіння)
-Диффуз, спекуляр, глянцевитость беруться безпосередньо з текстур геометрії,
-Нормалі видобуваються з карти нормалей натягнутих на геометрію і перетворених в координати простору камери.
-Карта світіння виходить шляхом складання карт самосвеченія, RIM освітлення, амбієнтного дифузного освітлення + слабкою підсвічування з боку камери.
2. Використовуючи карти нормалей, глибини, дифузія, спекуляра і глянцевитости розраховується дифузне і спекулярное світіння кожної точки для кожного джерела світла і інкрементного підсумовується з картою світіння. У цьому ж пассе перевіряється попадання кожної точки екрану в тіньові карти.
 
Це стандартний варіант відкладеного освітлення, реалізований у більшості ігор.
 
 
Варіант Б:
 
Розрахунок освітлення ділиться на 3 етапи:
1. На першому вся непрозора геометрія рендерится в 1 текстуру (Рендер карти нормалей, глибини і глянцевитости)
2. По картах нормалей, глибини і глянцевитости Рендер дві карти: дифузного і спекулярного освітлення для кожного джерела світла.
3. На третьому етапі рендерится фінальне зображення: малюється вся непрозора геометрія ще раз, але з дифузії і спекуляром і обчислюється освітленість кожної точки шляхом множення дифузного освітлення на дифузну карту + твори спекулярного освітлення на спекулярную карту + рим-освітлення + карту самосвеченія + світло від камери.
  
Переваги цього методу:
1) Менше вимог до пропускної здатності відеопам'яті відеокарти.
2) Менше обчислювальних операцій на кожне джерело світла, тому що частина операцій переходить з другого етапу в третій.
3) Третій етап вже може Редер з увімкненим fsaa, що збільшує якість картинки.
 
Недолік цього методу один — два рази рендерится вся геометрія. Проте другий раз можна рендерить по готовому z-буферу, підготовленому на першому етапі.
 
 
Варіант В:
 
 
 
Розрахунок освітлення ділиться на 3 етапи:
1. На першому етапі малюється вся непрозора геометрія в 4 текстури (диффуз, спекуляр, глянцевитость, нормаль, карта глибини і карта світіння (як сума від складання карт самосвеченія, RIM освітлення, амбієнтного дифузного освітлення + слабкою підсвічування з боку камери)).
2. По картах нормалей, глибини і глянцевитости Рендер дві карти: дифузного і спекулярного освітлення для кожного джерела світла.
3. На третьому етапі рендерится фінальне зображення: обчислюється освітленість кожної точки шляхом множення дифузного освітлення на дифузну карту + твори спекулярного освітлення на спекулярную карту карту самосвеченія…
 
Цей варіант — суміш перших двох варіантів. У порівнянні з варіантом A ми отримуємо виграш в швидкості за рахунок особливості варіанту Б: замість чотирьох вибірок з текстури йде тільки одна.
 
Зараз у нас реалізовано перший варіант відкладеного совещения. Всі канали які використовуються для відтворення фінальної картинки можна виводити в отладочном режимі.
 
 
 
Після рендера фінальної картинки робиться постообработка: тут у нас створюється ефект глибини різкості і робиться корекція кольору. На цьому ж етапі малюються відображення по технології SSR.
 
SSR (Screen Space Reflection) — це алогорітм створення в сцені реалістичних відображень з використанням даних, які вже відрендерити на екрані. Коротко: від камери пускається промінь до перетину зі сценою. Використовуючи нормаль в точці перетину, вважається відображення. За цим променю відображення відбувається трасування карти глибини поки до попадання в яку-небудь геометрію, в якості результату береться світність найденої точки і множиться на спекуляр відбиває точки і записується в світність відбиває точки.
Зараз реалізовано два алгоритми Screen Space Reflections:
1) Трасування відбувається в координатах камери — повільна, але дає правильну картинку.
2) Трасування відбувається в координатах текстури — швидка але дає похибку при малих кутах.
 
 
 
2014р. Презентаційна діорама з включеними відбитками.
 
 
 
2014р. Презентаційна діорама з включеними відбитками.
 
Ми використовуємо свій ігровий і мережевий движок. Графічний движок — Ogre3D, Фізичний — Bullet. Скриптинг: Lua, C # (Mono). Під час розробки довелося сильно допілівать Ogre3D і налагоджувати його в'язку з Blender… У планах зв'язатися з розробниками Огра і запропонувати включити свої доробки в наступні збірки Огра.
 
 

Як очікувати кращого. 2014р.

В даний момент, тобто прямо ось зараз, йде наша друга кампанія зі збору коштів на кікстартер.
  
 />
Використовувані мови програмування: C + +, PHP, Lua, C #, Python, Java, Groovy, Cg, GLSL, HLSL.
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.