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

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

Страницы: 14 5 6 7101 Следующая »
#60
0:56, 31 мая 2012

WISHMASTER35
Т.е. каждый чанк хранит массив своих блоков как массив ссылок на префабы блоков?

#61
1:13, 31 мая 2012

alexzzzz, да, каждый чанк хранит массив ссылок на префабы блоков.

#62
1:26, 31 мая 2012

WISHMASTER35
Можно не хранить в массиве четырёх- или восьмибайтные ссылки, а хранить просто порядковый номер типа блока в виде одного байта, или одного enum'а, и по этому номеру выбирать соответствующий префаб в списке префабов.

#62
3:41, 31 мая 2012

icelex
> ах да ещё немного лагает когда быстро колупаеш блоки тож до 30-35+,
Можно в качества пищи для размышления узнать, какой у тебя процессор, и заодно посмотреть скриншот счётчиков производительности, которые по клавише 'I'?

> пока не колупнул ещё было видно насквозь изза отсучтвия рендер меша
> + я колуал ,колупал и 1 стена(чанк хз как там у тебя) просто забыла
> обнвится,(точней гдет потерялся апдейт, скорей всего бага синхроницазыи
> мультитрида)

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

#63
12:44, 31 мая 2012

хранить просто порядковый номер типа блока в виде одного байта, или одного enum'а, и по этому номеру выбирать соответствующий префаб в списке префабов

В том то и дело, что я не составляю список всех блоков.
Сейчас у меня в скрипте который строит карту несколько ссылок на блоки. В скрипте, который добавляет блок при нажатии мыши тоже есть ссылки на блоки. И как со всех этих скриптов собрать все блоки в список я хз(
Хотя заменить 8-байтную ссылку  на один байт-номер в списке было бы очень хорошо.

#64
13:58, 31 мая 2012

=A=L=X=
ЛОД решит все проблеммы, вдали объединять кубики по 8 штук по рекурсии
У меня подобным образом целая планета укладывается в 30-тыс треугольников
http://www.gamedev.ru/projects/forum/?id=139185

#65
15:31, 1 июня 2012

icelex
> я хз чем оно тебе поможет, ибо лаг (наверно) в обращении к жесткому диску :)
Я хотел посмотреть, сколько времени занимают разные стадии создания чанков на твоём процессоре.

Вероятно, тормозит жёсткий диск, но ещё есть вероятность, что добавляются лаги на создание/обновление чанков.

Если очистить папку saves или к бинарнику в качестве параметра командной строки добавить пятизначный seed и потом двигаться в одном направлении, то читать с диска станет нечего и можно будет понять, лаги были из-за чтения или из-за обновления чанков. Большинство стадий расчётов идёт в фоне, но стадия "gameobject" проходит в главном потоке. На твоём скриншоте видно, что среднее время её выполнения 8мс. Иногда за один кард обновляется несколько чанков, суммарная задержка получается ещё больше. У меня есть ограничение по суммарному времени выполнения заданий в главном потоке, но оно сделано неудачно, могут возникать лаги по 15-20мс. Сейчас я уже запретил выполнение в главном потоке нескольких заданий подряд и дальше хочу разбивать большие задания на несколько мелких (отдельно видимый меш, отдельно физический коллайдер, отдельно растительность с декалями, отдельно воду) и размазывать их по нескольким кадрам.

Вчера сделал покадровый график fps/длительности кадров, как в Майнкрафте по F3, на нём у меня видны единичные резкие всплески в моменты обновления чанков, хотя раньше на глаз этого не замечал.

Aslan
Я пробовал на ранних этапах объединять группы дальних кубиков в большие. Выглядело, честно говоря, не очень хорошо, и сильно усложнялся код.

#66
1:02, 6 июня 2012

alexzzzz, а координаты в атласе для блока у тебя тоже в твоей структуре хранятся? Там их довольно много т.к. на каждый фейс надо.
Я тоже хотел вынести генерацию в другой поток, но столкнулся с проблемой, что из другого потока нельзя обратиться к объекту наследованному от ScriptableObject. Даже к своим полям нельзя)
Буду теперь класс блока перегонять в структуру) Вот только не пойму, если ссылочный тип можно было сравнить с null, то как проверить, что структура пуста?

