Моделирование сферического игрового пространства (планета)
 

Заинтересовался идеей не плоского мира, а сферического, отличный пример - планета.

Давайте по обсуждаем идею, математические и алгоритмические сложности данной задачи, и вообще идеи по моделированию планет и игрового пространства на них.

Например давайте посчитаем сколько данных нужно для высотной карты всей планеты Земля?
Земля имеет радиус 6,378,100 метров.
Используя формулу площади сферы - 4 * PI * r^2 мы получим площадь планеты земля: 511,201,962,310,545 кв. м.
Далее зная площадь, если мы хотим создать высотную карту всей планеты с детализацией до 1 метра, нам понадобиться предположим 2 байта на ячейку. И это выходит 929.871 терабайт данных.
Естественно числа заоблачные, что говорит о создании высотной карты всей планеты - не вариант для игр.
Конечно есть интересные подходы совмещения подготовленных и процедурных данных, теоретически можно иметь детализацию всего на каждый километр, тем самым снизить объём данных всего до 975.04 мегабайт на всю планету! Ну и далее использовать процедурный шум для детализации, но естественно детальность не будет столь качественной и реалистичной, но для космического симулятора - по моему отличный вариант.

А теперь представьте сколько данных хранит Google для их карт, снимков satelite, и ещё не забываем что основные карты они генерируют на лету при каждом запросе.


Но отклонимся от высотной карты.
Как насчёт координатной системы?
В плоском мире используется X и Y. А в плоском 3D мире X, Y и Z, но сам мир по прежнему плоский, что делает эти координаты всегда прямыми.
В сферическом мире - это Прямоугольная Система Координат (Cartesian coordinate system). Основная разница в том что например координата Y - не будет указывать на высоту объектов от уровня моря (например), а в абсолютных координатах будет указывать "вверх" относительно севера. Что на разных позициях на планете воспринимается по разному. На южном полюсе - это это указывает под землю, а на экваторе вдоль земли, а на севере от земли.
Следственно работа с прямоугольной системой координат не удобна для математики и логики работы с поверхностью земли.

Есть Сферическая Системам Координат, которая хранит координату в трёх измерениях, расстояние до центра, зенитный и азимутальный угол.
Такая система координат возможно удобна для навигации, т.к. зенит и азимут весьма интуитивны для представление относительно сферы.
Но я не вижу никакого применения в математике этой системы координат.

Далее идут Географические Координаты (Geographic coordinate system), это очень схожая система координат со сферической, но немного удобнее засчёт более интуитивных углов.
Мы повседневно имеем дело с этой системой координат используя GPS навигаторы.
Т.к. на нашей планете нам не нужно знать о расстояния от центра земли, мы обычно имеем лишь долготу и широту (longitude, latitude), и эти два числа очень удобны в ориентировании снова.
Но в 3Д они снова слабо применимы. Во первых вычислять расстояние между ними воспринимая их как X и Y в корню не верно. Т.к. расстояние по сфере - это дуга а не две точки.
Также выше от экватора долгота имеет меньшее расстояние между градусом.
В интернетах часто можно встретить как кто-то используя Google Maps берёт долготу и ширину и применяет теорему пифагора для вычисления дистанции, и затем умножает на коэфициент (который видиом подобрал), таким образом "получает" расстояние в километрах (или других мерках). Но проблема в том что на экваторе это может и будет работать с верных коэффициентом, а вот на полюсах совсем нет.
Следственно вычисление расстояния не так и просто, т.к. работая с углами, нужно вычислять по дуге. Благо формул в интернетах не мало.

Хоть долгота и ширина, удобны для пользовательской навигации, они же не удобны для математики.

Так что же, мы получается возвращаемся к X, Y, Z? По моему - да.
Только вот как же делать разного рода вычисления корректно, учитывая все сложности не плоскости пространства.

У меня была идея что нужно трансформировать все координаты для определённого вида, исходя из того где находится камера. Например если центра вычисления на Аляске, что выше экватора но не на полюсе, то нужно трансформировать все данные с которыми предполагается вычисления. Поворачиваем их так, чтобы X и Z - были перпендикулярны вектору от центра камеры к центру планеты.
Тогда X и Z - будут как в плоском мире, а Y - будет высотой от земли.

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



