- Рендерферма кроликов
- Забанен
NickDoom
Выздоравливай
> Каст каждый шаг ограничивается найденными сверху и снизу кубиками
Метод горизонта, как в Doom
Видимо взгляд должен быть вдоль коорд оси? Можно отрисовать сцену на грани skybox, а потом крутить skybox вокруг игрока для произвольного обзора
Про GLSL - любопытно
У меня сначала пускаются 8 лучей через вершины world axis aligned player centered box. Если 4 луча, пущенные через вершины одной грани, все попали в одну грань одного куба на сцене, то никакой другой куб не может "влезть" между ними (частично перекрыть квад их проекции на экране), рисуем квад из их проекций, иначе - разбиваем на 4, пуская средние лучи между соседними лучами и один в центре и далее по рекурсии. Разбиение идет до уровня 9, быстродействие кушается на краях кубов, много лучей и квадов в 1-2 pixel, но если рисовать найденные кубы через GL, можно разбивать до min размера куба на экране, думаю glDrawElements с ~10 тыс индексов - это ничто
В общем-то цель не софтрендер, а эффективное определение только видимых кубов/граней
На дальности 128 куб размера 1 виден под углом 1/128. При fov 90 град это 1/256 экрана, при разрешении 1024 - 4 пиксел
Еще важный момент - сейчас трассировка проходит весь 3d массив, т.е на больших открытых пространствах идет до max дальности. Нужны mip, т.е. если весь куб 128x128x128 пуст - пройти его одним шагом. Сейчас алгоритм Брезенхэма - выбирается min время до достижения очередной коорд плоскости (X=N итд, N-целое) и увеличивается на время прохождения отрезка длины 1 по соотв оси. Надо переписать на кубы переменного размера 2^k
MrShoor
Даа, сейчас разбиение box до уровня 9 при разрешении окна 800x600, т.е. где-то получаются лучи через 2 pixel, при повышении разбиения падает FPS. Можно менять через параметры командной строки в файле cmd, выкладывал exe и исходники
https://habr.com/ru/articles/799077
Не очень внятно, но изложил лог своих бесплодных размышлений.
Может, какое зерно там накопать удастся.
Команча четыре на вас не зватает
innuendo
А там можно было разломать вертолет или землю на воксели? Или просто heightmap?
Рендерферма кроликов
Для 98 года было охренительно
Два метода, альтернативных raycast:
1. Портальный - считаем грань пустого куба порталом, через который виден сосед. Пересечение множества порталов выводится аналитически
Предложил glukh, для тетраэдров, Тарас использовал в своем Хулионе для кубов со сдвинутыми вершинами
2. Hierarchical Z-buffer. Тут надо рендерить треугольники (или вокселы?) в screen space mipmap.
Для треугольника нужно оптимизировать нахождение пересечения с квадратом, в основе метод SAT
NickDoom
Просмотрел твою статью, примерно понятно.
Жду реализацию на glsl. Может сделать игру на ShaderToy? )
Рендерферма кроликов
Мерси.
Вряд ли я чего-то реально осилю, так что feel free to continue, но если вдруг — буду отчитываться :)
Трассировка лучей хороша именно в паре с репроекцией, тогда можно трассировать только небольшую долю экрана каждый кадр
Вий
Пока что я трассирую кубы, там лучей немного
А для полигональных сцен или point cloud надо страшно оптимизировать трассировщик
В текстурах тексели лежат в z-curve order, это дает следующие выгоды
1) обеспечивает локальность
2) смещение соотв тексела в мипе на уровень выше получается простым >>3 (для 3d текстуры)
Смещение получается пооечередной записью битов zyxzyxzyx...(2)
Однако, перейти скажем от тексела x y z к текселу x+1 y z (что необходимо для трассировщика) уже не так просто, нужен перенос из бита 0 в бит 3, из 3 в 6 итд, это можно сделать, заполнив биты yz единицами 11х11х11х...(2)
#define mask 0b110110...110
(n&mask)|((n|mask)+1)
Также, нужна переконвертация xyz <-> offset при создании/удалении кубов игроком и их генерации вдали при передвижении по карте. На gpu видимо то реализуется простой схемой, а на cpu проблема
NickDoom
Насчет Думо-Дюковского движка тоже есть соображения, вот только кому оно сейчас нужно
Вий
> Трассировка лучей хороша именно в паре с репроекцией
Если позиция камеры не поменялась с прошлого кадра, то достаточно заполнить пустоты по краям экрана.
А если камера сдвинулась - появляются новые точки, ранее загороженные, теперь могущие перекрыть прежние.
Однако, репроецированные точки дают верхний предел расстояния для рэйкастера, интересная оптимизация, сработает внутри закрытых локаций.
А как быть с открытыми пространствами? Там с одной стороны большие расстояния, с другой - они относительно мало меняются при передвижении и сцена похожа на скайбокс
1Man1
> А как быть с открытыми пространствами? Там с одной стороны большие расстояния, с другой - они относительно мало меняются при передвижении и сцена похожа на скайбокс
На открытых пространствах тоже отлично работает.
Земля отлично репроецируется от кадра к кадру, деревья и дома тоже.
Суть оптимизации от репроекции в том, чтобы не пересчитывать весь экран каждый кадр, не искать видимый в каждом пикселе воксель, грубо говоря.
Если смотреть на рендеринг воксельной модели как на задачу поиска, получается, что каждый кадр нужно для каждого пикселя экрана найти такой воксель, который в этот пиксель рисуется.
Если ты в прошлый кадр уже решил эту задачу, в следующий кадр ты можешь переиспользовать результаты прошлого поиска для того, чтобы быстрее найти новые видимые точки для пикселов.
Например, если мы рассматриваем густую траву, камера между кадрами немного сдвигается и травинки ближайшего к нам ряда начинают загораживать некоторые части более далеких травинок, а некоторые другие части могут стать видимыми и узнать, что именно видно на месте сместившихся краев травинок можно, например, запустив новый луч, но не из глаза, а примерно с того расстояния до камеры на котором была точка перекрытия другим вокселом.
А еще мы, например, приблизились к травинке и между парой вокселов травинки видимых ранее в соседних пикселах появился еще один видимый пиксел. Мы точно конечно не знаем, но можем предположить, что видно в этой точке будет воксел который примерно посередине между двумя видимыми рядом, можно оттрасировать к нему луч откуда-то из недалекой точки (снова не из глаза). Вот как-то так.