Чи показує зіткнення у повільному темпі руху обчислювально розслабляючий?

У багатьох гоночних іграх (наприклад, Burnout Paradise ), коли зіткнення має відбутися, гра автоматично перемикається на повільний рух і продовжується в повільній послідовності до завершення зіткнення.

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

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

Що правильно?

Чи збільшує сцена сповільненого руху використання CPU / GPU або зменшує його?

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

Припустимо, ви займаєтеся фізикою із 200 оновлень в секунду. Напр. одне оновлення кожні 0.005секунди часу моделювання. Під час запуску гри з 50 оновленнями в секунду, це призведе до 4 оновлень фізики на оновлення візуалізації. Тепер ви б запускали гру в повільному темпі, це означає, що ви уповільнюєте час моделювання. Отже, якщо гра все ще працює з 50 оновленнями в секунду ( 0.02секунди часу моделювання), а ви показуєте світ у повільному темпі (скажімо, половину швидкості), то один кадр був би еквівалентний 0.01секундам часу моделювання. Отже, лише 2 оновлення фізики на кожен кадр. Значить менше фізика-розрахунки на наданий кадр.

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

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

Це можливо , що це може бути так. Якщо ви не займаєтеся фізикою для зіткнення на GPU, це означає присідання. Але з точки зору самої фізики ... це можливо.

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

Праворуч до тих пір, поки одна річ не потрапить на іншу. Дивіться, у фізиці у вас є те, що називається часовим фрагментом; це кількість часу, яке охоплює виконання системи фізики. Якщо ваш часовий відрізок займає 1/30 секунди (30 кадрів в секунду для оновлення фізики), то кожне оновлення фізики рухає об’єкти на 33,3 мілісекунди у майбутнє.

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

Проблема полягає в тому, коли об’єкти стикаються. Раптом тепер вам доведеться обробляти фізичні сили в часовий відрізок, а не лише один раз на початку. Якщо об'єкт стикається два або три рази в рамках фізики, то вам доведеться повторити обчислення фізики.

Якщо у вас є багато зіткнень за один проміжок часу, ви можете дійсно вбити кадр. Однак ймовірність багаторазового зіткнення в межах часового відрізка зменшується, оскільки розмір часового відрізка зменшується. Бігові симулятори високого класу, такі як Forza та Gran Turismo, керують своїми фізичними системами у неймовірних рамках. Я думаю, що один з них отримує до 300 + кадрів в секунду за оновлення фізики.

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

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

Перш за все, це робиться заради візуального ефекту, а не з міркувань продуктивності.

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

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

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

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

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

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

Середній спосіб - використовувати двигун фізики зі змінним кроком, який, як правило, підвищить точність, коли ви уповільнить моделювання, вирішивши таким чином принаймні частину проблеми. Є й інші причини не використовувати фізику змінних кроків, але мінливий крок все ще досить поширений у галузі.