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

Воксельные миры (2 стр)

Страницы: 1 2 3 4 5 6 Следующая »
#15
17:30, 10 июня 2020

Решил поискать про вокслап а нашел вот это: https://www.voxelfarm.com/index.html


#16
17:33, 10 июня 2020

samrrr
> Решил поискать про вокслап а нашел вот это:
> https://www.voxelfarm.com/index.html
это никакие не воксели, а обычные marching cubes. то есть оно внутри представлено вокселями, а рендерится треугольниками, это шлак. мы тут говорим о том, как рендерить сами воксели.

#17
17:52, 10 июня 2020

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

>это шлак.
Space engineers шлак? что-то непохоже.

#18
(Правка: 18:11) 18:06, 10 июня 2020

Suslik
> тут показано, как растеризуется карта высот, причём на ней колонки смотрят
> вверх относительно направления взгляда камеры. с ней всё понятно. а как
> осуществляется переход от карты высот к произвольному объёму, причём ты
> описываешь алгоритм, в котором колонки смотрят по направлению взгляда камеры,
> так?

Да, это самый интересный случай. В нем нельзя эффективно сделать обычный реймаршинг, идя вдоль луча для каждого вертикального столбца пикселов. Но можно эффективно идти по слоям, рисуя вот именно такие полоски как там показано. При этом всегда известно для каждого экранного x какой экранный y для него минимально видимый, персперктивных преобразований в коде не появляется, так как просто известно что в каждом следующем слое на экран влезает 2 дополнительных воксела по горизонтали. Выходит что понадобится идти вдоль столбца от его начала для каждого видимого столбца, но тут сильно поможет RLE. В octree чтобы приблизиться к сложной поверхности может быть нужно сделать много итераций по разным уровням дерева, а с RLE это просто 1 шаг, очень эффективно выходит при разумном количестве этажей.

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

Для ускорения обработки совсем далеких объектов используется mip-map всего уровня со своими столбцами.

#19
18:33, 10 июня 2020

Вий
> Да, это самый интересный случай. В нем нельзя эффективно сделать обычный
> реймаршинг, идя вдоль луча для каждого вертикального столбца пикселов. Но можно
> эффективно идти по слоям, рисуя вот именно такие полоски как там показано. При
> этом всегда известно для каждого экранного x какой экранный y для него
> минимально видимый, персперктивных преобразований в коде не появляется, так как
> просто известно что в каждом следующем слое на экран влезает 2 дополнительных
> воксела по горизонтали. Выходит что понадобится идти вдоль столбца от его
> начала для каждого видимого столбца, но тут сильно поможет RLE. В octree чтобы
> приблизиться к сложной поверхности может быть нужно сделать много итераций по
> разным уровням дерева, а с RLE это просто 1 шаг, очень эффективно выходит при
> разумном количестве этажей.
я правильно понимаю, что в этом описании колонки смотрят именно по оси y в экранных координатах? то есть колонки смотрят перпендикулярно камере, а не вдоль направления её взгляда?

ещё я правильно понимаю, что наихудший тест для такого рендера — это трёхмерная шахматная доска?


samrrr
> > то шлак.
> Space engineers шлак? что-то непохоже.
шлак не в смысле, что игра плохая, а в смысле что сам рендер вокселей через их полигонализацию никакого интереса не представляет, это давно изученный вопрос.

#20
18:39, 10 июня 2020

Suslik
> я правильно понимаю, что в этом описании колонки смотрят именно по оси y в
> экранных координатах? то есть колонки смотрят перпендикулярно камере, а не
> вдоль направления её взгляда?
Случай когда колонки смотрят по оси y в экранных координатах как раз простой, он подходит для видов на север, запад, юг и восток. И в этих видах простой реймаршинг работает.

А это описание уже про случай взгляда "наверх", когда ось "вглубь экрана" для камеры сопадает с осью "колонки вокселов зажатой RLE", колонки идут вдоль направления взгляда. Реймаршинг не работает, приходится делать wave surfing/порталы.

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

#21
18:45, 10 июня 2020

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

я примерно понял твоё описание wave surfing'а, но там всё равно гораздо больше прыжков через обручи, чем я представлял.

#22
(Правка: 19:14) 18:53, 10 июня 2020

Это просто способ использования пространственной когерентности. Напоминает чем-то происходящее в демке Heaven7: там запускали трассировку не на каждый пиксель экрана, а, скажем, на узлы сетки 8х8 пикселов. До тех пор пока 4 угла ячейки 8х8 попадают в один и тот же воксель, можно продолжать трасировать только углы и для всей ячейки считать что лучи попали в этот же воксель. А если лучи в углах попадают в разные воксели, разбить ячейку на 4 равных части 4х4 пикселя и продолжать.

#23
(Правка: 1:43) 1:16, 11 июня 2020

Unlimited Detail

Изображение

Как я понимаю, Unlimited Detail работает так:
Мир представлен в виде octree, в узлах которого на разных уровнях могут содержаться листья для разных LOD.

