Комментарии 14
А что в плане ресурсоемкости задачи? Говорят, что в теории, отривка графической сцены на вокселях съест намного (насколько?) меньше ресурсов, чем аналогичной полигональной сцены
пока что FPS довольно сильно провисает из-за ray-casting'а — там очень много получается вычислений с использованием матрицы поворота. У полигональной сцены в этом плане есть преимущество. Но сейчас пытаюсь перенести все эти вычисления на GPU (сейчас они только на CPU), который гораздо лучше производит вычисления с плавающей точкой, и добавить обработку не по одному, а «пакетами». Сейчас, к сожалению, только с большими усилиями удалось получить FPS около 50-60 (воксельная сетка 128*128*128), но надеюсь, что все эти оптимизации, а также модификация октодерева (скрещение с kd-деровом и еще кое-какие), помогут выдать большую скорость.
А деревья тоже на GPU переложить нужно? Или обход по дереву не сильно нагружает?
Если координаты типа int, то процессор превосходно справляется сам (так как в основном идут операции битового сдвига). А вот если уже координаты типа float, то уже все немного хуже. К примеру, полная трассировка всего дерева с сеткой 256*256*256 на одном потоке с целочисленными координатами занимает 20 msec., а с float — 25 msec. С другой стороны, при реальном использовании, полной загрузки дерева не может быть в принципе (модель глаза на сетке 128*128*128, пока что на чистом октодереве, без каких либо модификаций, занимает всего около 200 тыс. узлов, при том, что максимальная нагрузка для такого дерева — 2,4 млн. узлов).
«знакомство с группой экономистов, которые параллельно осваивали web-программирование и которые меня подтолкнули изучать программирование»
Программеры изучают менеджмент, экономисты — веб-программирование, филологи — свободную кассу…
Куда мир катится?
Программеры изучают менеджмент, экономисты — веб-программирование, филологи — свободную кассу…
Куда мир катится?
В будущее без людей.
«Экономистами» я их назвал только из-за того, что они учились (а некоторые уже и преподавали) в экономических университетах. А web-программированием занимались параллельно, причем вполне неплохо. Возможно это связано с тем, что на «математическое обеспечение информационных систем» очень трудно поступить, а вот в экономисты берут всех подряд, да еще и не особо напрягают.
Рассматривается ли вариант создания поверхности на основе октодерева — вершинных и индексных буферов для отрисовки в GPU? А также использования instancing и geometry shaders для оптимизации?
В данный момент не рассматривается, так как я использую OpenGL только для конечного вывода картинки на экран (то есть преобразование готового массива, в котором хранится растеризованная картинка, в текстуру и наложение ее на прямоугольный полигон). Как следствие, отсутствуют вертексы в целом, 2d текстуры (сейчас добавляю в код возможность использование 3d-текстуры), карта высот и нет необходимости в геометрических шейдерах (сейчас осваиваюсь с GLSL для возможности написания пиксельных шейдеров). Вся остальная отрисовка будет выполняться либо на OpenCL, либо на AMP C++ (проверяю, какая из библиотек быстрее), на которых будет написан ray-casting.
Поддерживаю вопрос. Напрямую рисовать воксели на сегодняшем железе сомнительная с точки зрения ресурсоемкости и качества ренедера затея…
Согласен. Но мне сейчас нужно добиться максимальной скорости отрисовки напрямую, а вот дальше уже можно будет добавить отрисовку дальних объектов полигонами, конвертация из воксельной модели в полигонную с хранением в VBO, в крайнем случае blur. Сейчас главное получить отрисовщик, который максимально быстро сможет использовать все преимущества вокселей и 3d-текстур.
В библиотеке VTK есть объемный рендеринг через CPU и GPU, нужно лишь подготовить данные, что достаточно просто. Смотрел в этом направлении?
Может вам будет интересно покопать Polyvox, слышал про него много хорошего и видел приличного размера конструкции (для рендера использовался Ogre3D).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Воксельная графика своими руками — первые шаги