International scientific e-journal

ΛΌГOΣ. ONLINE

14 (October, 2020)

e-ISSN: 2663-4139
КВ №20521-13361Р

ENGINEERING AND IT

UDC 004.92

EOI 10.11232/2663-4139.14.04

ПРОБЛЕМИ ОПТИМІЗАЦІЇ ГРАФІКИ ПІД ПРИСТРОЇ ВІРТУАЛЬНОЇ РЕАЛЬНОСТІ

МАТВЄЄВ Дмитро Ігорович

ORCID ID: 0000-0002-0622-8159

асистент кафедри програмної інженерії

Харківський національний університет радіоелектроніки

 

НАУКОВИЙ КЕРІВНИК:

 

ЛАНОВИЙ Олексій Феліксович

ORCID ID: 0000-0002-4504-4301

канд. техн. наук, доцент кафедри програмної інженерії

Харківський національний університет радіоелектроніки

 

УКРАЇНА


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

Ключові слова: віртуальна реальність; ігрові рушії; окулус квест; оптимізація; комп’ютерна графіка; полігони; шейдери.

ПОСТАНОВКА ПРОБЛЕМИ.

Проблема продуктивності додатків під віртуальну реальність є куди більш гострою, ніж у більш звичних додатків під персональні комп'ютери, консолі або мобільні пристрої. Викликано це явищем, відомим як motion sickness (далі МС). Людина, що знаходиться в пристрої віртуальної реальності, виявляється в безпосередньому зв'язку з зображеннями на дисплеях. Відбувається це через сприйняття зображення поза контекстом навколишнього світу. З цієї причини будь-яка втрата кадрів болісно впливає на вестибулярний апарат, провокуючи МС, схожий за відчуттями на морську хворобу. Через це багатьом розробникам доводиться йти на компроміс, погіршуючи якість графіки. У свою чергу цей крок не завжди дає очікуваний результат з причини поганого розуміння принципів роботи комп'ютерної графіки і проблемних областей, з якими слід проводити оптимізаційну роботу. У цій статті розбираються такі проблемні області в контексті ігрового рушія Unreal Engine 4 (далі UE4) і шолому віртуальної реальності Oculus Quest. Останній обраний через можливість тестування на ньому як комп'ютерної, так і мобільної віртуальної реальності.

АНАЛІЗ ДОСЛІДЖЕНЬ ТА ПУБЛІКАЦІЙ.

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

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

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

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

МЕТА СТАТТІ.

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

ВИКЛАД ОСНОВНОГО МАТЕРІАЛУ.

Вимоги продуктивності для пристроїв віртуальної реальності значно перевищують аналогічні вимоги для мобільних пристроїв [2] або персональних комп'ютерів (далі ПК). Так для ПК мінімальним допустимим значенням є 30 кадрів в секунду, а рідкісні падіння кількості кадрів в особливо важких сценах також можуть бути некритичними. У той же час мінімальний допустимий поріг для пристроїв віртуальної реальності варіюється від 60 до 120 кадрів в секунду (fps) [1]. При чому у найбільш популярних пристроїв це вже значення в 90 fps, а у того ж Oculus Quest в 72 fps. Через варіативність мінімального порогу fps далі його падіння до рівня, що викликає МС, пропоную називати «проміжком « хвороби». Ускладнюється завдання ще й тим, що відмальовка сцени (рендер) ведеться на два дисплеї, розділяючи зображення для кожного з них. У випадку з Oculus Quest це два дисплея з роздільною здатністю 1440х1600. Відмальовка сцени трохи здешевлюється завдяки режиму Mobile Multi-View, який копіює буфер лівого ока в праве око, на його основі домальовуючи сцену під необхідним кутом. Це дозволяє проводити рендер швидше, ніж для двох камер, але все ж дорожче, ніж для однієї, так як зображення для кожного ока різні.

Основним джерелом втрати продуктивності є безпосередньо об'єкти сцени. З них можна виділити наступні, найбільш вагомі: геометрія, матеріали, джерела освітлення, туман, системи частинок, постобробка. Розміщення вищевказаних об'єктів в порядку впливу на продуктивність є неможливим, так як неакуратної роботи з будь-яким з них може бути досить для потрапляння в проміжок «хвороби». Далі розглянемо кожен з об'єктів окремо.

