Как выбрать коэффициент масштабирования игрового мира 3D?

Я делаю прототип трехмерной игры-танка с физическим моделированием, использую C ++. Одно из решений, которое мне нужно принять, - это масштаб игрового мира относительно реальности. Например, я мог бы считать, что 1 игровая единица измерения в действительности соответствует 1 метру. Это кажется интуитивным, но я чувствую, что могу что-то упустить.

В качестве потенциальных проблем я могу думать о следующем:

1. Совместимость с программами 3D моделирования. (?)
2. Численная точность. (Имеет ли это значение?) Особенно в больших масштабах, как игры, подобные Battlefield, имеют огромные карты: как они не теряют числовую точность, если используют отображение 1: 1 в реальном масштабе, поскольку представление с плавающей запятой, как правило, теряет большую точность при увеличении числа (например, с лучевым литьем, физическим моделированием)?
3. Игровой процесс. Я не хочу, чтобы движение юнитов ощущалось медленно или быстро при использовании почти реальных значений мира, таких как -9.8 m/s^2гравитация. (Это может быть субъективно.)
4. Можно ли увеличивать / уменьшать импортируемые активы или лучше всего подходит для мира с его первоначальным масштабом?
5. Рендеринг производительности. Большие сетки с одинаковым количеством вершин медленнее рендерится?

Мне интересно, если я должен разделить это на несколько вопросов ...

Как правило, вы должны делать все, что работает.

1. Поскольку у вас есть реальные объекты жизни, имеет смысл соответствовать их масштабу (приложения для трехмерного моделирования обычно имеют единицы измерения, метры, футы и т. Д.), Но как только вы отойдете от резервуаров к деревьям и другим пейзажным объектам - им, вероятно, понадобится чтобы пользовательский масштабировался в соответствии с вашим стилем игры (чтобы вы моделировали дерево и имели возможность масштабировать его в редакторе игр, чтобы он выглядел хорошо, много раз вы будете использовать одно и то же дерево, но с другим масштабом для добавления разнообразия).

2. Не перемещайте камеру подальше от источника миров, но перемещайте мир вокруг камеры, расположенной рядом с источником миров. Таким образом вы избежите многих проблем с точностью, которые возникают, когда GPU / физика должны точно сравнивать значения, которые имеют низкую точность. Если вы переместите танк и камеру на 10 км от начала координат, ваша точность будет равна долям миллиметра с помощью float32, и это может вызвать эффекты, аналогичные 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

Вся эта информация и многое другое в Game-Coding Complete. Автор Майка МакШаффри. Профессионал индустрии, работающий над играми от Black Jack до Thief: Deadly Shadows.