LINUX.ORG.RU

Про volume ray tracing


2

2

Написал давно достатосчно свой рей-трейсер для вокселёв. У меня воксель - это кубоид с заданными сторонами, полностью прозрачный или полностью непрозрачный, и с ребрами параллельными осям координат. Я строю на основе вокселей в сцене октодерево (куда попадают только непрозрачные воксели - sparse voxel octree) для того, чтобы ускорить поиск пересечений луча с облаком вокселей.

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

Скачал несколько CT сканов разных кишок и мозгов. Они представляют из себя сетку k x l x m с одинаковым шагом. В «узлах» этой сетки число, представляющее плотность элемента пространства с такими координатами. Я сделал несколько рендерингов, полагая воксели с плотностью меньше пороговой полностью прозрачными, а выше пороговой - полностью непрозрачными.

Теперь я хочу поиграться с прозрачностью. Тут вижу 2 проблемы, ставящие применимость octree под вопрос:

1) Тут нет «прозрачных» вокселей, которые не заносятся в дерево. Каждый воксель в сетке имеет свою прозрачность и должен быть как-то учтен при построении рендеринга.

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

Получается, применять октодерево больше нет смысла, а можно, скажем, идти по лучу с неким шагом, пока не накопим нужное значение плотности среды/цвета. Но это медленно. А есть ли какие-либо приемы для рендеринга вокселей с учетом полупрозрачности?

Ответ на: комментарий от invy

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

amphibrakhij
() автор топика
Ответ на: комментарий от amphibrakhij

я могу искренне посоветовать гугл, я там в своё время (да и сейчас) находил кучу статей по рэйкастингу в разных вариантах и другим методам volume rendering'a.

по идее именно надо таки лучём весь объём проходить и ставить воксели. но лучше читай статьи, а то я точно сейчас «насоветую» :)

вот например: http://graphics.ethz.ch/teaching/former/scivis_07/Notes/Handouts/03-raycastin...

invy ★★★★★
()
Ответ на: комментарий от invy

А вот сколько статей не смотрел, всё пишут какую-то элементарщину. Вроде таких формулок:

a_{i+1} = a_i + a(x) (1-a_i)

(это для плотности). Ну или ещё какую-нибудь хрень. По делу из кучи всего пересмотренного нашел только одну (где про эти октодеревья и узнал)

anonymous
()
Ответ на: комментарий от invy

И да, у тебя советуют прикупить какое-то Voxelpro. Ну да, счас :)

anonymous
()

Если делать тупо в лоб (есть 3D массив данных и рей-трайсинг) то для актуального массива (что бы кишки были не из кубиков) это будет крайне долго, потому как локальность данных в таком массиве ни к черту, кэшируемость сыпется и привет. Можно переупорядочивать данные в хитрый 3D массив, у которого две оси совпадают с осями окна в котором строится сцена, а третья идет вдоль луча - это ускорит построение, но все равно задержки будут приличные, т.е. красиво покрутить картинку не выйдет. Можно попытаться припахать GPGPU - коллеги довольно таки здоровые массивы визуализируют, выходит шустро.

ИМНО все таки надо идти от данных (т.е. обходить не пиксели окна а воксели массива) и заюзать какой нить алгоритм для прозрачности, позволяющий накидывать в пиксель окна воксели в произвольном порядке.

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

AIv ★★★★★
()

А вообще, по личному опыту визуализации 3D массивов - ничего лучше срезов пока не придумали;-( Понять что либо на такой картинке, с прозрачностью, невозможно, даже если ее можно интерактивно крутить. Куда информативнее срезы, которые можно двигать. Сравните (1), (2) и (3) при том, что (1) строится секунды а (2) и (3) десятки секунд.

Если точнее, на моем стареньком ноуте с core2duo (1) строится за 0.3сек (т.е. срезы двигаются интерактивно, отзывчивость прекрасная), (2) и (3) за 30 сек, массив 512х512х512. (2) и (3) как раз тупой рей-трайсинг в лоб, только там хитрый какой то алгоритм итоговой обработки дающий цвет точки, я его уже забыл;-)

AIv ★★★★★
()
Последнее исправление: AIv (всего исправлений: 1)

Получается, применять октодерево больше нет смысла

Голос с дивана: Ну почему, во-первых, можно построить его так, чтобы все листы на пути пачки лучей влезали в кэш. Если сканировать экран по z-order curve, локальность доступа будет высокой, это, мне кажется, позволит здорово уменьшить число кэш-промахов. Во-вторых, в каждую ветвь октодерева можно положить усреднённое значение плотности, чтобы с удалением от наблюдателя или по какой-то другой эвристике можно было увеличивать шаг.

dmfd
()
Ответ на: комментарий от dmfd

Насчет первого не факт. Насчет второго - да, безусловно.

AIv ★★★★★
()
Ответ на: комментарий от AIv

Зависит от гладкости кривой. Пример на рисунке (3 поверхности с освещением) строит около 50 секунд на моей машине.

abalakin ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.