Різниця між візуалізацією в OpenGL та програмному забезпеченні 3D-анімації


16

Завдяки OpenGL та іншим я можу зробити кілька дивовижно виглядаючих речей у реальному часі 60 FPS. Однак, якщо я спробую зробити відео з тієї самої сцени, скажімо, Майя, або 3ds Max, це займе МНОГО МНОГО довше, щоб вона відображала, навіть якщо це однакова роздільна здатність і FPS.

Чому ці два типи візуалізації вимагають різного періоду часу для одного результату?

Примітка: Так, я розумію, що програмне забезпечення для 3D-анімації може створювати зображення, які чудово переважають те, що можна зробити в режимі реального часу. Але для цього питання я маю на увазі сцену однакової складності.


1
Коротка відповідь полягає в тому, що OpenGL приймає ярлики.
користувач253751

Відповіді:


9

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

Це має бути швидким, щоб ми могли відчувати це як у режимі реального часу.

Тому алгоритм виконує кілька простих кроків.

  • перевірте, чи певна частина сцени, на мій погляд, фрустрація

    Куріння плоду

  • перевірте, чи є щось перед цим, що, можливо, потрібно буде подати пізніше, використовуючи буфер глибини

    Глибина буфера

  • впорядкувати об’єкти, які ми знайшли, щоб намалювати

  • малюйте їх , проектуючи їх на екран
  • відтіняйте їх на основі текстур / шейдерів / світильників / ...

З іншого боку, програмне забезпечення для рендерінгу (Blender / Max / Maya / ...), швидше за все, використовує певний тип ретрансляції

Це передбачає багато більше математики для досягнення вищого ступеня реалізму. Це в основному працює так само:

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

….

Я перестав тут перелічуватись, оскільки це пункт, коли лунає зйомка.

Замість того, щоб перевіряти, чи потрапила точка, більшість Raytracer зараз починає обчислювати:

  • кількість світла, яке проникає в поверхню
  • скільки світла відбивається
  • викидайте нові промені з точки попадання на сцену, поки вона не потрапить на джерело світла

Існує багато методів з різним ступенем реалізму, які можна використовувати для обчислення світла певної точки сцени.

TL; DR Суть полягає в тому, що Raytracer здебільшого намагається бути фізично точним, коли йдеться про освітлення, і тому в ньому є набагато більше розрахунків на піксель (іноді знімають тисячі променів), а з іншого боку ігри отримують свою швидкість малювання великих фрагментів екрану з більш простими підрахунками світла і безліччю трюкових штрихів, які дозволяють виглядати реалістично.


7

Ви порівнюєте яблука з апельсинами

Гра схожа на порт перегляду у вашому додатку для моделювання. Ви можете скористатися вікном перегляду для візуалізації, і ви отримаєте ті ж швидкості 60 кадрів в секунду.

Немає причини, чому ви не можете отримати графіку в реальному часі, яка дуже добре виходить із програмного забезпечення для моделювання, як Maya або 3DS Max. Результати, сумісні з багатьма іграми. Вони мають шейдери для перегляду, як і ігри. Існує також параметр візуалізації вікна перегляду, який кадрує кадри на диск настільки швидко, наскільки це дозволяє (я робив повні HD-рендери в 30 кадрів в секунду від Майя). Все, що вам потрібно зробити, - це припинити використання наданих програмних променів.

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

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

Чому променеві сліди повільніші?

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

  1. Випромінювання даних на диск, не тільки кадри, але й усі дані. Щось, що миттєво порушило б більшість ігор швидкості.

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

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

TL; DR Різниця здебільшого полягає в оптимізації (читайте багато хитрощів) та доступних зовнішніх ресурсах.

PS: Існує помилкова думка, що це тому, що це фізично правильніше. Це, безумовно, може бути, але промінь-прослідчик не є по суті більш фізично правильним, ніж ваша середня гра чи будь-які інші обчислення. Насправді багато ігор використовують дійсно хороші моделі, тоді як досить багато моделей цього не роблять.

* Див. Http://www.graphics.cornell.edu/~bjw/mca.pdf


2
Вибачте, але це явно неправильно. OpenGL та DirectX використовують наближення, які за своєю суттю швидше, ніж точне випромінювання. Вся суть прискореної тривимірної графіки полягає в створенні алгоритмів, які балансують між реалістичністю та швидкістю, виглядаючи досить добре для практичного використання: ігор, CAD тощо
IMil

2
@IMil OpenGL може використовуватися для прослуховування променів. Це швидше, оскільки він оптимізований для обладнання, про яке йдеться. Але Майї НЕ треба простежити. Майя та Макс можуть використовувати openGL та directX так само, як і ваша гра. Вікно перегляду майя (і 3ds) відкривається або directX (на ваш вибір). Те, що ваш процесор у певних паралельних навантаженнях обробляється повільніше - інша річ. Отже, відповідь стоїть. Стандартні налаштування майя не більш реалістичні, ніж стандартні лінії сканування.
joojaa

5

