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

Я не совсем понял, что ты имел в виду. Хотел вдумчиво почитать вечером, но ты уже удалил.

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

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

Во чего нашёл:
http://www.decarpentier.nl/scape-procedural-basics
http://www.decarpentier.nl/scape-procedural-extensions

Статьи в копилку про процедурную генерацию ландшафта на основе шума Перлина. Пока не прочитал, но картинки выглядят неплохо, а примеры кода просятся на попробовать. «IQ Noise» в первый раз вижу.

alexzzzz

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

Выглядит очень круто.

у меня такая идея про освещение... ведь можно его считать итерациями.. главное чтобы во времени сходилось к нужному результату..
самый тупой вариант F(i+1)[x,y,z] = ((Fi[x-1,y,z]+Fi[x+1,y,z]+Fi[x,y-1,z]+Fi[x,y+1,z]+F[x,y,z-1]+Fi[x,y,z+1])/6.5 + G[x,y,z])*A[x,y,z].
F- освещенность
G - источник света
A - прозрачность блока

и так каждый кадр для ближайших чанков просчитывать каждый пиксель. на основе предыдущего результата.
будет считать вкруг персонажа по 3x3x3 чанка, если чанк 32ч32ч32 то это все влезет в текстуру 1кx1к. а это для GPU копейки.
потом можно посчитать лод чанков например уменьшить в 4 раза. для большего объема...

особенность в том что данный метод не зависит от количество источников света.

susageP
Надо попробовать, но ведь эти расчеты нужно делать для каждого блока и по несколько раз?

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

alexzzzz
> Ещё смущает то, что предполагается проходить по всем блокам чанка, даже по тем,
> куда свет в принципе не мог бы попасть, типа глубоких пещер и длинных
> коридоров. И надо по-особому обрабатывать свет в блоках воздуха, граничащих с
> твёрдыми блоками, иначе свет прямо над поверхностью земли окажется темнее, чем
> на один блок выше, и сама земля станет темнее, чем должна быть.
верно...
но это идея...
современные карточки спокойно сделают в сек 1к проходов по текстуре 1кx1к...  это 3ч3ч3 чанка вполне достаточно.. + можно лод прикрутить для дальних.

суть в том что не зависит от колво источников, а это значит что хоть каждый квад может светиться.

На счёт большого количества источников смотри:

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

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

3. При удалении одного из источников света удалить и полностью пересчитать весь свет было бы проще, но так делать необязательно. Можно очистить только свет от удалённого источника и получившееся чёрное пятно осветить на основе данных об оставшемся освещении. Я такой алгоритм придумал, проверил ― работает: описание.

alexzzzz
> При удалении одного из источников света удалить и полностью пересчитать весь
> свет было бы проще, но так делать необязательно. Можно очистить только свет от
> удалённого источника и получившееся чёрное пятно осветить на основе данных об
> оставшемся освещении. Я такой алгоритм придумал, проверил ― работает:
судя по рисунк отсутствует сложение освещенности от двух источников.
F(i+1)[x,y,z] = Max( Max(Fi[x-1,y,z],Fi[x+1,y,z],Fi[x,y-1,z],Fi[x,y+1,z],F[x,y,z-1],Fi[x,y,z+1]) -1, G[x,y,z])*A[x,y,z]

+ O(..) - не изменый при любом колво источнике света..    хоть делай армию 10к юнитов в светящихся доспехах. главное чтобы они двигались хотя бы в 2 раза медленней скорости 'света'.
простота расчетов. главное легко ложиться на GPU.

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

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

susageP
> судя по рисунку отсутствует сложение освещенности от двух источников.
Складывать особого смысла нет, потому что
а) и так смотрится нормально;
б) можно запихнуть свет в 4 бита на блок или 4 бита на канал, если свет многоканальный;
в) так как естественным образом получается ограничение по максимальной яркости, то добавление новых источников света к куче существующих не требует такого же количества расчётов, как для нескольких первых источников.

Правда, если свет складывать, то удалять будет проще: просто вычесть свет удаляемого источника из общей суммы и всё.

Про расчёты на GPU я ничего не знаю, не в курсе подводных камней.

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

alexzzzz
А чем обусловлен размер чанка 32x32x32? почему дерево не используется? хуже или просто сложней в реализации?

Дерево чего?

alexzzzz
> Дерево чего?
любое, хотя бы SVO

я тут просто подумал натянуть 3D мир Minecraft на сферу.