Войти
ПрограммированиеФорумГрафика

Рендер как в Minecraft-е - кто нибудь знает основные "секреты"? (6 стр)

Страницы: 15 6 7 8101 Следующая »
#75
1:36, 13 июня 2012
На этапе генерирования меша это поможет, а на этапе просчёта освещения нет, там свои особенные заморочки:

Если, к примеру, чанки 32х32х32, а интенсивность источника света 15 единиц, то свет от источника может
а) проникать в соседний чанк до самой его середины;
б) проникать на пару блоков в соседний чанк, а потом немного в другом месте возвращаться обратно в первый;
в) одним «лучом» пронизывать углы сразу нескольких чанков.

Для расчёта света момент перехода из чанка в чанк по-любому придётся специально отлавливать.


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

У меня сейчас перебором для быстрой проверки 25600 чанков на попадание во фруструм в релизе уходит 6 миллисекунд. Используя 32 по игреку, вместо 128, мы увеличиваем количество чанков в четыре раза. Если использовать перебор, мы только на проверку будем тратить 24 миллисекунды, 41 фпс, если отрисовка нам ничего не стоит, т.е. в пределе.
Поэтому, чтобы использовать 32х32х32 чанки, необходимо разработать алгоритм нахождения пути для отрисовки. Чтобы не перебирать чанки, которые полностью скрываются другими, в которых отсутствуют кубики и т.д.
Сейчас при размере видимого лашдшафта 160х160 чанков программа занимает в памяти 140 мб. Убрав кубики из чанков, мы освободили место под индексы для навигации между ними, в том числе, для снижения количества чанков к перебору для отрисовки.


Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры


#76
1:54, 13 июня 2012

fornetjob
> У меня сейчас перебором для быстрой проверки 25600 чанков на попадание во
> фруструм в релизе уходит 6 миллисекунд.
У тебя дикие расстояния.  Если карта 160х160, а чанки 16х16, то наблюдатель видит на 1,3км вокруг. На таком расстоянии у 9-этажного дома угловой размер примерно 0,13°. Если fov 60°, это 1/460 часть экрана, т.е. всего несколько пикселей. Есть ли в этом смысл?

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

#77
2:09, 13 июня 2012
Если ландшафт ― карта высот, то да, а если от реально трёхмерный, со всякими пещерами, гротами и нависающими скалами?

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

#78
2:20, 13 июня 2012

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

#79
2:22, 13 июня 2012

fornetjob
> Пещеры и гроты тёмные, в них нужно рассчитывать только динамическое освещение.
Они могут быть полностью тёмными, а могут не быть:

+ Показать
#80
2:30, 13 июня 2012

fornetjob
> Кстати, подумалось, а что если завести несколько типов блоков для света? Вместо
> пустого блока можно добавлять блок с типом говорящем о направлении падения
> света...
Если хранить свет в том же массиве, что и блоки, можно забыть про прозрачные и полупрозрачные блоки. С одной стороны, жалко конечно тратить память, а с другой ― зачем она вообще нужна, если её не тратить?

#81
2:31, 13 июня 2012
Они могут быть полностью тёмными, а могут не быть

А что, если использовать байт под тип блока следующим образом:
Последний бит в 0 - это тип блока, 1 - градус падения света.
Таким образом, мы можем представить 360 возможных градусов в 128 делениях с точностью по три градуса. Можно расчитать любое освещение.

Если хранить свет в том же массиве, что и блоки, можно забыть про прозрачные и полупрозрачные блоки. С одной стороны, жалко конечно тратить память, а с другой ― зачем она вообще нужна, если её не тратить?

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

#82
3:08, 13 июня 2012

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

#83
4:02, 13 июня 2012

При расчёте освещения использовать "перетекание" света с одного кубика на другие, с неким изменением градуса и уменьшением веса. Если предположить, что естественный свет снизу падать не может, тогда нам необходимо 180 градусов падения "вниз" и 360 градусов направления, которые можно уместить в один-два байта.
Изображение
В случае бесконечного мира и чанков 32х32х32, необходимо выделить память под 27 чанков, последовательно "передвигаясь" в них по видимой карте рассчитать освещение, вбо и, возможно, создать индексы для быстрой отрисовки.

Возможно, стоит сделать чанки чанков. Тогда индексы для поиска чанков делать не нужно.

alexzzzz, а в твоей демке ты для интересного эффекта с гранями кубов используешь небольшой рандом для всей колонки чунка?

#84
16:14, 13 июня 2012

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

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

#85
17:10, 13 июня 2012

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

#86
17:16, 13 июня 2012

alexzzzz
> alexzzzz
глядя на это я придумал мега шедевр...
Изображение

онлайн RPG Dungeon keeper в мире Minecraft-е.

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

#87
17:26, 13 июня 2012

Из леса набигают эльфы...

#88
17:41, 13 июня 2012

fornetjob
> alexzzzz, а в твоей демке ты для интересного эффекта с гранями кубов
> используешь небольшой рандом для всей колонки чунка?
Пробовал рандом ― жуткое зрелище. У меня смещение вершин достигается комбинацией двух эффектов:

1. Каждый непустой блок вокруг вершины слегка тянет эту вершину к себе. Для каждой вершины просматриваю все восемь смежных блоков и считаю итоговое смещение.

2. Чтобы убрать длинные прямые линии добавляю к позиции каждой вершины немного шума Перлина. Есть функция трёхмерного шума: float Noise(x, y, z), на вход подаю мировые координаты вершины, на выходе получаю смещение вдоль оси координат. Т.к. осей координат три, то для каждой оси использую свой шум со своим seed'ом.

#89
18:03, 13 июня 2012

fornetjob
> Из возможных вариантов вижу, что можно не хранить освещённость в вертексах, а
> хранить их порядковый номер. При расчёте освещённости данные заносить в
> текстуру, которую использовать для получения освещённости вертекса по его
> порядковому номеру.
Прикольно.

Страницы: 15 6 7 8101 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.