Геометрія в тривимірному просторі має уявлення у вигляді з'єднаних між собою трикутників (будь-який н-кутник автоматично розбивається на трикутники), що складаються з ребер і вершин. Складність геометрії прийнято обчислювати в кількості трикутників або вершин. В сучасних ігрових рушіях немає фізичного обмеження за кількістю трикутників на сцену або на кадр. Всі обмеження, які можна знайти, мають рекомендаційний характер. Таким обмеженням для платформи Oculus Quest є значення в 100 000 трикутників на кадр. Розробник може створити сцену, в якій на кадр буде припадати не 100 000, а 1 000 000 трикутників, чим викличе потрапляння в проміжок «хвороби».

Зменшення кількості полігонів (трикутників) - очевидний спосіб. Найбільш очевидний спосіб це зробити - фізично зменшити щільність сітки в тривимірному редакторі. Проблема тут виникає в тому, що автоматичні реалізації методів зменшення щільності полігональної сітки підходять далеко не для всіх об'єктів і дають неакуратний результат, через що погіршується якість тривимірної моделі. В результаті цю процедуру доводиться проводити вручну, що вимагає багато людино-годин. Частково вирішити проблему великої кількості полігонів на кадр допомагають такі інструменти: level of detail (рівні деталізації) [3], occlusion culling (оклюзивне обрізання), precomputed visibility (попередньо прорахована видимість). Перший інструмент за рахунок методу децимації створює вказану кількість варіантів моделі з меншою кількістю полігонів, перемикаючись між ними на вказаних дистанціях. Так, наприклад, модель, що складається з 10 000 трикутників, на достатній відстані може використовувати лише 100 трикутників. Другий інструмент автоматично прораховує об'єкти на сцені і не обробляє ті з них, які повністю не видно. Так будинок, який повністю перекривається іншим будинком, не буде прораховуватимуться і малюватися. Останній інструмент схожий на другий тим, що робить те ж саме, але виключно для статичних об'єктів. Він розбиває сцену на області, для кожної з яких визначаючи які об'єкти будуть видні під кожним кутом повороту камери.

Матеріали (шейдери) завжди йдуть в зв'язці з геометрією. На поверхні лежить питання складності матеріалів. Грубо матеріали можна розбити на чотири категорії: непрозорі неосвітлювані, непрозорі освітлювані, непрозорі замасковані, прозорі. Далі будемо мати на увазі, що всі матеріали, крім прозорих, є непрозорими. Найбільш дешевими по продуктивності є неосвітлювані матеріали (unlit), так що їх використання в будь-яких проектах під мобільну віртуальну реальність є пріоритетним. Як випливає з назви, даний вид матеріалів передає тільки колір, на який не впливають жодні джерела освітлення. Освітлювані матеріали (opaque) є більш дорогими, але в багатьох проектах ми змушені їх використовувати, якщо хочемо працювати з освітленням, відблисками і відображеннями. Кількість інструкцій для подібних матеріалів часто буває в межах допустимого. Здешевити їх можна за допомогою функції fully rough (повністю матове) [2]. Такий варіант підходить в тих випадках, коли ми можемо дозволити собі відмовитися від відблисків, відображень і металевих поверхонь. Замасковані матеріали бувають як освітлюваними, так і не освітлюваними. Їх особливість в тому, що у кожного пікселя є два стани: видимий і невидимий. У цій групі матеріалів знаходиться один важливий підступ: при багатошаровому накладення невидимих ​​пікселів, для них значно збільшується складність шейдерів. Часто таке відбувається при створенні листя на деревах. Вирішується ця проблема включенням додаткового буфера глибини для замаскованих об'єктів. Прозорі матеріали є найнебезпечнішими. Вони мають найбільшу складність і вимагають обережності при роботі з ними. Це викликано в першу чергу тим самим ефектом накладення, який вже не можна нівелювати додатковим буфером глибини. Бажано взагалі не використовувати прозорі матеріали. У разі ж необхідності використання таких, краще використовувати режим змішування additive і не допускати накладень. Для зменшення кількості інструкцій в матеріалах рекомендується використовувати батьківські (майстер) матеріали і успадковувати від них інстанси. Це дозволить значно здешевити матеріали в контексті сцени.

