Реализация карты тайлов / ландшафта с различной высотой соседних тайлов

10

Ahoy!

Я ищу некоторую информацию о картах плиток, или, скорее, как называется конкретный тип карты плиток.

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

Было трудно найти какую-либо приличную информацию, так как большинство людей называют ее изометрической плиткой, но я стремлюсь создать что-то в 3D с фиксированной орфографической перспективой. Я понимаю, что основное хранилище карты тайлов не имеет ничего общего с тем, как она отображается, но я не собираюсь создавать двухмерную карту тайлов, как в старых играх покемонов / зельда, в большей степени в духе Diablo с возможностью включать нависающие скалы и наклонная местность.

Я просто пытаюсь найти правильные термины для поиска в Google и stackoverflow ресурсов, которые помогут мне решить, какой путь продолжить.

До сих пор мне удавалось конкретизировать базовую карту тайлов без использования компонента height / y, который хранится в VBO и отображается как каркас. Пока все выглядит хорошо, но я предполагаю, что у меня возникнут проблемы при попытке манипулировать одной вершиной, чтобы создать скалы и уклоны, не затрагивая соседнюю плитку.

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

Если кто-нибудь может пролить свет на это для меня, пожалуйста, помощь будет принята с благодарностью :)

Обновить

Я включил изображение для дальнейшего разъяснения того, чего я хотел бы достичь:

2.5D карта тайлов

Изображение заимствовано из Как создать наклонную (высоту) изометрическую плитку

Это изображение показывает тип местности, которую я хотел бы создать, но не включает в себя «скалы» или нависающие типы местности, которые мне интересны в моделировании. Это, однако, поднимает несколько других вопросов, которые я не рассматривал, а именно;

  • Как будут обрабатываться «слои», такие как вода (вверху слева на изображении), чтобы включить видимую почву под водой?
  • Как можно было бы обслужить «края» карты, чтобы земля / грязь отображались как неплоская сущность?
  • Может ли базовое хранилище для этого вида местности использоваться для моделирования физики, такой как мяч, катящийся по склону, или скорости движения игрока, пересекающего склон?

У меня была идея, что каждая плитка ландшафта может быть смоделирована с 8 вершинами, где 4 основные вершины покрывают саму фактическую плитку, а оставшиеся 4 вершины используются для моделирования сторон / стенок каждой плитки. Две проблемы, которые я вижу с этой реализацией, состоят в том, что а) карта мира по существу удваивается в размере и б) учитывая, что не все плитки будут содержать "стены", некоторые плитки будут иметь избыточные вершины, которые не используются.

Я хотел бы создать редактор ландшафта, который позволяет деформировать каждую плитку, а также включать возможность изменения ландшафта во время игры. Это само по себе ставит дополнительные вопросы, такие как; Можно ли использовать VBO для хранения и рендеринга ландшафта во время его изменения на лету, а также можно ли изменять вершины, не затрагивая соседние тайлы?

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

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

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

Спасибо за чтение!

CaptainRedmuff
источник

Ответы:

2

Если бы я был тобой, я бы посмотрел на вокселы, а точнее на рендеринг кубов типа Minecraft . В отличие от карт высот, они могут обрабатывать свесы, пещеры, многоэтажные здания и т. Д.

Вы бы сохранили свою местность в трехмерном массиве целых чисел, где числа сопоставлены с определенным типом местности: 0 = воздух, 1 = грязь, 2 = вода и т. Д. Затем, чтобы создать сетку для рендеринга, вам нужно создайте грани куба для каждого непустого вокселя.

Этот урок является отличным объяснением того, как сделать это в C ++ с использованием Ogre3D. Я полагаю, вам придется перейти на более низкий уровень в OpenGL.

После создания кубов вы хотите сгладить края, чтобы создать вид плавной поверхности, показанной на изображении. Я считаю, что PolyVox (также в C ++) делает это; Вы могли бы взглянуть на их код. Я думаю, что вы в основном делаете в 3D то, что изображение показывает в 2D: усредните положения окружающего куба, чтобы знать, где разместить каждую вершину.

РЕДАКТИРОВАТЬ:

  • Создайте грани для кубов, смежных с водой, как если бы плитка для воды была пустой, и визуализируйте грани воды прозрачно.
  • Грани на «краю» могут быть сгенерированы так же, как обычные грани, если вы считаете воксели вне мира пустыми.
  • Физика: Вы, вероятно, можете подать визуализированную сетку на физический движок как статический объект.
  • Редактор карт: вы хотите редактировать базовые данные вокселей, а не саму сетку! (Сетка должна отражать данные, поэтому редактирование вокселей должно привести к изменениям в вашей сетке.) Возможно, вы захотите поискать Модель, Вид, Контроллер (MVC), если вы с ним не знакомы.