Вообще интересует кто таки дочитал до конца, и что думает по этому поводу?
Особенно интересует методы проецирования сферических данных на плоскость в мелких масштабах.

Ответ: Моделирование сферического игрового пространства (планета)
 

Я игры никогда не делал, но тоже задавался подобным вопросом. Хотел сделать 2D игру с замкнутой картой, представляющую собой шар. Первое, что приходит в голову: замкнуть левый край карты с правым, а верхний край с нижним (как в пакмане), но таким образом мы получим не шар и не куб, как может показаться на первый взгляд, а тор, у которого, помимо прочего, внешний круг и внутренний будут иметь одинаковую окружность засчёт того, что "клетки" мира имеют одинаковые размеры между собой. По ходу получается геометрическое тело, невозможное в евклидовом пространстве. Для какой-нибудь фантастической игры, где действие происходит в параллельной вселенной с планетами в виде пончиков, идея неплоха, но мне хотелось что-то более близкое к реальности. Ну а так как в математике я не шарю и придумывать что-то более сложное, чем квадратные спрайты для карты мира, не хотелось, идею забросил. Но если кто-то предложит простое решение, интересно послушать.

Ответ: Моделирование сферического игрового пространства (планета)
 

Мне тоже интересно.
Но читать всё, стало страшно, хотя кое-что понял.
Когда я слышу слово математика, я хватаюсь за пистолет. :-)

Ответ: Моделирование сферического игрового пространства (планета)
 

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

Ответ: Моделирование сферического игрового пространства (планета)
 

А что используется в Kebal space program? Процедурная генерация ландшафта?

Ответ: Моделирование сферического игрового пространства (планета)
 

Для этого существуют такие науки как Геодезия и Картография.
И соответственно существуют формулы для пересчёта географических координат в плоские координаты. Так же есть формула для нахождения расстояния между точками на поверхности земли в географических координатах по поверхности.

Ответ: Моделирование сферического игрового пространства (планета)
 

