Что использовать, int, float или double в современном игровом движке?

Question

[devalone]

Рассмотрим современные CPU архитектуры с 64 битными инструкциями и современные GPU, например, nvidia 1080

Если представлять мир с точностью до миллиметра, то целочисленный тип размером 64 бита позволяет сделать мир размером > 9000000000000 км, double ~10000000000 км и float ~10 км.
int достаточно большой и я сомневаюсь, что кто-то захочет игру с ещё большим открытым миром. Но современные процессоры уже давно имеют сопроцессор для операций с плавающей точкой и я не думаю, что арифметика с плавающей точкой будет сильно медленнее. Если выбирать между float и double, double больше, но видеокарты работают быстрее с float https://en.wikipedia.org/wiki/GeForce_10_series#Ge...
GeForce GTX 1080 Ti: Single precision - 10609 GFLOPS, Double precision - 332 GFLOPS.

Такие движки как Unity используют float, но есть также и те, которые используют double, например unigine unigine.com/en/products/engine/unbounded-world У них не возникает проблем с медленной double арифметикой?

Что лучше использовать для представления положения, скорости, ускорения и т.д. игровых объектов: int(64), float или double?

Или, может быть, разбить мир на кубы размером, допустим 10 км? Но тогда возникают проблемы с рендерингом больших сцен.

Comments

[Denis Gaydak]

Чта? Десятикилометровый мир, с точностью до миллиметра. Зачем? На чем вы столько геометрии отрисуете? и вообще точность числа и размер мира- мягко говоря почти никак не связанны. в камеру/рендер даже если и попадет все сразу (с далека, при нереальной дальности отрисовки) - там будет плевать на обхекты в далеке, хоть они на метр не точно стоят.
В общем что то вы странное перемудрили так вот сопоставляя миллиметр и точность числа.

[devalone]

Denis Gaydak: тут дело не только в рендеринге, если делать мир размером, допустим, как Земля, то на краях сцены могут возникнуть проблемы с расчётом коллизий, движения объектов и т.д. из-за неточности float и чем больше мир, тем больше погрешность.

[Евгений Шатунов]

devalone , хороший вопрос. :)
Но в ответчики я набиваться не буду. maaGames очень хорошо ответил, считай это решением.

А на счет точности до мм есть очень важная штука. Может ты ее и упустил из виду. Поэтому уточню.
Весь мир в единой системе координат делать безрассудно. Координатная система мира может быть иерархической и включать в себя подсистемы координат. Для комфортного представления мировой позиции объекта достаточно от 2х до 4х уровней вложенности.
Соответственно, на самом нижнем уровне для позиционирования можно использовать float, а дальше - хоть uint8_t.

[devalone]

А на счет точности до мм есть очень важная штука. Может ты ее и упустил из виду. Поэтому уточню.
Весь мир в единой системе координат делать безрассудно. Координатная система мира может быть иерархической и включать в себя подсистемы координат

Т.е. предлагаете хранить несколько вариантов координат для одного объекта? И делать несколько вычислений вместо одного?

[Евгений Шатунов]

devalone , а скажи вот, какие вычисления ты собрался делать? :)
Если у тебя есть клеточная локация, где одна клетка - это один метр, то какие дополнительные вычисления ты должен делать с индексами клеток во время свободного перемещения внутри клетки?

Если у тебя мир порезан на чанки размером 100x100м, то какие манипуляции с индексом чанка тебе надо делать во время перемещения внутри него? Граница чанка - сущность однозначная и тоже не предполагает дополнительных расчетов при ее пересечении.

А если мир реально большой и сперва состоит из регионов, каждый из которых - из зон, каждая - из секторов, каждый - из чанков, то зачем тебе использовать всю иерархию систем координат где-либо еще кроме загрузки содержимого очередного чанка?

Вот, загляни к Алексу на сайт: aigamedev.com/open/review/near-optimal-hierarchica...
Статья примерно о том-же, только для решения задачи поиска пути. Это на случай если моего слова в деле мало.

Answer 1

[maaGames]

И то и то и то. В видеокарту double лучше не передавать (особенно в карточки nvidia), поэтому float. В физическом движке лучше double, либо вещественное число с фиксированнй точкой (читай int/int64).
У вас ошибка в суждениях. 1мм - это много или мало? Для линейного размера нормально? А для углового? А если пять раз повернуться по часовой стрелке и три раза против часовой, при этом координата сохраняется с точностью до миллиметра? Если поворачиваем корабль, длиной в 300 метров? А если карандаш, длиной 7 сантиметров? А если это моргает персонаж? Т.е. нужно использовать те типы данных, которых достаточно для представления тех данных, с которыми работаете. Причём, они вполне могут конвертироваться друг в друга, возможно, с потерей точности.

Answer 2

[laxikodeje]

флоаты ОЧЕНЬ СИЛЬНО ЗАМЕДЛЯЮТ расчеты.
хотя и позволяют избегать округлений, неточности и переполнений ГОРАЗДО лучше, чем инты.

что и где использовать - решать вам самому.
зависит от конкретных мест.
а будет ли там тормозить на не самом крутом железе.
или вы ориентируетесь только на топовое железо.

