Легко ли будет отобразить даже небольшой кусочек мира ?

Играюсь с полигональными вокселями. Имеется:
1. Чанк размерами 4х4х4 метра из 4096 блоков.
2. Размер хранимой информации для 1 чанка ~ 20 кб.
3. Локация размерами 8х4х8 км.
4. каждый чанк помимо информации о блоках имеет уникальный 8 байтовый идентификатор.


Просто расчеты, для отображения такйо локации минимальными размерами блоков или хранить эту информацию в минимальных размерах, необходимо:

2000 х 1000 х 2000 чанков = 4 Гб * 8 байт (идентификатор) = 32 Гб необходимо только для хранения информации о самих чанках.

Добавляем к этому 20 кб информации о блоках - получим 2000 * 1000 * 2000 * 20000 = 8 * 10^13 байт.

или 80 000 000 000 000 байт или ~ 70 Тбайт информации для отображения локации 8х4х8 км 25 см блоками. никакого харда не хватит.

До отображения реального мира в мельчайших деталях такими темпами еще не одно поколение пройдет.

Наконец то начинаю осваивать профессию демиурга.

Балуюсь с алгоритмом Marching Cubes для генерации полностью разрушаемого террейна (земли). Согласно мануалам алгоритм не предполагает использование фигур с ровными кубическими гранями, то есть чистый куб не получить никак. Точнее есть расширенная таблица треугольников, но где ее искать я, честно признаться, не знаю. Поэтому остается экспериментировать с тем, что есть и модифицировав немного алгоритм, оказалось, что невозможное возможно... уж я то знаю :)

Конечно пока не чистый куб, но ровные грани уже есть, остается это систематизировать.



Collapse )

Учусь программировать. Процедурная вода 2D. Пробую флюиды.

ч. 6 Учусь программировать. Алгоритм авторазметки или подсчет отдельных объектов на поле.

Все никак руки не доходят, чтобы взяться за Octree, хотя с квадродеревом (QuadTree) уже разобрался пару недель назад и выложил видео и сорсы, но писать про них буду чуть позже :).

А сегодня, опишу что же эта за процедурная вода такая. ВО первых слово процедурная - уже означается что это вода полностью программная, а не замоделенная или анимированная, то есть все подчиняется некоему программному алгоритму. По производительности такая вода, как оказалось, весьма ресурсоемкая, но весьма функциональна.

В своих реализациях я стараюсь минимизировать насколько это возможно постороннуюю работу и использовать исключительно код. Если взять в качестве примера несколько популярных песочниц, размер исходных файлов игры находится в пределах 40-80 мб, но при этом своими возможностями они превосходят многие игры на нескольких ДВД дисках. Помню в 90-х игры уже выходили размером с CD, а это около 600 мб.

Самая маленькая 3Д игрушка под названием .kkrieger (ссылка на википедию, возможно там есть ссылка на игру), в которую я играл весила всего 96 кб, и работала на чистых алгоритмах. Это полноценный 3Д шутер с несколькими видами оружия и монстров. Помню как запустив ее, я офигел, потому что гиг оперативки был отожран практически за пару секунд, то есть окружение строилось на ходу, а графика на (2004 год) была весьма впечатляющей. Это то, к чему стоит стремиться :).

Итак вернемся к воде.
Collapse )

Учусь программировать. Алгоритм авторазметки или подсчет отдельных объектов на поле.

ч.5 Учусь программировать. Marching Cubes

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

Написав свой первый поиск пути, я так и не решил на тот момент толком проблему, что же делать если зона поиска недоступна. Точнее решил ее частично, ограничив максимальное количество перебираемых точек, тем самым ограничив дальность такого поиска. К слову, похожая система была организована в игре Divinity original sin, потому что путь от одного конца карты в другой персонажи отказывались прокладывать напрочь, хотя алгоритм насколько я понял был похожий с моим, не знаю была ли у них реализовано раграничение игрового поля на зоны. В игре тоже были закрытые участки - например запертые дома или временно недоступные зоны :).

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

