Это потрясающая работа! Особенно идея с тетродеревом, даже и не думал о чём-то кроме октодерева. Но как ты хранишь чанки? Я уже долгое время пытаюсь понять как мне это сделать. На данный момент у меня 1 воксельный объект - 1 буфер. Но я же не могу привязать все буферы для одного вызова (наверно). И держать 1 буфер для всех объектов тоже не выйдет, так как из-за октодерева размер каждого чанка динамичный, а я хочу сохранить возможность изменять чанки. Пожалуйста подскажи как ты это сделал? Я боюсь что все эти годы, я придерживался не правильного подхода.
Каждый чанк у меня имеет собственное тетрадерево, иначе бы при загрузке новых чанков пришлось бы перестраивать всё дерево на сцене. И на самом деле у меня достаточно много буферов, они ссылаются друг на друга по средством ссылок (по сути в структуре просто хранится индекс и размер из другого буфера). Чанки хранят ссылку на своё дерево, дерево разложено в одномерный буфер и само по себе ссылкок не имеет, поэтому чтобы найти с помощью него воксели нужно ещё 2 буфера, один который хранит количество вокселей, которое есть в тетрантах до искомого тетранта, а второй уже плотно хранит воксели. Надеюсь понятно объяснил, потому что там не очень наглядная схема)) До дерева ссылки в чанке были прямо на участки воксельного буфера. GPU не поддерживает динамическое выделение памяти, поэтому приходится так выкручиваться, заранее выделать побольше места, а на CPU его поддерживать, чтобы один участок памяти не перекрыл другой. Конкретно со структурами чанков проблем нет, я загружаю сразу все чанки мира на GPU, поскольку они мало весят, воксели они не хранят, а только ссылки на них. Если надо загрузить данные чанка, то в других буферах выделяется память и заполняются ссылки на них в структуре чанка, а если надо выгрузить, то указатель на данные просто затираются и на те места в буфере перезаписываются другие данные
@@Duxen8956 Кстати, я храню воксели только в виде октодерева, в виде одномерного вектора, который можно без преобразований передать шейдеру. В таком виде я его и редактирую. в векторе конечно после редактирования остаются дыры. Но спустя 5 секунд без редактирования этого октодерева, оно перестраивается по новой в отдельном потоке, что для глубины 8 и среднего чанка занимает
@@Duxen8956 а разве это не значит, что тетрадерево по сути ни как не экономит память, учитывая что приходится выделять место для потенциально полного дерева? Так ещё и надо выделять место под все будущие деревья, которые будут входить в дальность прогрузки
![GUILTY GEAR -STRIVE- Season Pass 4 Playable Character #1 [Queen Dizzy] Trailer](http://i.ytimg.com/vi/nXDsAgYXXv4/mqdefault.jpg)
Обожаю видео такого плана, где разбираются все стороны проблемы. Продолжай в том же духе!
Очень интересно, ждем продолжения
Очень классное видео, жду продолжение!
Кайф!
Вау! Это очень круто! Продолжай пожалуйста
Классное видео, очень интересно слушать ) жду про анимацию!
Коментарий
Это потрясающая работа! Особенно идея с тетродеревом, даже и не думал о чём-то кроме октодерева. Но как ты хранишь чанки? Я уже долгое время пытаюсь понять как мне это сделать. На данный момент у меня 1 воксельный объект - 1 буфер. Но я же не могу привязать все буферы для одного вызова (наверно). И держать 1 буфер для всех объектов тоже не выйдет, так как из-за октодерева размер каждого чанка динамичный, а я хочу сохранить возможность изменять чанки. Пожалуйста подскажи как ты это сделал? Я боюсь что все эти годы, я придерживался не правильного подхода.
Каждый чанк у меня имеет собственное тетрадерево, иначе бы при загрузке новых чанков пришлось бы перестраивать всё дерево на сцене. И на самом деле у меня достаточно много буферов, они ссылаются друг на друга по средством ссылок (по сути в структуре просто хранится индекс и размер из другого буфера). Чанки хранят ссылку на своё дерево, дерево разложено в одномерный буфер и само по себе ссылкок не имеет, поэтому чтобы найти с помощью него воксели нужно ещё 2 буфера, один который хранит количество вокселей, которое есть в тетрантах до искомого тетранта, а второй уже плотно хранит воксели. Надеюсь понятно объяснил, потому что там не очень наглядная схема)) До дерева ссылки в чанке были прямо на участки воксельного буфера. GPU не поддерживает динамическое выделение памяти, поэтому приходится так выкручиваться, заранее выделать побольше места, а на CPU его поддерживать, чтобы один участок памяти не перекрыл другой. Конкретно со структурами чанков проблем нет, я загружаю сразу все чанки мира на GPU, поскольку они мало весят, воксели они не хранят, а только ссылки на них. Если надо загрузить данные чанка, то в других буферах выделяется память и заполняются ссылки на них в структуре чанка, а если надо выгрузить, то указатель на данные просто затираются и на те места в буфере перезаписываются другие данные
@@Duxen8956. Весьма сложно понять конечно. То есть ты хранишь все тетрадеревья в одном буфере? И размечаешь его с помощью ссылок?
@@jexus2912 да, все деревья в одном буфере, которые в доступе по ссылкам из чанков
@@Duxen8956 Кстати, я храню воксели только в виде октодерева, в виде одномерного вектора, который можно без преобразований передать шейдеру. В таком виде я его и редактирую. в векторе конечно после редактирования остаются дыры. Но спустя 5 секунд без редактирования этого октодерева, оно перестраивается по новой в отдельном потоке, что для глубины 8 и среднего чанка занимает
@@Duxen8956 а разве это не значит, что тетрадерево по сути ни как не экономит память, учитывая что приходится выделять место для потенциально полного дерева? Так ещё и надо выделять место под все будущие деревья, которые будут входить в дальность прогрузки