если сомневаетесь - проводить тесты, эксперименты, замеры скорости.

что именно где использовать - без тестов и экспериментов вы будете знать заранее только с опытом.

UPD:

то целочисленный тип размером 64 бита позволяет сделать мир размером > 9000000000000 км, double ~10000000000 км и float ~10 км.

Зависит от логики вашего мира.
Может, будет проще сделать 128-битное целое - это все равно будет очень быстро.

или разделить мир на независимые сегменты - все равно очень далекие друг от друга объекты не взаимодействуют скорее всего.
такая технология была еще в прошлом веке задействована в процессорах именно для адресации. так называемый "сегмент:смещение" и "короткие ближние адреса" и "дальние длинные адреса".

Comments

[devalone]

или вы ориентируетесь только на топовое железо.

На то, которое топовое сейчас с расчётом, что когда я допилю движок оно станет средним)

[laxikodeje]

devalone: правда?
я вот уже лет 5 не менял и не собираюсь. прекрасно играется.
лет 10 назад - тогда да, видеокарту меняли 50% игроманов каждый год.

[laxikodeje]

devalone:
В любом случае - нужно смотреть от ваших задач.
Все тестировать и проверять.
Предусмотреть, возможно, несколько режимов качества.

[devalone]

или разделить мир на независимые сегменты - все равно очень далекие друг от друга объекты не взаимодействуют скорее всего.

именно про это я и говорил тут:

Или, может быть, разбить мир на кубы размером, допустим 10 км? Но тогда возникают проблемы с рендерингом больших сцен.

Ну и тут ещё могут возникать проблемы при взаимодействии объектов на границе.

[laxikodeje]

devalone:

Ну и тут ещё могут возникать проблемы при взаимодействии объектов на границе

сегменты пересекаются.

[devalone]

laxikodeje: тоже об этом думал, но тогда возникают проблемы с обработкой объектов на пересечении, если объект принадлежит обоим сегментам, нужно хранить 2 варианта координат и следить за тем, чтоб объект не обрабатывался дважды, если одному, то нужно делать преобразование координат (это в принципе не особо затратно по ресурсам).

[laxikodeje]

devalone:
это преобразование сегментов и адресов в процессорах прошлого века, которые медленнее процессоров современных телефонов (не смартфонов) - было реализовано очень быстро.

https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%B3%D...

[laxikodeje]

devalone:

представим для упрощения ваш мир одномерным массивом длинной гугол.
весь его подгрузить в оперативную память невозможно.
весь его просчитывать также невозможно.
но для работы игры "здесь и сейчас" вам достаточно подгрузить из этот длинного массива кусочек начиная с адреса 1 млн. по адрес 2 млн.
а затем, по мере смещения игрока, подгрузить кусочек с адреса 2 млн. по адрес 2 млн. + 100 000. и выкинуть с адреса 1 млн. по адрес 1 млн. + 100 000.

[devalone]

laxikodeje:
Сделал простенький бенчмарк(https://toster.ru/q/444037), надеюсь, что учёл всё что надо, для чистоты эксперимента(real time систему разве что не использовал).
Результат получился следующий: скорость арифметических операций float и double на CPU одинаковая(в пределах погрешности), а целочисленный тип быстрее плавающей точки примерно в 1.4 раза на AMD FX6300, примерно в 1.3 раза на pentium3825u и примерно в 1.3 раза на Xeon E5-2643 v3(другого железа под рукой не было).
Учитывая, что квадратные корни, синусы и прочее интегрировано в современные сопроцессоры, возможно лучше будет выбрать именно double для мировых координат, а видеокарте отдавать float после преобразований.

[laxikodeje]

devalone: где то вы что то не так сделали.
разница между целочисленным и плавающей запятой - существенно больше.

[devalone]

laxikodeje: ну, судя по вот этим данным www.agner.org/optimize/instruction_tables.pdf разница больше. В любом случае херня это всё, нужно делать два варианта игровой сцены и тестить)

Answer 3

[Mercury13]

Предварительные расчёты (например, координаты моделей) проводить в типе достаточной точности (и, разумеется, на процессоре). Окончательные — в привычном float.
И, понятное дело, для открытых миров придётся писать свои «велосипеды» по отсечению далёких горизонтов, и Unity в стандартной поставке не уверен, что подойдёт.

Ещё раз. Координаты участников игры записываются в double. Координаты вершин модели — во float. Мы на процессоре проводим начальные преобразования координат, убеждаемся, что координаты заслуживают того, чтобы их рендерить, преобразуем во float и гоним на видяху.

Comments

[devalone]

А если часть вычислений, например, коллизии, надо будет перенести на GPU? Тогда придётся терпеть медленную скорость работы double, ну или мудрить с преобразованиями координат.

[Mercury13]

devalone: Мудрить. И только мудрить. Мы ведь можем как-то прикинуть, достаточно ли близок самолёт, чтобы вместо охватывающей сферы использовать детальный хитбокс?

Answer 4

[Сергей]

У флоат есть такая штука как ошибка представления.
Например выражение (1/3) * 3 = 0.999999996 для машины может быть вполне истиным :)
Да и операции с Int на порядки быстрее всегда.