Отрисовка происходит проходом по узлам дерева в порядке «от камеры вдаль». В процессе поддерживается маска-портал, в которой отмечены все незакрашенные пиксели экрана.
Для каждого рассматриваемого узла octree определяется его bounding box. Проверяется, попадают ли незакрашенные точки экрана в этот bounding box. Если не попадают, к детям переходить не требуется, можно продолжать обход. Для box размером в 1 пиксель берется его LOD и рисуется. Для остальных происходит переход к детям и обход в том же порядке.

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

Модель в виде octree читается с диска или по сети как поток блоков, содержащих данные о нескольких узлах каждый. У каждого узла есть 8 битов маски, указыающие наличие каждого из 8 детей. У каждого блока указано в каких блоках искать узлы-детей узлов для этого блока. Кроме этого есть индекс блоков, описывающий где какой блок искать и какую часть модели этот блок описывает.

Верхние несколько уровней octree сразу превращаются в ячейки, чтобы индексировать проще было. И дальше блоки описывают все более детальные уровни части другого блока.

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

Очень полезно посмотреть вот этот ролик про Unlimited Detail начиная с 6 минут 53 секунд (красивый и непонятный отладочный режим, про который ничего не сказали).

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры

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

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры

#24
(Правка: 1:25) 1:22, 11 июня 2020

Мысль для медитации: а ведь можно взять SVO и отрисовать его при помощи 6 камер смотрящих вдоль осей, идя от камеры вдаль, а потом натянуть это на кубик как текстуру и вращать его. Взять лучшее от подходов Voxlap и Unlimited Detail. На самом деле никогда не будет нужно даже 3 кадра одновременно, можно заранее посчитать какая часть каждой текстуры куба может быть видна на экране и не рисовать лишнее.

#25
(Правка: 4:50) 4:44, 11 июня 2020

Вий
я тут вот: https://gamedev.ru/unity/forum/?id=248517&page=6&m=5199303#m78 показываю, как можно рендерить 1000000 капсул. аналогичным образом можно рендерить сферы и, главное, сурфелы. то есть если каким-то образом дать мне массив из, скажем, 10000000 точек, которые покрывают всю геометрию на экране с одинаковой плотностью (в скринспейсе), я могу их растеризовать с освещением. ещё на таком представлении легко считается GI вместо уродского плоского света а-ля UD. мне тоже нравится идея совместить это с 6 фейсами кубмапа по осям, но совершенно не нравится баловство на CPU — алгоритм нужно разрабатывать так, чтобы его удобно было выполнять на GPU, иначе нет никакого смысла.

> Очень полезно посмотреть вот этот ролик про Unlimited Detail начиная с 6 минут 53 секунд (красивый и непонятный отладочный режим, про который ничего не сказали).
у них есть артефакты, ориентированные по осям координат. я ставлю, что они возникают, именно потому что они растеризуют те самые ориентированные по осям камеры.

#26
(Правка: 5:07) 5:05, 11 июня 2020

Suslik
Аффинное преобразование даёт артефакты, тормоза при подгрузке дают не тот лод и тоже артефакты.
Можно попробовать искать видимые точки на cpu и выплевывать их в gpu для отрисовки. Какой у тебя шейдер в капсулах, GLSL?
Я возился со всем на cpu только с целью доказать что UD не фейк. Сейчас то не актуально уже, а тогда было.

#27
(Правка: 5:48) 5:46, 11 июня 2020

Вий
короче, я придумал. мне кажется, я придумал, как скрестить UD и GPU.

> Можно попробовать искать видимые точки на cpu и выплевывать их в gpu для отрисовки
да, именно в этом идея. CPU ищет видимые чанки, GPU их рисует. чанков всегда будет гораздо меньше, чем самих точек, поэтому их можно обработать на CPU за разумное время. чанки ищутся через растеризацию axis-aligned cones на CPU в низком разрешении (скажем, 64х64 вполне хватит). найденные чанки либо уже находятся на GPU, либо добавляются в очередь загрузки с диска, как только загружаются, отправляются на GPU. чанки, которые не нужны, удаляются с GPU. GPU просто тупо растеризует все загруженные на него чанки, не выполняя ни culling'а, ни обходов octree, просто растеризует 10 миллионов точек, это ерунда.

#28
(Правка: 9:33) 9:33, 11 июня 2020

Лучше все 1920х1080 точек так и искать. UD их успеваел их покрасить ещё 10 лет назад, а нам достаточно только найти.

Шейдеры у тебя на чем? GLSL?

#29
(Правка: 9:40) 9:38, 11 июня 2020

Вий
> Лучше все 1920х1080 точек так и искать
это я считаю медленно и в этом нет никакого смысла, потому что на уровне блоков 32х32 пикселя (примерно) гораздо быстрее просто растеризовать 10000 точек, которые этот блок покрывают, на GPU, чем мусолить листья дерева на CPU. более того, этот блок можно хранить на GPU и следующий кадр просто отрисовывать его точно так же c немного изменившейся позиции камеры, пока CPU решает, какие новые блоки добавить и какие старые выкинуть.

ещё, имея эти точки на GPU для главной камеры, их можно переиспользовать для расчёта теней и GI, хоть с точки зрения их камер частота семплинга и не будет оптимальной.

> Шейдеры у тебя на чем? GLSL?
какая разница-то? ну на glsl/spirv

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