Тёмная тема
WISHMASTER35
Т.е. каждый чанк хранит массив своих блоков как массив ссылок на префабы блоков?
alexzzzz, да, каждый чанк хранит массив ссылок на префабы блоков.
WISHMASTER35
Можно не хранить в массиве четырёх- или восьмибайтные ссылки, а хранить просто порядковый номер типа блока в виде одного байта, или одного enum'а, и по этому номеру выбирать соответствующий префаб в списке префабов.
icelex
> ах да ещё немного лагает когда быстро колупаеш блоки тож до 30-35+,
Можно в качества пищи для размышления узнать, какой у тебя процессор, и заодно посмотреть скриншот счётчиков производительности, которые по клавише 'I'?
> пока не колупнул ещё было видно насквозь изза отсучтвия рендер меша
> + я колуал ,колупал и 1 стена(чанк хз как там у тебя) просто забыла
> обнвится,(точней гдет потерялся апдейт, скорей всего бага синхроницазыи
> мультитрида)
Там был один глюк, из-за которого иногда у чанка ошибочно обнулялась вся геометрия. Я в ответственном месте уже прилично переписал код, рецидивов вроде больше не было.
=A=L=X=
ЛОД решит все проблеммы, вдали объединять кубики по 8 штук по рекурсии
У меня подобным образом целая планета укладывается в 30-тыс треугольников
http://www.gamedev.ru/projects/forum/?id=139185
icelex
> я хз чем оно тебе поможет, ибо лаг (наверно) в обращении к жесткому диску :)
Я хотел посмотреть, сколько времени занимают разные стадии создания чанков на твоём процессоре.
Вероятно, тормозит жёсткий диск, но ещё есть вероятность, что добавляются лаги на создание/обновление чанков.
Если очистить папку saves или к бинарнику в качестве параметра командной строки добавить пятизначный seed и потом двигаться в одном направлении, то читать с диска станет нечего и можно будет понять, лаги были из-за чтения или из-за обновления чанков. Большинство стадий расчётов идёт в фоне, но стадия "gameobject" проходит в главном потоке. На твоём скриншоте видно, что среднее время её выполнения 8мс. Иногда за один кард обновляется несколько чанков, суммарная задержка получается ещё больше. У меня есть ограничение по суммарному времени выполнения заданий в главном потоке, но оно сделано неудачно, могут возникать лаги по 15-20мс. Сейчас я уже запретил выполнение в главном потоке нескольких заданий подряд и дальше хочу разбивать большие задания на несколько мелких (отдельно видимый меш, отдельно физический коллайдер, отдельно растительность с декалями, отдельно воду) и размазывать их по нескольким кадрам.
Вчера сделал покадровый график fps/длительности кадров, как в Майнкрафте по F3, на нём у меня видны единичные резкие всплески в моменты обновления чанков, хотя раньше на глаз этого не замечал.
Aslan
Я пробовал на ранних этапах объединять группы дальних кубиков в большие. Выглядело, честно говоря, не очень хорошо, и сильно усложнялся код.
alexzzzz, а координаты в атласе для блока у тебя тоже в твоей структуре хранятся? Там их довольно много т.к. на каждый фейс надо.
Я тоже хотел вынести генерацию в другой поток, но столкнулся с проблемой, что из другого потока нельзя обратиться к объекту наследованному от ScriptableObject. Даже к своим полям нельзя)
Буду теперь класс блока перегонять в структуру) Вот только не пойму, если ссылочный тип можно было сравнить с null, то как проверить, что структура пуста?
WISHMASTER35
> а координаты в атласе для блока у тебя тоже в твоей структуре хранятся? Там их
> довольно много т.к. на каждый фейс надо.
Я не использую атласы, я меня текстуры высокого разрешения, растянутые на 4 блока в высоту и ширину. UV рассчитываются вместе с геометрией. Для чанков 32х32х32 и видимого мира размером 12х12 чанков обычно выходит около 300 drawcalls ― вполне терпимо. С подземными пещерами, конечно, несколько больше, но я не фанат пещер.
> Буду теперь класс блока перегонять в структуру) Вот только не пойму, если
> ссылочный тип можно было сравнить с null, то как проверить, что структура
> пуста?
Пустой блок всё равно память занимает и будет занимать, так что оформи его как отдельный тип блока:
― Подлагивания во время движения должны быть меньше. По клавише F3 можно посмотреть график производительности.
― Можно рубить деревья. В отладочном меню (клавиша ~) выбрать Plant tree или Plant many trees, а в инвентаре (Tab) выбрать топор.
С деревьями знаю два глюка:
1) После разрубания иногда некоторые листья поворачиваются вокруг ствола в другом направлении.
2) Физическая оболочка стоящего дерева соответствует его видимой геометрии, а срубленного дерева нет ― у него она выпуклая. Поэтому если срубить ствол с большими ветками на нём, то потом эти ветки хрен отрубишь.
alexzzzz, если у тебя на каждый блок может свой материал создаваться, то ты используешь несколько субмешей в меше?
Это получается, что ты сначала считаешь количество используемых материалов в чанке, потом создаешь такое кол-во субмешей, а потом генерируешь эти субмешы? Получается, что видемость блоков будет по два раза проверяться.
Анимация травы в вершинном шейдере сделана?
WISHMASTER35
> ты используешь несколько субмешей в меше?
Да.
> ты сначала считаешь количество используемых материалов в чанке, потом создаешь
> такое кол-во субмешей, а потом генерируешь эти субмешы?
1. Создаю массив сабмешей по максимально возможному количеству материалов.
2. Прохожу по-очереди все блоки и добавляю видимые грани к нужному сабмешу в массиве в соответствии с индексом материала этого блока.
3. Сабмеши в массиве, которые остались пустыми, убираю, а из оставшихся создаю финальный объект Mesh.
> Анимация травы в вершинном шейдере сделана?
Да.
Помимо этого, сами блоки можно не хранить, после наполнения буферов для отрисовки. Будет гемор с физикой игрока, конечно. Можно хранить блоки только для текущего чанка и чанка с которым происходит взаимодействие. Возможно, можно начитывать информацию о вертексах из буфера и на основе этого строить физику игрока.
Почему бы не сделать нормальную физику, чтобы висящие в воздухе блоки наконец попадали? Или бросил что-нибудь с горы, оно покатилось, упало, ещё покатилось и остановилось. Я знаю, почему: потому что в Майнкрафте нечего бросить с горы, там все предметы ― маленькие квадратные иконки, они не могут кататься. Поэтому у нас физики тоже не будет.
С физикой беда, т.к. для её реализации нужно перестраивать вертексный буфер, но если использовать чанки 32х32х32, это может стать подъёмной задачей. Вообще, мысль очень здравая. Единственная проблема - нахождение пути отрисовки в этом пространстве, но перспективы очень неплохие.
Кстати, а как бы вы решили проблему нахождения пути для отрисовки видимого игроком пространства в этом нагромождении чанков?
fornetjob
> Если для каждого чанка изначально хранить блоки вместе со слоем блоков
> соприкасающихся чанков, то большое количество костылей можно будет отбросить.
На этапе генерирования меша это поможет, а на этапе просчёта освещения нет, там свои особенные заморочки:
Если, к примеру, чанки 32х32х32, а интенсивность источника света 15 единиц, то свет от источника может
а) проникать в соседний чанк до самой его середины;
б) проникать на пару блоков в соседний чанк, а потом немного в другом месте возвращаться обратно в первый;
в) одним «лучом» пронизывать углы сразу нескольких чанков.
Для расчёта света момент перехода из чанка в чанк по-любому придётся специально отлавливать.
> Кстати, а как бы вы решили проблему нахождения пути для отрисовки видимого
> игроком пространства в этом нагромождении чанков?
Можно просто рисовать все чанки, что попадают во frustum, их не так уж много.
Пля alexzzz твой проект мега-опупенный, я серьёзно. Такое даже стыдно будет назвать пародией или клоном, скорее v2.0 minecraft
Правда память кушает... Оч много.
Jarro
> Правда память кушает... Оч много.
В два гигабайта бы уложиться, чтоб на x86 не было проблем, а в остальном пофиг.
Тема в архиве.