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

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

10 млн точек это не так много как кажется, это всего 4х перекрытие 1920x1080

При этом 10 млн точек это минимум 30 мегабайт только на RGB, а чтобы просто копировать 30 мегабайт за кадр на 60 кадрах в секунду понадобится 1.8 ГБ/с.

Вий
> Если сделаешь блоки, то на первом же дереве с листвой потеряешь находящееся за
> ним дерево, куст за вторым деревом и лужу за кустом.
растеризация не останавливается на первом блоке. я планирую рендерить все блоки, которые пересекают луч, по типу cone tracing. occlusion на CPU считаться вообще не будет, потому что с этим гораздо лучше справится GPU.

> 10 млн точек это не так много как кажется, это всего 4х перекрытие 1920x1080
именно так, поэтому я планирую gap filling для surfel'ов, который во-первых, позволяет снизить количество точек как минимум раз в 10-100, во-вторых, позволяет бесплатно хранить информацию за первой видимой поверхностью, что позволяет считать тени и GI от загороженных объектов.

Ну вот возьми 1000 кроликов, сторона кролика 512 вокселов. Видимых не помню сколько, но никак не менее 512^2. Это уже 2.6 миллиарда вокселов. За кадр столько на gpu не передать

Вий
> Ну вот возьми 1000 кроликов, сторона кролика 512 вокселов. Видимых не помню
> сколько, но никак не менее 512^2. Это уже 2.6 миллиарда вокселов. За кадр
> столько на gpu не передать
на GPU отправляются блоки только того уровня octree, у которых плотность точек находится в нужном соотношении с плотностью экранных пикселей. например, одна точка на каждые 100 пикселей. поэтому чем дальше от камеры, тем более разреженными будут такие блоки в мировых координатах. поэтому если куст будет за деревом, то и блок куста и блок дерева отправится на GPU, но так как куст дальше, то у него разрешение будет ниже.

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

впрочем, это я фантазирую. я думаю это попробовать написать, но пока ещё не начал.

Все равно по числам не сходится, 1000 кроликов перекрывают экран в 20 слоев, это примерно 40 млн точек. Зачем так делать, когда можно спокойно найти все видимые точки и передать только их?

Вий
> Зачем так делать, когда можно спокойно найти все видимые точки и передать только их?
во-первых, даже формировать массив отдельно видимых точек — это гемор с точки зрения драйвера, потому что ему гораздо проще указать на блок, который просто стримится с диска без изменений, чем что-то там собирать на CPU. я хочу, чтобы CPU вообще ничего не знал ни об отдельных точках, ни об отдельных пикселях, это совершенно не его дело.

> Все равно по числам не сходится, 1000 кроликов перекрывают экран в 20 слоев, это примерно 40 млн точек. Зачем так делать, когда можно спокойно найти все видимые точки и передать только их?
не понял, откуда число. на экране в первом слое будет в идеале 1920x1080 / 100 точек (если одна точка на сто пикселей и нет перекрываемой геометрии), умножаем эту величину на столько, сколько у нас слоёв перекрывающейся геометрии. допустим, у нас 100 слоёв (что в реальности может быть только в лесу) — это же всего лишь миллион точек.

У UD на CPU 10 лет назад было 1024х768 точек с освещением и анимацией и основная фишка была в высокой детализации мира. Если отказаться от высокой детализации, выйдет мыльце растянутое из 640х480 на весь экран. Да, освещение будет классное, но деталей не добавится. Я бы спокойно нашёл все видимые точки на CPU за 8 мс, отдал бы их пусть за ещё 3 мс на gpu и спокойно рисовал бы ещё 5 мс.

Вий
> Если отказаться от высокой детализации, выйдет мыльце растянутое из 640х480 на весь экран
погоди, ты нипонил. я планирую растеризовать gbuffer — позиции, глубину, нормали и UV. далее на это натягиваются нормальные текстуры. растеризовать сами точки можно, но тогда не прокатит трюк с gap filling'ом, а я его считаю важным.

Мне кажется интересной задача в такой постановке:
Сделать next-gen воксельный рендер, который будет идеально работать на железе уровня GeFroce 1080 и 4 core/8 thread CPU, выдавая плавные 60 FPS в 1920x1080. Детализация геометрии должна быть такой, чтобы средний игровой кадр не менее чем на 90% состоял из вокселов проецируемых в 1 пиксел. Одним из источников моделей должно быть копирование реального мира по фото/видео без специальной техники.

Примеры среднего игрового кадра:

Вий
> Сделать next-gen воксельный рендер, который будет идеально работать на железе
> уровня GeFroce 1080 и 4 core/8 thread CPU, выдавая плавные 60 FPS в 1920x1080.
> Детализация геометрии должна быть такой, чтобы средний игровой кадр не менее
> чем на 90% состоял из вокселов проецируемых в 1 пиксел. Одним из источников
> моделей должно быть копирование реального мира по фото/видео без специальной
> техники.
тут просто есть две ветки: либо ты считаешь, что у тебя информация о цвете (albedo, glossiness, metalness, emissive) хранится в самих точках, либо точки хранят только uv для текстурирования. по идее конкретный выбор здесь только определяет, какие именно оптимизации ты можешь для этого запилить, по большей части алгоритмы будут похожие. я попробую побаловаться ночью и посмотреть, что из этого может получиться. тоже ориентируюсь чисто на сканированные данные.

я брал отсюда тестовые данные (пока не смотрел): https://www.navvis.com/m6-pointclouds

Я думаю, а не попарсить ли модели от unlimited detail чтобы было что рисовать на старте

Вий
если распарсишь, дай мне тоже побаловаться

Вий
> Детализация геометрии должна быть такой, чтобы средний игровой кадр не менее
> чем на 90% состоял из вокселов проецируемых в 1 пиксел.
cкажем кадр=1024х768
90 процентов это=900х630 вокселов
эти 900х630 вокселов=они в 1 пиксел
то есть на экране видно один пиксел
так правильно?

жду ваши воксель-рендерилки на 4k мониторе посоны