Если у вас есть еще вопросы, не стесняйтесь оставлять комментарии. Добро пожаловать в gamedev.SE!

Wackidev
источник
Это очень сложное решение для относительно простой задачи. Множество игр сделали то, о чем просит ОП, без сложности вокселей.
Шон Мидлдич
Я согласен, что вокселы могут быть сложными. Не могли бы вы дать ссылку на эти игры? Мне интересно услышать, как они это сделали.
Вацидев
Я играл с идеей использования вокселей. Означает ли эта реализация, что все кубы имеют единичные размеры, или может быть выдавлен один куб? Я предполагаю, что мир должен был бы быть сохранен в слоях, чтобы позволить воде и другим плиткам, которые могут "перекрываться" вдоль y-плоскости.
CaptainRedmuff
Да, обычно воксели имеют размер блока. Я полагаю, что их можно было бы вытеснить, но я думаю, что это только усложнит ситуацию. Я не уверен, что понимаю, что вы имеете в виду под слоями. Вы имеете в виду водную плитку переменной высоты?
Wackidev
Что-то в этом роде. Я больше думал о том, чтобы просто определить «пол», который мог бы быть выдавленным кубом, который затем имел бы водяной куб сверху, определяемый плоскостью, где они пересекаются. Возможно, я снова усложняю вещи. Я еще немного прочитаю воксели и посмотрю, к чему это меня приведет.
CaptainRedmuff
6

Это: http://30.media.tumblr.com/tumblr_m06qv6OREt1r2qjpao1_500.png является примером карты, которую я сделал некоторое время назад.

У меня был XML, представляющий карту и различные типы плиток. Каждый тип будет иметь несколько атрибутов:

  • Высота
  • Должность
  • Тип слияния: какой тип слияния будет выполнять эта плитка ALL(если она должна слиться с любой плиткой вокруг нее) EQUAL(только слияние с плитками того же типа) NONE(никогда не объединяться).
  • Высота слияния: максимальная высота для уклонов (хорошо для выступов), допустим, вы хотите, чтобы плитка объединялась только с плитками одинаковой высоты или с разницей 1, значение будет равно единице.

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

Хотя мои модели являются гексами, концепция та же самая, вам нужен куб для представления плитки, затем вы переместите базовые вершины на самый низкий уровень и «сгладите» верх куба с кубиками вокруг него. Вы также проверите, были ли объединены две стороны кубов, так что вы можете просто удалить эту сторону из куба (если они не объединены, это, вероятно, утес или что-то в этом роде).

О физике зависит от твоей цели. Если вы делаете что-то вроде магната с американскими горками, они вам на самом деле не нужны. Вы можете просто проверить высоту игрока между каждой плиткой и решить скорость ходьбы. Вы можете сделать то же самое для объекта, который движется сам (например, мяч), вы можете проверить плитки вокруг (или текущий угол плитки) и решить направление / скорость. Если вам нужна реалистичная физика (например, гравитация, трение и т. Д.), Вам придется использовать физический движок, и вы можете использовать трехмерное представление куба в движке.

Слои также возможны, но вам понадобится что-то вроде майнкрафта (со сглаживанием кубов в верхнем слое). Если вам нужны только слои для воды, у вас может быть «водяной источник» на плитке, и ваш код должен заполнять каждое пространство вокруг него, которое находится на той же высоте или ниже (рекурсивное решение здесь вполне подошло бы).

Редактор рельефа также будет простым, если ваш код достаточно гибок, вы можете применить преобразования к одной плитке (той, которую вы меняете) или к списку плиток (если вы используете «кисть» для выберите и переместите их). Этот же код можно использовать для изменения ландшафта в игре. И да, вы можете изменять вершины в VBO, также можно менять вершины, не влияя на другие (это также зависит от того, как вы кодируете).

Люк Б.
источник
+1 Спасибо за ваш вклад по этому вопросу. Вы поднимаете хороший вопрос о расслоении в отношении «водяного источника», который я раньше не рассматривал. Сейчас я посмотрю, как модифицировать VBO, когда знаю, что это возможно :)
CaptainRedmuff