Як вибрати фактор масштабування у світі 3D-ігор?

Я роблю 3D-прототип гри з танками з деяким фізичним моделюванням, використовую C ++. Одне з рішень, яке мені потрібно прийняти, - це масштаб ігрового світу стосовно реальності. Наприклад, я міг би вважати, що одна ігрова одиниця вимірювання реально відповідає 1 метру. Це відчувається інтуїтивно, але я відчуваю, що я можу щось пропустити.

Я можу вважати наступні як потенційні проблеми:

1. Сумісність програми 3D-моделювання. (?)
2. Числова точність. (Це має значення?) Особливо в великих масштабах, як такі ігри, як Battlefield, мають величезні карти: як вони не втрачають числової точності, якщо використовують карти 1: 1 у реальному масштабі світу, оскільки представлення з плаваючою точкою, як правило, втрачає більшу точність з більшими розмірами цифри (наприклад, при відливанні променів, фізичному моделюванні)?
3. Ігровий процес. Я не хочу, щоб рух одиниць відчував себе повільним або швидким, використовуючи майже реальні світові значення, як -9.8 m/s^2для сили тяжіння. (Це може бути суб'єктивним.)
4. Чи нормально масштабувати імпортні активи вгору / вниз чи це найкраще підходить до світу з його оригінальною шкалою?
5. Ефективність візуалізації Чи великі сітки з однаковою вершиною рахуються повільніше?

Мені цікаво, чи варто це розділити на кілька запитань ...

Як правило, ви повинні робити будь-які справи.

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

2. Не переміщуйте камеру далеко від світового походження, але перемістіть світ навколо камери, розміщеної поблизу світового походження. Таким чином ви уникнете безлічі питань щодо точності, які виникають, коли GPU / фізика повинні точно порівняти значення, які мають низьку точність. Якщо ви перемістите танк і камеру в 10 км від походження, точність буде залежати від частки міліметра з поплавком32, що може спричинити ефекти, схожі на Z-бої між трансформованими моделями.

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

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

5. Я сумніваюся, що є якась різниця, якщо вони візують однакову кількість пікселів на екрані.

Ось це іде.

1. Програми 3D моделювання, як правило, дозволяють вам вибрати шкалу одиниці. Може бути обмежено імператорською або метричною, але це лише число. Числа можна легко перетворити / масштабувати / регулювати. Це на самому ділі не має значення , що системний блок використовується, якщо ви використовуєте цей один . Будьте послідовними, тому 1 метр не стає 1 футом.

   Редагувати: Книга: Кодування гри завершено, Третє доповнення, глава 15, стор. 525, "Метри, ступні, кубики чи келікамси?"

2. Ігри з великими шматками вершин можуть зробити кілька справ. Для одного вони можуть розділити його на невеликий фрагмент, і тоді дані, що відносяться до цього фрагменту, можуть вказати зміщення. Дещо схоже на використання Octrees, що є оптимізацією візуалізації, щоб уникнути надання великої частини небачених вершин. Як альтернатива, подвійний може зберігати 1.79769e + 308 , що є досить великим, але детальним числом. Поплавок може зберігати 3.40282e + 038, який теж не потертий.

   Редагувати: Кодування гри завершено, Третє доповнення, глава 13, стор. 410, "Координати та системи координат" (Таблиця додана внизу публікації)

3. Ви, ймовірно, захочете потім скористатися метричною системою або перетворити її у свою власну одиничну систему. Варто зазначити, що ви, ймовірно, збираєтесь трохи змінити цю цінність. Впевнені, що перероблене значення не буде фізично точним. Але це могло б відчувати себе більш точним, скажімо, -9.3 m/s^2.

4. Ви можете це зробити будь-яким способом. Хоча я б сказав, щоб масштаб активу. Якщо ви масштабуєте світ, вам доведеться пройти і змінити гравітацію, швидкість обчислення та всі інші речі. Під час імпорту активів в Unity3D я, як правило, повинен коригувати масштаб моделі в налаштуваннях імпорту, тому я припускаю, що Unity масштабує його. Якщо ви хотіли чогось більшого в цьому напрямку.

5. Великий чи маленький, розмір полігонів / сітки не має значення БІЛЬШЕ стільки, скільки їх багатокутників. Я припускаю, що може бути незначна зміна продуктивності залежно від того, скільки пікселів займає модель, але це все. Крім цього, число, що становить 10 або 100, нічого не змінює на кінці комп'ютера. Обробляти все одно таку ж кількість бітів, це просто той самий біт, який дорівнює 0.

Редагувати: падаюча таблиця передбачає 32-бітний номер IEEE з плаваючою комою.

Game Coding Complete, Third Addition, Table 13.2, pg. 411
Smallest unit         Smallest Representable object  Upper Range    Description of
                      (As a textured polygon)                       largest area

100m                  A group of redwood trees       1.67x10^9      Earth/Moon System
1m                    A Human Being                  1.67x10^7      North and South America
1cm                   A coin                         1.67x10^6      California
1mm                   A flea                         1.67x10^5      San Francisco Bay Area
100 micrometer        A grain of pollen              1.67x10^4      Downtown San Francisco

Вся ця інформація та багато іншого в програмі «Кодування ігор завершено». Автор Майк МакШафрі. Професіонал галузі, який працює над іграми, починаючи від Блек Джека, до Злодія: Смертельні тіні.