#67
1:24, 6 июня 2012

WISHMASTER35
> а координаты в атласе для блока у тебя тоже в твоей структуре хранятся? Там их
> довольно много т.к. на каждый фейс надо.

Я не использую атласы, я меня текстуры высокого разрешения, растянутые на 4 блока в высоту и ширину. UV рассчитываются вместе с геометрией. Для чанков 32х32х32 и видимого мира размером 12х12 чанков обычно выходит около 300 drawcalls ― вполне терпимо. С подземными пещерами, конечно, несколько больше, но я не фанат пещер.

> Буду теперь класс блока перегонять в структуру) Вот только не пойму, если
> ссылочный тип можно было сравнить с null, то как проверить, что структура
> пуста?

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

+ Показать
#68
1:27, 11 июня 2012

Выложил новый бинарник.

― Подлагивания во время движения должны быть меньше. По клавише F3 можно посмотреть график производительности.
― Можно рубить деревья. В отладочном меню (клавиша ~) выбрать Plant tree или Plant many trees, а в инвентаре (Tab) выбрать топор.

С деревьями знаю два глюка:
1) После разрубания иногда некоторые листья поворачиваются вокруг ствола в другом направлении.
2) Физическая оболочка стоящего дерева соответствует его видимой геометрии, а срубленного дерева нет ― у него она выпуклая. Поэтому если срубить ствол с большими ветками на нём, то потом эти ветки хрен отрубишь.

#69
12:32, 11 июня 2012

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

#70
12:54, 11 июня 2012

WISHMASTER35
> ты используешь несколько субмешей в меше?
Да.


> ты сначала считаешь количество используемых материалов в чанке, потом создаешь
> такое кол-во субмешей, а потом генерируешь эти субмешы?
1. Создаю массив сабмешей по максимально возможному количеству материалов.
2. Прохожу по-очереди все блоки и добавляю видимые грани к нужному сабмешу в массиве в соответствии с индексом материала этого блока.
3. Сабмеши в массиве, которые остались пустыми, убираю, а из оставшихся создаю финальный объект Mesh.


> Анимация травы в вершинном шейдере сделана?
Да.

#71
21:55, 12 июня 2012

Если для хранения блоков использовать отдельный массив блоков для каждого чанка, то при расчёте освещения будут проблемы с обработкой пограничных блоков. Будет много дополнительных проверок на выход за пределы чанка. И при постройке геометрии эти проверки крайних блоков тоже будут нужны. Майнкрафт и большинство клонов хранят блоки именно так, по отдельному массиву в каждом чанке.
...
Ещё один момент, который лучше осознать как можно раньше: считать освещённость можно только для тех чанков, которые уже заполнены блоками, и все соседи которых (в том числе по-диагонали) тоже обязательно уже заполнены блоками. Иначе расчёт выйдет неправильный. И создавать геометрию можно только для тех чанков, для которых уже просчитано освещение, и для соседей которых тоже обязательно уже просчитано освещение. Иначе граничные блоки чанка могут оказаться неправильно освещены.

Если для каждого чанка изначально хранить блоки вместе со слоем блоков соприкасающихся чанков, то большое количество костылей можно будет отбросить.
Пример хранения | Рендер как в Minecraft-е - кто нибудь знает основные "секреты"?

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

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

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

Кстати, а как бы вы решили проблему нахождения пути для отрисовки видимого игроком пространства в этом нагромождении чанков?

#72
23:40, 12 июня 2012

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

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

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

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

#73
0:01, 13 июня 2012

Пля alexzzz твой проект мега-опупенный, я серьёзно. Такое даже стыдно будет назвать пародией или клоном, скорее v2.0 minecraft
Правда память кушает... Оч много.

#74
0:20, 13 июня 2012

Jarro
> Правда память кушает... Оч много.
В два гигабайта бы уложиться, чтоб на x86 не было проблем, а в остальном пофиг.

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

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