В понимании мне также очень хорошо помогла вот эта статья на Хабре Подсчет объектов на бинарном изображении.

Collapse )

Учусь программировать. Marching Cubes

ч.5 Учусь программировать. Первый 2Д редактор карты.

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

В ч.3 Я уже описывал как пытался постичь алгоритм Марширующих кубов, но не хватило терпения и знаний. Алгоритм интересен тем, что позволяет на регулярной сетке строить сложные 3Д объекты, а если его довести до ума, то можно строить 3Д модели практически любых размеров. Для меня это второй шаг на пути создания полностью изменяемого мира.
Все сложное начинается с чего то более простого, поэтому для начала я решил попробовать изучить упрощенный вид алгоритма Marching Squares - это 2-х мерный вариант марширующих кубов. Снова погрузившись в изучение статей, я с удивлением обнаружил, что 2Д вариант у меня есть практически в готовом виде - это был тот самый тайлинг земли из 2Д редактора (из предыдущей темы). Те же 16 разных видов кусочков карты из которых автоматически подбирается нужный пазл, лишь с небольшими изменениями. Сказать что я был рад - не то слово. Как оказалось позже я все же немного ошибся, но об этом дальше.

Итак, проглядев свой код, а также почитав описания теперь уже для 3Д варианта я решил перенести свой 2Д тайлинг земли на 3-х мерную сетку. Я также отписывался на форуме и мне подсказали примерно следующее >>"Я разобравшись с тайлингом 2Д, перенес его с 3Д и только потом узнал, что это уже сделано 20 лет назад и называется marching cube..."
Дело казалось нехитрым, тем более, что я уже игрался с кубическими чанками и как построить сложные объекты из более мелких не было трудностью.

Collapse )

Учусь программировать. Первый 2Д редактор карты.

ч.4 Учусь программировать. Настоящий поиск пути. А*.
Чтож, первый поиск пути готов, хоть и кривоватый, но вполне работоспособный и его даже можно зайдествовать. Нужно браться за что то более сложное. Поскольку модельщик я тот еще, на время я решил отказаться от 3Д и следующей целью стал редактор 2Д карты.

В свое время довольно много времени я посвятил Героям 3. Я прошел все кампании, клепал свои карты и миссии. Тогда еще не было мега 3Д игр с суперграфикой, и герои казались фантастически красивой игрой.

И я до сих пор считаю редактор карт Heroes III эталоном редактора для двухмерных карт. Раньше я не задумывался сколько труда вложено, чтобы создание новой карты было настолько простым и даже увлекательным занятием - это было как самом собой разумеющееся. А теперь я решил подойти к этому с точки зрения разработчика.
Полазив по всемирной сети, я также провел некоторые сравнения, какие есть еще интересные реализации 2Д редакторов. Просмотрев кучу видео демонстраций в очередной раз убедился насколько эталонный редактор продуманный и в тоже время простой и удобный. В некоторых других редакторах например отсутствовал автотайлинг земли и для того чтобы создать красивую территорию приходилось нажимать кучу лишних кнопок, выбирая нужный кусочек земли и собирать территоию буквально как пазл. В других, к примеру для создания дерева или домика требовалось собирать его из нескольких кусочков, что так же требовало дополнительных усилий.

Поэтому решительно откинув их я стал пристально всматриваться в мой эталонный редактор :).
Collapse )

Учусь программировать. Настоящий поиск пути. А*.

ч.3 Учусь программировать. Знакомлюсь в теорией поиска пути.

Закончив, интсрумент по созданию путевых точек, у меня стали спрашивать, а можно ли этим инструментом создавать тоже самое в процессе игры ? Я не стал добавлять поддержку создания путей в рантайме, потому что в интернете полно описаний и готовых решений реализации различного рода поисков пути и в самом игровом движке даже в Free Версии есть встроенный поиск пути. Зачем делать одно и тоже думал я :)...

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

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