Попередній перегляд у режимі реального часу

Працюючи в галузі VFX галузі, якщо ви говорите про попередні перегляди огляду в режимі реального часу, а не про відображення виробництва, то Maya і 3DS Max зазвичай також використовують OpenGL (або, можливо, DirectX - майже все те саме).

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

Відображення виробництва та трасування шляхів

Програмне забезпечення VFX також робить акцент не на попередньому попередньому перегляді, а на виробництві, де світлові промені насправді моделюються один за одним. Попередній перегляд у режимі реального часу найчастіше - це лише «попередній перегляд» результатів вищої якості.

Ігри роблять прекрасну роботу з наближення багатьох таких ефектів останнім часом, як глибина різкого поля в режимі реального часу, м'які тіні, розсіяні відбиття тощо, але вони знаходяться в категорії важкого наближення (наприклад: розмиті карти кубів для дифузних відбиття замість того, щоб насправді імітувати світлові промені).

Зміст

Якщо повернутися до цієї теми, припущення щодо вмісту між програмним забезпеченням VFX та грою дико відрізняються. Основна увага програмного забезпечення VFX полягає в тому, щоб дозволити створювати будь-який можливий тип контенту (принаймні, це ідеал, хоча практично це часто ніде не буває). Ігри зосереджуються на вмісті з набагато важчими припущеннями (всі моделі мають бути в межах тисяч трикутників, нормальні карти повинні бути застосовані до підроблених деталей; насправді у нас не повинно бути 13 мільярдів частинок, персонажі насправді не оживлені м'язами картки та натяжні карти тощо).

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

Ігри Робіть це краще

Це може бути суперечливим поглядом, але ігрова індустрія є набагато вигіднішою галуззю, ніж програмне забезпечення VFX. Їх бюджет на одну гру може охоплювати сотні мільйонів доларів, і вони можуть дозволити собі випускати двигуни нового покоління кожні кілька років. Їх зусилля в галузі науково-дослідної роботи дивовижні, і постійно випускаються сотні і сотні назв ігор.

Програмне забезпечення VFX та CAD, з іншого боку, ніде не є таким прибутковим. Науково-дослідні та дослідницькі роботи часто піддаються аутсорсингу дослідниками, що працюють в академічних умовах, і багато галузей часто застосовують методи, опубліковані за багато років до цього, ніби це щось нове. Таким чином, програмне забезпечення VFX, навіть прибуваючи від таких великих компаній, як AutoDesk, часто не є настільки "сучасним", як новітні ігрові двигуни AAA.

Вони, як правило, мають набагато довший спадок. Майя - це, наприклад, 17-річний продукт. Він був багато відремонтований, але основна його архітектура все одно та сама. Це може бути аналогічним спробі взяти Quake 2 і постійно оновлювати та оновлювати його до 2015 року. Зусилля можуть бути великими, але, ймовірно, не відповідають Unreal Engine 4.

TL; DR

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


Це також питання часу. Навіть якщо ви зможете зробити 60 кадрів в секунду і отримати прийнятні результати, вона рідко намагається оптимізувати її. Скажімо, це займає 3 хвилини на кадр, і у вас є 200 кадрів. Можливо, ви зможете отримати 60 кадрів в секунду, найнявши шейдерну програму та оптимізуючи, але тоді це займе щонайменше день або два вашого часу. Але 200 кадрів за 3 хвилини займає лише 10 годин, тому ви заощадите ці кошти. На практиці дешевше купувати більше обладнання та не надто турбуватися про це. Ігри просто не можуть прийняти такий підхід.
joojaa

@joojaa Це теж трохи складніше. Просто робити справді хороші шейдери в реальному часі для Майї може зайняти рік або близько того, щонайменше, навіть від досвідченого розробника шейдерів (з меншими вигодами), оскільки гнучкість вузлової системи там орієнтована на виробництво. Для переведення цих шейдерних вузлів загального призначення в систему затінення в режимі реального часу, яка фіксує діапазон ефектів UE 4, знадобиться зворотний інженерний настрій і новий вид генерування коду GLSL / HLSL (як система метапрограмування). , наприклад
Драконова енергія

Шейдерний двигун @joojaa UE 4 безпосередньо орієнтований на сильно наближений модуль PBR (дуже невеликий підмножина шейдера PBR Disney). Вони розробили навіть свою матеріальну систему для швидкого, в реальному часі, замість того, щоб починати з чогось подібного до матеріальної системи Майя, яка зовсім не призначена (призначена для прослуховування). Навіть якби найяскравіший з UE 4 працював над VP 2.0, їм довелося б працювати ніч і день протягом можливих років, щоб досягти однакових результатів у порівнянні з дизайном, який не збирався робити подібні речі.
енергія Дракона

але це разова вартість, навіть якщо у вас є цей конвеєр у додатку VFX, кожна сцена може потребувати додаткової оптимізації. Немає жодної причини, через яку користувач майя не міг зробити рендерінг в UDK, наприклад, для тієї самої платформи shader dev.
joojaa

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.