З джерелами освітлення ситуація куди простіша. Вони бувають трьох типів рухливості: статичний, динамічний і стаціонарний. Статичних джерел освітлення можна використовувати як завгодно багато. Це впливає виключно на час попереднього прорахунку світла. Динамічні джерела освітлення представляють тут найбільшу небезпеку. У мобільній віртуальної реальності їх бажано взагалі не використовувати, або використовувати дуже обережно і дозовано. У віртуальній реальності під ПК варто звернути увагу на тіні. Динамічні джерела освітлення без тіней досить дешеві. Всю їх небезпеку становлять саме динамічні тіні, прорахунок яких є вельми складним. Вирішити цю проблему для ПК можна трьома способами: не використовувати динамічні тіні, відключати джерела освітлення на дистанції, використовувати distance field shadows. Ці способи можна поєднувати. Стаціонарні джерела освітлення є проміжним станом між статичними і динамічними. На відміну від статичних джерел освітлення їх можна відключати і включати в реальному часі за цієї причини для кожного такого джерела освітлення генерується свій набір карт світла. На статичні об'єкти стаціонарні джерела освітлення впливають так само, як і статичні джерела освітлення, але на динамічні об'єкти так само, як і динамічні джерела освітлення. Тобто динамічні об'єкти вони висвітлюють в реальному часі і відкидають від них тіні. Їх бажано не використовувати, обмежившись статичними і динамічними джерелами освітлення без тіней. У разі використання важливо не розміщувати стаціонарні джерела освітлення занадто близько.

Туман сам по собі є досить недорогим інструментом, так як прораховується на рівні постобробки, або маскує вершини в разі мобільної розробки без постобробки. Небезпека полягає тільки в об'ємному (volumetric) тумані. Його варто використовувати вкрай обережно, або не використовувати взагалі.

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

Постобробці варто приділити окрему увагу. У мобільній віртуальної реальності є можливість включити HDR режим, який активує постобробку, але з цим режимом навіть на порожній сцені fps буде нижче мінімального допустимого значення. Таким чином, має сенс її розглядати в контексті віртуальної реальності для ПК. Постобробка, як випливає з назви, накладає ефекти поверх промальовані сцени, використовуючи для цього «проходи» рендеру (render pass). Наприклад, буфер глибини або нормалі в глобальних координатах. Постобробка має безліч параметрів, що настроюються, так що звернути увагу варто на найважливіші з них. Світіння (bloom) є недорогим ефектом при використанні його в стандартному режимі. Тут варто звернути увагу на режим світіння convolution. Такий розрахунок світіння є більш дорогим і не рекомендується для віртуальної реальності. Depth of Field (розмиття на дистанції) має середню вартість. При наявності запасу продуктивності його можна використовувати. Матеріали постобробки також можна вільно використовувати, але не варто забувати, що тут працюють правила, аналогічні іншим матеріалам. Так абсолютно будь-який матеріал можна перевантажити кількістю використовуваних текстур і складними інструкціями, що з практично безкоштовного по продуктивності інструменту може зробити вкрай дорогий. Ambient Occlusion (глобальне затінення) є потенційно дорогим ефектом. Використовувати його можна в разі зниження рівня якості даного ефекту, або при достатньому запасі продуктивності. Motion Blur (розмиття в русі) можна не розглядати з точки зору продуктивності, так як його використання у віртуальній реальності небажано через провокування MS. Screen Space Reflections (відображення в просторі екрану) успадковує правила використання глобального затінення. Його також небажано, але можна використовувати при зниженні якості даного ефекту. Решта ефектів постобробки досить недорогі, так що їх використання не повинно викликати проблем з продуктивністю при дотриманні всіх попередніх рекомендацій.

