Воксельные изыскания

[Paul Siberdt]

Слежу за проектом. Удачи и неувядающего интузязизьма.

[bwolf88]

Слежу за проектом. Удачи и неувядающего интузязизьма.

Благодарствую, стараюсь как могу -грызку гранит .

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

Размеры 800х400х800, потребляемая память 0.95-1,1 Гб.
ФПС проседает только когда записываю, причем на обоих видеокартах, почему не пойму, проц загружен на 20% всего.
Встроенная без записи 50-60 ФПС, Nvidia - 80-150.

[bwolf88]

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

[gnoblin]

очень круто!

[bwolf88]

Начал переписывать все на Юнити, заодно еще немного оптимизируя иииии
- теперь мир грузится еще в два раза быстрее, при той же напруге на процик;
- фпс в 2 раза больше;

Хотя на счет фпс не знаю, может потому что я юзаю простой трипланарник с большой текстуркой вместо тайловой карты. Скоро проверю и на тайлах.
Каждый раз что то оптимизируя я думаю - все это предел, а нифига, я знаю, как можно еще увеличить скорость, хотя даже сейчас на 20 м3 чанк приходится всего 0.2 млс в среднем. Правда это без расчета биомов и калькуляции данных вокселя на основе этих данных.

И нужно что то с изначально сожранной памятью делать. 3,2 Гб на 800х400х800 м (полный вес всех вокселей), которые через пару минут движения опускаются до 1,1 гб (реально используемой). А непроверять неиспользуемые чанки нельзя.

[Woolf]

3,2 Гб на 800х400х800 м

Упаковывать "полные" чанки в пару байт можно, например. Да и не полные тоже можно паковать. Естественно, работать с чанками, как с массивом при таком раскладе уже не выйдет, тут нужно динамическое выделение памяти.

[MF_Andreich]

Кстати да, видел идею одну, где воксели хранятся не сплошным полем, а листом с адресами, можно наверное сделать дикшнари, для более удобного поиска по адресу. Там идея в том, что у воксели хранились только граничные, то есть те у кого по одной из сторон либо соседа нет, либо сосед другой. Тут правда нужно попарится при просчете копания, в случае если натыкаемся на границу, но думаю ты это решишь =)

[bwolf88]

3,2 Гб на 800х400х800 м

Упаковывать "полные" чанки в пару байт можно, например. Да и не полные тоже можно паковать. Естественно, работать с чанками, как с массивом при таком раскладе уже не выйдет, тут нужно динамическое выделение памяти.

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

можно наверное сделать дикшнари,

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

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

Это очень сложно выглядит, я предпочитаю делать все понятно и прямо, без танцев . Хотя мой алгоримт тоже немного с танцами прочитывает форму, но в будущем я его переделаю под прямое взаимодействие, будет реалтайм 3Д редактор. Я знаю как сделать в общих чертах, но чтобы реализовать программно нужно опять недели на две в транс уходить .

[bwolf88]

Вообще, ЛОДы все эти проблемы решают, я просчитал, что даже если использовать 7 вложений, то можно в 16к чанков начиная с 25 см кубиков и увеличивая их размер на определенной дистанции до 16 метровых на последнем уровне отобразить 4км в каждую сторону при том же потреблении памяти.

Но появится другие неприятные особенности:

1. Допустим игрок смотрит в бинокль и объекты на которые он смотрит нужно резко перестроить до максимальной детализации. А учитывая расстояние - это будет довольно нагрузно по памяти. Причем скорость перемещения экрана с биноклем значительно выше, нежели скорость движения игрока даже на транспортном средстве. То есть перестраивать нужно мегабыстро.
2. Как взаимодйествовать объектам на таком расстоянии ? Допустим снаряд вылетел и попал в цель на расстоянии пол километра - но там ячейки другого размера, а изменения нужно делать с учтом самого маленького кубика. Значит для снаряда нужно менять детализацию в этой области. А если таких снарядов 100 ? Система нагнется.

Так что с ЛОД системой пользователь может взаимодействовать с миром только на определенной дистанции. Взять тот же Воксельфарм или Блокскейп или Ландмарк (в последних двух я периодически тестирую возможности). В Блокскейп диснтация ~16м и пока мир вокруг игрока не прогрузится до минимальных кубиков ничего поставить/удалить нельзя + периодические глюки. В Ландмарке расстояние около 60 м, но и соответствующие тормоза и отжор памяти. Поэтому я не спешу делать ЛОД систему.

[MF_Andreich]

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

[Woolf]

к ячеке Дикшинари доступ в 9 раз медленнее одномерного массива

А зачем тут скорость? Их надо брать только на этапе переформирования меша. Так что реально пофиг, сколько времени там занимает обращение к ним.

[bwolf88]

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

Ячейки выделяю, но в пустых чанках информации максимум на 500 байт, так что это вообще не критично. Критично именно выделение памяти на каждый блок в этом чанке для расчет меша. В одном чанке около 12к блоков, пока по 4 байта = 50 кб * 32 000 чанков выходит 1,5 гб. Если меша нет - то массив блоков обнуляется. Мусорщик подчищает и общий отжор снижается почти в 3 раза, но через 2 минуты )). Пока по 4 байта, но в планах расширить размер до ~10 байт на блок.

А зачем тут скорость? Их надо брать только на этапе переформирования меша. Так что реально пофиг, сколько времени там занимает обращение к ним.

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

[bwolf88]

Хотя...

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

Завтра и попробую.

[Woolf]

но на самом деле переформирование меша идет постоянно

Но зачем? Сделал и забыл его, пока не переформируют.

[bwolf88]

но на самом деле переформирование меша идет постоянно

Но зачем? Сделал и забыл его, пока не переформируют.

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