Эти науки известны.
Но ты говоришь Картографической Проекции (http://en.wikipedia.org/wiki/Map_projection), это отличный метод визуализации поверхности планеты на плоскость и дальнейшей работы с этими данными, но тут есть проблема в том что это не годится для работы с вычислениями, т.к. даже расстояние будет всё равно считаться исходя из долготы и ширины используя формулу которая считает расстояние по дуге, которую ты упомянул.

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

Ответ: Моделирование сферического игрового пространства (планета)
 

Гугл ничего на лету не генерирует. Представь что человек открыл гугл карты и нашел Лондон. Площадь Лондона - 1700кв. км. учитывая их точность каждый кв. км будет примерно 5000х5000 px. В итоге гуглу надо на лету отрендерить 1700кв.км по 25кк пикселей, то есть 42'500'000'000. На лету. И это только 1 человеку... Гугл бы сдох уже завно. Все растры (и 90% векторных карт) тайлятся и кэшируются. В итоге их js карты просто вычисляют какие тайлы нужны для заполнения вьюпорта, и загружают их.

Вся математика в системе координат "долгота/широта" очень проста. Это же простой эллипсоид и углы. Там все в пределах синуса и косинуса.
http://en.wikipedia.org/wiki/Haversine_formula
http://www.movable-type.co.uk/scripts/latlong.html
Проекция на плоскость совсем другое дело.
http://ru.wikipedia.org/wiki/%D0%9A%...86.D0.B8.D0.B8
Изначально самой удобной проекция была проекция меркатора т.к. она сохраняет углы, а значит удобна для навигации (мореплавателям например). На сегодняшний день ничего лучше толком не придумали (и не придумают), только сделали несколько уточнений о форме земного шара (т.к. это не шар и даже не эллипсоид вовсе). В Роиссе например используются т.к. называемые местные ск. Для каждого региона местные органы самоуправления определяют систему координат. Эти системы координат являются произвольными и как правило одна система координат определяется для кусочка в 3 градуса долготы. Таким образом получается проекция этого кусочка на плоскость, при этом она с математической точки зрения не сохраняет ни углы ни площади, но значения проекции подобраны так, что по карте можно вычислять и углы и площади с определенной точностью (то есть погрешность будет, но она в допустимых пределах).

Для игры вся эта геодезия нахрен не нужна.

Ответ: Моделирование сферического игрового пространства (планета)
 

...в вакууме?

Ответ: Моделирование сферического игрового пространства (планета)
 

Опровергаю. Во первых смотрел презентацию от самих Google которые рассказывали всю историю их алгоритмов, что они раньше кешировали, а сейчас снова генерируют всё на лету динамически.
Подтверждение этому, простая туулза для кастомизации вида карты:
http://gmaps-samples-v3.googlecode.c...ard/index.html
Заметь, тут можно изменить визуальный аспект любого элемента, текста и т.п. карты. Также текст локализируется тоже динамически и рендерится в карту.
Что подтверждает динамичность генерации. Без неё было бы очень сложно иметь такое разнообразие в картах.
Также вот почитай тут: http://www.theatlantic.com/technolog...ything/261913/

Лучше почитай и проверь, прежде чем делать свои выводы, которые могут ограничиваться твоими представлениями о возможном.


Я об этом уже писал. И знаю что это просто. Только это не даёт возможности удобно делать вычисления.
Например у тебя есть турель на здании, далее идёт моб, и турель нужно с определённой скоростью повернуть на моба.
В представлении X, Y, Z и плоского мира - это элементарно просто, вектор - и крутим его.
А вот имея Прямоугольные координаты, по сути вычислений ничего не меняется, Но, чтобы вычислить например горизонтальный поворот относительно плоскости земли - нужно делать дополнительные вычисления.
Следственно работать с сферическими или прямоугольными данными напрямую - не удобно ни в каком случае.

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

Ну так замути на планетку, с машинками, дорогами, строениями и человечиками на ней.
И так чтобы можно было с ощущением плоскости поуправлять машинкой или человечком.
Я посмотрю как ты справишься, мы все поучимся.

Ответ: Моделирование сферического игрового пространства (планета)
 

Ответ: Моделирование сферического игрового пространства (планета)
 

А если наплевать на плоские карты высот и использовать трех или более мерный шум. То есть берем обычную сферу с более менее регулярной сеткой, наподобие той же геосферы, потом для координат каждой точки поверхности из шума получаем ее высоту над уровнем моря. Умножаем вектор от центра сферы до точки на эту высоту. И в полученную координату ставим точку. В итоге получаем сферу деформированную к планетному виду причем без искажений у полюсов или еще где как было б при наложении двумерного шума.

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

Ну и работать в обычных координатах.

Ответ: Моделирование сферического игрового пространства (планета)
 

Я не вижу как это решит проблему с относительностью шума на полюсах границе долготы где две стороны будут смешиваться.
Ведь шум - он не с балды берёться, а в зависимости от X и Y, можно конечно внести и Z, но это 3D шум, что совсем другого типа шум, и он да будет работать. А простая 2D карта шума, всё равно не спроецируется на сферу.

Ты предлагаешь иметь 2Д шум на локальные участки? Это может и сработать, только я тебе снова дам задачку - 2Д карта, обычно квадратная, а покрыть ровнымы квадратами всю планету - невозможно, следственно как ты разобьёшь сферу на квадраты?

Прямоугольных? Это снова не решает проблемы описанной выше с углами и относительности игрового пространства на плоскости в близких масштабах.

Ответ: Моделирование сферического игрового пространства (планета)
 

Нет же. 3д шум дает для каждой точки пространства какое то свое значение. Зачем читать какуюто одну плоскость и затем деформировать ее к сфере если можно сразу считать шум лежащий на поверхности сферы.
Не разбивать сферу. Вот когда она целиком влазит в экран то она сфера. А когда не влазит, то берем и делаем плоскость перпендикулярную вектору от центра планеты к камере. Размещаем эту плоскость на расстоянии радиуса от центра планеты. Дальше есть у нас координаты каждой вершины, соответственно и есть вектор от центра до вершины плоскости, и если этот вектор нормализовать, а потом умножить на радиус, то эта плоскость замечательно обернется вокруг сферы. Затем вот эти новые координаты точек лежат на той поверхности внутри 3дшума с которого можно читать нужные смещения для точек этой уже выгнутой по сфере поверхности. нет никакого разбиения.

Ответ: Моделирование сферического игрового пространства (планета)
 

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