Не менш важливим критерієм оптимізації є показник Draw Calls (викликів промальовування). Він безпосередньо пов'язаний з поєднанням геометрії і матеріалів. Кожен матеріал створює виклик промальовування. Для Oculus Quest є рекомендоване значення в 100 Draw Calls [4] (далі DC), яке бажано не перевищувати. Один геометричний об'єкт може бути розбитий на кілька матеріалів. Так, об'єкт, що складається з п'яти матеріалів, створюватиме 5 DC. Є кілька підходів до зменшення показника DC. Перший з них - об'єднання геометричних об'єктів з однаковими матеріалами в один геометричний об'єкт. Так 10 однакових об'єктів з одним матеріалом після об'єднання будуть генерувати не 10, а 1 DC. Але у цього рішення є і проблемна сторона. При поєднанні об'єктів результуючий об'єкт матиме більший візуальний масштаб, а також буде єдиним цілим, через що на нього будуть менш ефективно впливати рівні деталізації. Крім цього, на окремі його елементи, що колись були незалежними об'єктами, не працюватиме occlusion culling. Тільки на об'єкт в цілому. Такий метод підходить для об'єднання невеликих об'єктів, розташованих один від одного на невеликій дистанції. Наприклад, складені стопкою ящики можна таким чином об'єднати в об'єкт. Наступний метод є більш прикладним. Він полягає в створенні комплексних матеріалів, де колись окремі матеріали накладаються на геометричний об'єкт за допомогою текстурних масок або ж з використанням кольорів вершин (vertex color). Для цього методу необхідні просунуті вміння в створенні матеріалів. Останній метод заснований на роботі з інстансами. За допомогою коду можна генерувати пов'язані між собою об'єкти, які будуть вимальовуватися в один прохід. Для цього об'єкти повинні бути ідентичними. Наприклад, таким чином можна генерувати молекулярну сітку, що складається з безлічі повторюваних об'єктів.

Крім усього вищесказаного окремо варто звернути увагу на роботу з пам'яттю. У ПК віртуальної реальності це може бути некритично, але для мобільної віртуальної реальності вкрай вагомо. На кожному етапі розробки проекту варто орієнтуватися на максимальний обсяг оперативної пам'яті кінцевого пристрою і постійно стежити за обсягом використовуваної пам'яті, залишаючи запас в 20-30%. Цей запас необхідний у випадку масштабування проекту навіть в умовах повторного використання матеріалів та текстур, так як в оперативну пам'ять будуть завантажуватися текстури запеченого освітлення, вагу яких проблематично оцінити заздалегідь.

Наостанок розглянемо декалі (decals). Використання їх в мобільній віртуальній реальності неможливе за причиною обробки цього ефекту на рівні постобробки. У ПК віртуальній реальності цей метод рідко колі сприяє появі проблем з продуктивністю. Важкість обробки такого ефекту залежить від складності матеріалу та розміру області декалі. Декаль має бути мінімального необхідного розміру та використовувати коректно реалізовані матеріали.

ВИСНОВКИ.

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

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

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


СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ:

 

  • Virtual Reality Best Practices. Retrieved from https://docs.unrealengine.com/en-US/Platforms/VR/DevelopVR/ContentSetup/index.html

  • Performance Guidelines for Mobile Devices. Retrieved from https://docs.unrealengine.com/en-US/Platforms/Mobile/Performance/index.html

  • Mobile Performance Tips and Tricks. Retrieved from https://docs.unrealengine.com/en-US/Platforms/Mobile/Performance/TipsAndTricks/index.html

  • Draw Call Cost Analysis for Quest. Retrieved from https://developer.oculus.com/documentation/native/android/mobile-draw-call-analysis/


GRAPHICS OPTIMIZATION PROBLEMS FOR VIRTUAL REALITY DEVICES

MATVIEIEV D.,
assistant of the Department of Software Engineering
Kharkiv National University of Radio Electronics
UKRAINE

SCIENTIFIC ADVISER:

LANOVYY O.,
associate professor, PhD software engineering department
Kharkiv National University of Radio Electronics
UKRAINE

Abstract.
The development of virtual reality applications requires a deep understanding of the methods of computer graphics processing by modern graphic libraries and a deep understanding of the complexity of processing each graphic component of this process. This article discusses the main aspects that affect productivity and offers principles that are desirable to follow to get the best results.


Keywords: virtual reality; game engines; oculus quest; optimization; computer graphics; polygons; shaders.

© Матвєєв Д.І., 2020

© Matvieiev D., 2020

 

This work is licensed under a Creative Commons Attribution 4.0 International License.

PUBLISHED : 14.10.2020