Как избежать проблем с плавающей запятой на больших картах

Всем привет!
Собственно, уже второй раз поднимаю этот вопрос. Первая тема носила теоретический характер. Я как бы слышал об этой проблеме, но не сталкивался с ней вживую. А вот теперь, когда настала пора собрать мои наработки в кучку, вижу, что проблема реально есть и я даже пока вообще не представляю как ее решить.

Имеется карта размером 6000х6000 юнитов (6х6 км). Совсем небольшая карта, если в игре есть автомобиль.
Центр координат в центре карты, т.е. если отойти на край карты, удаление от центра будет +/- 3000.
И вот на этом удалении имеем вот это:

Дрожание анимации персонажа начинается уже где-то при удалении от центра на чуть больше 1000 юнит. Чем дальше, тем хуже. Т.е. эффективная карта должна быть 2х2 км (с 0:0:0 в центре), чтобы не было такого дрожания. Но это же несерьезно в 2024 году.

Я читал про джиттеринг и способы его решения методом переноса центра координат мира к игроку и т.д. Но, во-первых, все эти методы довольно старые, я нахожу статьи и видео 2019-2020 года. И они не идеальны, т.к. несут некоторые проблемы. К тому же незнание английского языка не способствует хорошему пониманию найденного материала (переводчик переводит, но как-то не так, как это хочет сказать автор).

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

0

Сообщение от alexsecl Хм... а как это будет работать со статичными объектами, в частности с навигационной сеткой, которую используют нпс и враги?

Нормально, через NavMeshBuilder, так все открытые миры на юнити работают.

0

Кстати, пока тестировал смещение начала координат, призадумался, а как реализовывать сохранения в таком случае? Сейчас у меня сохраниться можно в любом месте, так как позиция мира неизменна. Сохранил текущий вектор персонажа - загрузил сохраненный вектор. А при использовании смещения начала координат, положение мира и всего что на нем, будет сбрасываться. И как тогда получать координаты (персонажа, к примеру) и загружать их?

0

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

0

Aledveu, мир будет наподобие пустыни из игры Mad Max. Переход с локации на локацию прям посреди пустыни такое себе...

0

alexsecl, это не переход с локации на локацию.
это метод организации неограниченного мира.
мир делится на регионы - обычно квадратные.
количество загруженных регионов определяется дальностью прорисовки + запас.
переход между регионами происходит мгновенно ибо это просто представление координат.
регионы постепенно подгружаются по мере движения персонажа.
это классический типовой подход для неограниченного мира.

0

Aledveu, вы имеете ввиду что-то типа такого?

Если да, то эта система подзагрузки/выгрузки регионов призвана улучшить производительность игры, а не решить проблемы с плавающей запятой на удалении от начала координат, нет разве? Допустим, первый регион расположен по координате 0,0,0. Второй регион по координате 1000,0,0. Третий - 2000,0,0. И т.д. Чем дальше от нуля, тем больше проблем с плавающей запятой.
Если вы что-то другое имели ввиду?

0

Сообщение от alexsecl Кстати, пока тестировал смещение начала координат, призадумался, а как реализовывать сохранения в таком случае? Сейчас у меня сохраниться можно в любом месте, так как позиция мира неизменна. Сохранил текущий вектор персонажа - загрузил сохраненный вектор. А при использовании смещения начала координат, положение мира и всего что на нем, будет сбрасываться. И как тогда получать координаты (персонажа, к примеру) и загружать их?

Элементарно, хранить координаты как VectorD, а координаты VectorF пересчитывать динамически относительно позиции камеры.

Сообщение от alexsecl Если да, то эта система подзагрузки/выгрузки регионов призвана улучшить производительность игры, а не решить проблемы с плавающей запятой на удалении от начала координат, нет разве?

Для адекватной скорости загрузки(привет готика 2) и разделения редактирования мира дизайнерами.

Сообщение от alexsecl , а не решить проблемы с плавающей запятой на удалении от начала координат, нет разве?

Это решит проблему, ведь все будет храниться в double.

0

Сообщение от jetyb Это решит проблему, ведь все будет храниться в double.

Так... У меня уже голова кругом. А зачем тогда мудрят со смещением мира (origin shift), если есть этот более простой способ - разделить мир на "регионы"? Или все же есть какие-то нюансы?

0

Сообщение от alexsecl а не решить проблемы с плавающей запятой на удалении от начала координат

у вас не будет объектов от камеры более чем на пару регионов.
при переходе в другой регион нулём становится ноль региона.
абсолютные координаты региона можно хранить хоть в int64_t, но они для отображения не нужны - они только когда ищется соседний регион или надо карту всего мира сделать.

0

самый главный момент, это смещения игрока и мира на один вектор(одно и то же расстояние). что бы игрок стал в ноль и мир сместился с ним на такое же расстояние. например это можно делать во время загрузки игры.
тут человек предложил тип данных double. эти данные используются в банковской системе. и не спроста. в них число чисел после запятой на порядки больше, а следовательно, точность возрастает. как вариант использовать самописную структуру типа Vector3 или полностью Trancform, но не на float, а на double.
но расчеты таких чисел будут медленнее и памяти они занимают больше. для мощного железа, это конечно не особо критично, но все же...
думаю нужно колдовать с синхронным перемещением мира и игрока в удобные моменты, чтоб не было особо заметно.

0

Gammister, никаких даблов - даже не думайте в эту сторону.
конечные трансформации будут производится в шейдерах на видеокарте и никаких гарантий что у пользователя видюха будет их поддерживать и не сконвертирует во флоаты.
это как раз одно из основных отличий профессиональных графических карт от игровых - что на профессиональных полная поддержка даблов для расчётов как на уровне аппаратуры так и драйверами. а для игр достаточно точности флоатов.

0

спасибо за подсказку. буду иметь в виду

0

Сообщение от Aledveu у вас не будет объектов от камеры более чем на пару регионов. при переходе в другой регион нулём становится ноль региона.

Как вообще реализовать это? Вернее, как называется такая система? Просто тупо не знаю как сформировать запрос в гугле, чтобы он выдал документацию и туториалы. Если своими словами пытаться запрос формировать, выдает совсем не по теме.

0

Сообщение от Aledveu Gammister, никаких даблов - даже не думайте в эту сторону. конечные трансформации будут производится в шейдерах на видеокарте и никаких гарантий что у пользователя видюха будет их поддерживать и не сконвертирует во флоаты.

Да никто и не сможет на юнити double в видеокарту передавать и нормально с ними работать.
Разве что запилит там аддонами полностью свою систему рендеринга.

0

у меня игра галактических масштабов и я разделил мир на несколько ступеней, скажем самые огромные масштабы где расстояния между звездами, там стоит отдельная рендер камера и рендерит бекграунд с галактикой, сама галактика со звездами с точки зрения движка в тысячи раз меньше реальных масштабов, на средних околозвездных масштабах принцип такой-же правда эта текстура уже появляется перед галактикой и рендерится после нее, ну и на обычных масштабах я как раз пошел по принципу костыля где двигается мир относительно игрока, ну и физика в игре у меня тоже своя так что это было не так болезненно как если бы я пытался rigidbody использовать. хотя если бы мне все-таки пришлось использоваться я бы скорей всего просто создал свой класс который обрабатывает эти изменения позиций мира для физики и наследовал бы этот класс от rigidbody.

0