В интернете полно различного рода реализаций поиска пути, которые хороши для простых задач, но требуют доработки и заточки для более сложных. Так начались поиски наиболее универсального и достаточно быстрого алгоритма, снова чтение описаний, изучение преимуществ и недостатков, на которые я потратил несколько дней, а также же поиск более менее сносной документации. И снова на русском языке что либо найти оказалось весьма проблематично, поэтому приходилось вновь применять навыки переводчика :)). Тогда для меня это казалось неимоверно сложным, сейчас я уже вижу, что 80-90% текста описаний алгоритмов - это ненужная вода, и порой даже попытки запутать неискушенного в этом деле.

Collapse )

Учусь программировать. Знакомлюсь в теорией поиска пути.

ч.2 Учусь программировать. Кубочанки
Наигравшись с кубочанками и освоив первый, пусть и простенький алгоритм, мне захотелось чего то большего. Границы моего незнания моментально расширились. Ведь чем больше знаешь - тем больше не знаешь )). Кубики это конечно прикольно, но разные формы намного круче. Мечтой стало создать нечто похожее из видео предыдущего поста. Перелопатив кучу форумов, понял, что нужно двигаться в сторону алгоритма "марширующих кубов". Но эта тема оказалась практически закрытой. В интернете масса статей на русском и английском, но как оказалось большая часть текста - это вода. Четкого описания нет практически нигде (в чем я убедился через несколько месяцев). Как ни пытался я разобраться в этой теме по найденным источникам толку не было никакого. Мой разум отказывался воспринимать информацию. Я заваливал форумы вопросами, но либо это тема оказалась либо закрытой, либо делиться наработками и наводками никто не желал. В основном были отписки на оффициальные источники и мануалы, в коотрых неискушенному программным кодом и алгоритмами мозгам легко заблудиться. Проколупавшись несколько дней в бесполезных попытках, я отложил это до лучших времен, ведь есть еще масса неизученных и интересных вещей.

Collapse )

Учусь программировать. Кубочанки

ч. первая Чем я занимался пол года. Учусь программировать.
Пока я занимался конструктором, все задавался вопросом, а почему же никто не делал этого до меня, почему игры настолько примитивные и мир в них настолько статичный ? Я был наивен, поэтому с большим энтузиазмом вкладывал силы в свое, как мне казалось "Детище" :))). Но как и следовало ожидать, появилась куча проблем и ограничений, о которых я ничего не знал. Во первых, это физика и коллайдеры. Так вот чем больше объектов-деталек с коллайдерами появлялось на игровом поле, тем тяжелее все это обрабатывать машине.

Сразу закрались некие сомнения, а правильно я все делаю, почему то вспомнился знаменитый "Майнкрафт" со своим бесконечным кубическим миром, в который мне кстати так и не довелось поиграть. Я начал заваливать форумы вопросами, а как же это все работает, в нем спокойно обрабатываются миллионы кубиков, а у меня уже после 10 000-20 000 деталек производительность сводилась на нет. Тогда я узнал, что такое Mesh и что, так называемые кубики в Майнкрафте - вовсе не кубики, а огромные кучи кубов объединенные в большие объекты называемые Чанками.
На самом деле такие вопросы на форумах появляются чуть ли не каждую неделю, я был не исключением.

Collapse )

Чем я занимался пол года. Учусь программировать.

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

Сделать свою игрушку пробовал любой программист. Я не исключение, и начал я свое изучение именно с этого направления, потмоу что это наиболее близкая для меня тема. Свою игрушку я мечтаю сделать уже лет 15, как у меня появился первый компьютер, но до последнего года не мог повернуть мозги в нужном направлении, а точнее не знал с какой стороны к этому подойти. Начинал с банального вебпрограммирования и простеньких сайтиков. поскольку не стоит у меня на вебстранички, дело это я забросил. Затем мне повезло натолкнуться на один любопытный проект, где 20 летний паренек рассказывал, что начал делать свою игрушку, в принципе не умея ничего, это и стало моим пинком, чем я хуже? (К слову чел свою игрушку уже года пилит и все никак закончить не может :)).

Collapse )