Воксельная графика что это

Воксельная графика своими руками — первые шаги

Знакомство с воксельной графикой

В процессе поиска алгоритмов расчета коллизий на сайте GameDev, я наткнулся на маленькую статью про движок idTech 6 и заинтересовался воксельной графикой, которую противопоставляют полигональной графике, на которой сейчас основана почти вся компьютерная графика.
Вообще, воксел расшифровывается как «объемный пиксель», однако сейчас под вокселом в основном понимается некий примитив, чаще всего куб или прямоугольный параллелепипед, который имеет определенный размер и цвет. В idTech 6 и в движке Кена Сильвермана Voxlap они хранятся в разреженном октодереве (SVO — sparse voxel octree), что позволяет экономить память и делает возможным простую реализацию «уровня детализации».

Первые попытки

Штурмовать сразу трехмерное пространство я не решился — слишком пугающе выглядел весь тот список формул, которые бы пришлось освоить (о них речь пойдет чуть ниже), и решил просто переписать код, чтобы платформер использовал «боксы» — квадраты, и соответственно хранились не в разреженном октодереве, а в разреженном квадродереве.
Первый код был ужасен — все функции работы с деревом, такие как удаление, обход дерева, создание узлов, были итеративными отдельными от класса QuadTree функциями. В прочем, даже добавление их в пределы класса особо не сыграло роли, так как в последствии выяснилось, что рекурсивные функции сильно выигрывают в данном случае. Единственное, что принесли полезного эти первые попытки — это четкая формулировка, какие функции мне нужны, а также основы реализации деревьев на С++, что в дальнейшем очень помогало и, я надеюсь, еще будет помогать. И, конечно же, именно те первые попытки подтолкнули изучать OpenGL (правда до этого прельстился Direct2D, но очень быстро разочаровался в нем).

Переход в объем

OpenGL я начал изучать на NeHe gamedev и как то очень быстро втянулся в трехмерное пространство и начал планировать движок для Quake-подобной игры. Квадродерево было переписано в октодерево и начались первые сложности. Октодеревья потребляют памяти гораздо больше, и даже не смотря на то, что все основные функции стали рекурсивными, все равно они тратили слишком много времени и памяти. Для решения этой проблемы были реализованы следующие методы:

Оптимизация памяти

В октодереве очень часто приходится использовать операторы new/delete, которые выделяют для указателя место в динамической памяти (куче). Динамическая память медленнее, чем статическая (стек), а также сами функции new/delete выполнялись для меня слишком медленно. Из-за чего был написан собственный класс MemoryPool и шаблон mem_pool_tree.
mem_pool_tree был написан под впечатлением от BST-дерева, с которым я познакомился из книги Т. Кормана «Алгоритмы. Построение и анализ», и не работает напрямую с памятью, а только оперирует цифрами, которые в последствии используются для смещение указателя с начала массива в статической области памяти. Предугадать удаления не представлялось возможным, а вот выделять «правильные» куски памяти было реально, из-за чего я взял у BST дерева идею и повороты, и добавил «блочность» — mem_pool_tree хранит узлы, в котором две переменные хранят начало и конец блока, и еще две переменные — начало и конец занятого пространства. Если происходит попытка удалить кусок в середине занятого пространства, то узел делится, если вызывается функция выделения куска, то алгоритм ищет такой блок, где выделение пространства позволит ему объединится с соседним блоком. И периодически вызывается функция балансировки.

Многопоточность

Из-за строения дерева, в котором у родительского узла есть указатель на массив из восьми дочерних узлов, функции, где требуется полный обход дерева (такие, как удаление всего дерева, удаление лишних элементов, вычисление средних вокселов и т.д.), были написаны с возможностью включить многопоточность. Многопоточность была реализована с помощью OpenMP. К примеру, надо оптимизировать дерево (например, зачем хранить восемь дочерних узлов, если можно их цвет передать родительскому узлу, а их удалить). Реализуем:

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

Загрузка и сохранение вокселей

Долго пришлось искать оптимальный метод хранения вокселей в файле — ведь в условиях, когда оперативная память ценна, хранить лишние вокселы в оперативке является непозволительной роскошью. После долгих исканий, выбор остановился на SQLite3, в котором есть кэширование, а также возможность загрузить только те вокселы, которые требуются исходя из значений «уровня детализации». Самая быстрая работа с SQLite3 базами оказалось при встраивании в проект исходного кода sqlite3 и самостоятельной компиляции (точных цифр не помню, но что то вроде полмиллиона переменных за 200-250 ms, причем на нетбуке с Intel Atom). Естественно, в SQLite3 использовались для ускорения «Begin transaction;», «Commit transaction;», «PRAGMA journal_mode = MEMORY;», «PRAGMA synchronous = OFF;» и т.д.

Скриншоты

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

Текущие задачи и заключение

Полиморфизм

Сейчас октодерево в очередной раз переписывается с применением полиморфизма. Основная задача — чтобы дерево было не чистым октодеревом, а скрещением с kd-tree (дерево, в котором идет не разбиение воксела на 8 маленьких вокселей, а разбиение на два воксела с определенной пропорцией и по определенной оси), и еще другими модификациями.

RayCasting

Октодерево позволяет Ray Casting, алгоритм «бросания лучей», с помощью которого сейчас пишу растеризатор. Также реализации алгоритма используется OpenGL (генерация текстуры из массива и отображение его на полигоне), «групповая трассировка» и C++ AMP. В целом, эта тема хорошо раскрыта на ray-tracing.ru.

Заключение

В целом, тема интересная, и можно много интересного найти по ней. Например: статья на хабре про движок Atomontage и презентация технологии SVO с SIGGRAPH 2012.

Написанный мною класс распределения памяти с использованием массива в статической памяти, после замеров, выдал следующие данные:

Источник

Станут ли воксели новой прорывной технологией?

Мы пообщались с потрясающими разработчиками Atomontage, пытаясь разобраться, смогут ли воксели вернуться и победить пиксели.

Воксельная разработка

Бранислав: в 2000-2002 годах я участвовал в соревнованиях европейской демосцены. Я написал несколько 256-байтных демо (также называемых intro) под ником Silique/Bizzare Devs (см. «Njufnjuf», «Oxlpka», «I like ya, Tweety» и «Comatose»). Каждое из интро генерировало в реальном времени воксели или графику из облака точек. И воксели, и облака точек являются примерами сэмплированной геометрии.

Интро выполняли свою задачу всего в 100 инструкциях процессора, таких как ADD, MUL, STOSB, PUSH и им подобных. Однако из-за самой природы такого типа программ на самом деле десятки инструкций использовались просто для правильной настройки, а не для генерации самой графики. Тем не менее этих 50 с лишним инструкций, которые по сути являлись элементарными математическими операциями или операциями с памятью, оказалось достаточно для генерации довольно красивой подвижной 3D-графики в реальном времени. Все эти 256-байтные интро выигрывали с первого по третье места. Это заставило меня осознать, что если такую 3D-графику возможно создавать без полигонов, то в играх и других приложениях можно достичь гораздо большего с помощью того же принципа: использования сэмплированной геометрии вместо полигональных мешей. Решение заключается в простоте. Я понял, что доминировавшая тогда парадигма, основанная на сложных и фундаментально ограниченном (необъёмном) представлении данных, уже готова была упереться в потолок возможностей. То есть настало подходящее время испробовать эту «новую», более простую парадигму: объёмную сэмплируемую геометрию.

Дэн: ещё учась в старшей школе в Швеции, я начал программировать 2D-движок с сайдскроллингом, на котором я в результате создал инди-игру под названием «Cortex Command». Она была похожа на «Worms» или «Liero», но с геймплей был больше в реальном времени и с элементами RTS. Также в игре использовалась более подробная симуляция различных материалов каждого пикселя рельефа. В виде сбоку, похожем на «муравьиную ферму», персонажи игрока могли копать золото в мягкой земле и строить защитные бункеры с твёрдыми бетонными и металлическими стенами. В 2009 году Cortex Command выиграла награду за техническое превосходство и приз зрительских симпатий на Independent Games Festival. Ещё с того времени я мечтал создать полностью трёхмерную версию игры, а это было возможно только с помощью волюметрической симуляции и графики.

Примерно шесть лет назад я искал готовые воксельные решения и нашёл работы Бранислава на его веб-сайте и в видео, в котором он рассказывал о неизбежном переходе от полигональной 3D-графики к чему-то, напоминавшему сделанное мной в 2D: к симуляции всего виртуального мира как небольших блоков-атомов со свойствами материалов. Мне не только показалось правильным его заявление — его технологии, судя по простым, но впечатляющим видео, оказались лучшими и самыми убедительными из существовавших. Я начал спонсировать его проект через его веб-сайт и общаться с ним, что привело к началу многолетней дружбы, а теперь и совместному финансированию нашей компании. Восхитительно чувствовать себя частью этого поворотного периода в таком эпичном проекте, в котором результаты долгих лет исследований и разработок наконец-то можно будет передать людям и произвести революцию в создании и потреблении 3D-контента!

Растущий интерес

Мы считаем, что многие крупные игроки осознали: полигональные технологии упёрлись в потолок сложности больше десятилетия назад. Эта проблема проявляет себя множеством способов: в сложных тулчейнах, в хитрых хаках, позволяющих реализовать взаимодействия и симуляцию разрушений, в сложном представлении геометрии (модель полигональной поверхности + модели коллизии + другие модели для представления внутренней структуры, при её наличии), в переусложнённых подходах к волюметрическому видео, хаках и огромных кодовых базах, и т.д. Из-за этих проблем прогресс почти полностью зависит от мощности видеопроцессоров, а некоторые аспекты вообще недостижимы. Это битва, в которой нельзя выиграть. Это свойственно природе больших компаний: часто они даже не пытаются потратить много времени и ресурсов на развитие рискованных и меняющих условия игры решений; вместо этого их стратегия заключается в покупке маленьких компаний, которым это удалось.

Технология

Существует набор техник, которые люди обычно считают основанными на вокселях. Самые старые из них использовался в играх, основанных на картах высот, где рендерер интерпретировал 2D-карту значений высот для вычисления границ между воздухом и землёй сцены. Это не совсем воксельный подход, потому что здесь не используется волюметрический набор данных (примеры: Delta Force 1, Comanche, Outcast и другие).

В некоторых движках и играх используются большие блоки с собственной внутренней структурой, составляющие виртуальный мир (пример: Minecraft). Эти блоки обычно рендерятся с помощью полигонов, то есть наименьшими их элементами являются треугольники и текселы, а не воксели. Такая геометрия просто упорядочена в сетку из более крупных блоков, но это, строго говоря, не делает их вокселями.

Источник

Воксел

Из Википедии — свободной энциклопедии

Во́ксел (в разговорной речи во́ксель, англ. Voxel — образовано из слов: объёмный (англ. volumetric ) и пиксель (англ. pixel )) — элемент объёмного изображения, содержащий значение элемента растра в трёхмерном пространстве. Воксели являются аналогами двумерных пикселей для трёхмерного пространства. Воксельные модели часто используются для визуализации и анализа медицинской и научной информации.

В компьютерной графике воксели используются как альтернатива полигонам. Новички иногда ошибочно считают воксели заменой для физических пикселей (элементов матрицы дисплея). На самом деле под вокселом обычно понимается виртуальный элемент, соответствующий набору из шести прямоугольных полигонов. Всё в виртуальном мире — виртуальные пиксели, полигоны и воксели — должно быть спроецировано на пиксели физического экрана: [ источник не указан 782 дня ]

То есть в отличие от полигонов и пикселей, воксели — это истинный 3D кирпичик, а не 2D плоскость, которая «окружает» пустое 3D пространство. [ источник не указан 782 дня ]

Моделирование в виртуальных пикселях уже почти не встречается в производстве 3D графики. Сейчас при 3D моделировании объекты часто создают в основном только двумя способами:

Ввиду того, что полигональные модели пусты по своей природе, очень трудно моделировать их поведение в 3D мире. Например, если программисту нужно смоделировать поведение воды в 3D игре про пиратов, он сталкивается с проблемой: как смоделировать волны на поверхности воды? Как моделировать всплески воды, ведь вода в игре — это просто ковёр, сплетённый из треугольников голубого цвета, под этой плоскостью ничего нет, а между тем нужно показать пенящуюся и плескающуюся воду. То есть надо показать отделение частей воды друг от друга в виде пены и всплесков. Приходится вводить новые объекты в память компьютера, а управление этими дополнительными объектами требует большого искусства именно от программиста, а не от дизайнера. [ источник не указан 782 дня ]

Если же воду моделировать через воксели, то всё становится гораздо проще, ибо вся вода от поверхности океана и до дна состоит из «атомов», которые легко «отделяются» друг от друга естественным, с точки зрения программиста, путём. [ источник не указан 782 дня ]

Источник

Семь программ для работы с воксель-артом Статьи редакции

Редакторы для десктопных и мобильных платформ.

Платформа для рекомендаций сервисов, программ и иных продуктов Slant собрала список наиболее удобных и полезных воксель-редакторов. Этот топ был сделан на основе пользовательских оценок и комментариев. Мы выбрали самую важную информацию, которая поможет сделать выбор. А также дополнили этот список.

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

К тому же многие инструменты покажутся знакомыми пользователям, у которых есть хотя бы небольшой опыт работы с другими программами, например, Blender или Unity. Благодаря этой особенности снижается необходимость в туториалах — процесс знакомства с редактором проходит легко.

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

До недавнего времени основным недостатком программы считался небольшой максимальный размер поля — 128х128х128 вокселей. Но в 2020 году разработчики MagicaVoxel исправили это и увеличили порог до 256х256х256.

MagicaVoxel — бесплатная программа. Также её можно запустить через облачный сервис rollApp прямо в браузере.

Пользователи отметили, что Qubicle обладает удобным и понятным интерфейсом. Также в редакторе присутствуют все необходимые настройки для работы с вокселями, цветом и материалами.

Модели можно экспортировать во множество форматов — FBX, OBJ, STL, Collada, Minecraft Schematic, а импортировать в: VOX, KV6, Paint3D, BINVOX, Minecraft Schematic, RAWVOX, TIF, PNG, JPG, GIF, BMP. Один из главных недостатков — отсутствие камеры с линейной перспективой. Также отсутствует поддержка Linux.

Это платная программа (в Steam — 419 рублей), но существует и бесплатная версия с ограниченным набором функций.

Тем не менее пользователи жалуются на технические проблемы VoxelShop — вылеты программы и частые баги.

Goxel — воксельный редактор, который доступен как на десктопных платформах — Windows, Mac, Linux (везде бесплатно), так и на мобильных — iOS (ограниченная версия без возможности сохранять и экспортировать модели доступна бесплатно, полная стоит 4,99 доллара), Android (429 рублей).

Пользователи отмечают, что у программы простой и понятный интерфейс, в котором не нужно слишком долго разбираться. Также Goxel поддерживает Apple Pencil в версии для iOS.

Voxel Max — редактор, который доступен только на iOS. Сейчас проходит публичное бета-тестирование, поэтому открыт бесплатный доступ к приложению. Рендеринг происходит в реальном времени, поэтому все изменения освещения и материалов видны моментально. Поддерживает Apple Pencil.

VoxEdit — воксельный редактор, главная особенность которого заключается в наличии инструментов для анимирования моделей. Сейчас доступна бета-версия для Windows и Mac.

Voxel Canvas — простой онлайн-редактор, который можно запустить прямо в браузере. Тем не менее в редакторе неудобный интерфейс, ограниченное количество инструментов, а также встречаются баги. Но это отличный вариант сиюминутно попробовать работать в воксельной технике.

Пользователи Slant больше всего оценили MagicaVoxel за понятный интерфейс и широкий набор функций. Также стоит отметить Goxel за то, что он представлен на большом количестве платформ — и десктопных, и мобильных. Другой редактор, заслуживающий дополнительного упоминания — VoxEdit, в котором доступна возможность анимирования моделей.

А какие воксельные редакторы вы используете в своей работе и творчестве? Поделитесь своим опытом в комментариях.

не слишком распространён в 2д-графике, наверное 😂

@Владимир Семыкин ну исправь уже, ну. Перед пацанами неудобно же

obj Это относительно молодой тип, который только недавно начали использовать крупные компании.

Спасибо большое!
Пример с собором поражает воображение. Я с ходу даже не понял, что это воксельное.

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

А какой самый лучший вариант из представленных?

Только Магика, остальное даже пробовать не стоит, поверь мне.

Я пользуюсь MagicaVoxel для создания моделек и Light Tracer для получения красивой 2д-картинки с отражениями и тенями

«А какие воксельные редакторы вы используете в своей работе и творчестве?»

Гудини,без всяких приколов.
Уделывает все эти специализированные казалось бы под воксели редакторы.)

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

Ты понимаешь в чём твоя ошибка в оценке преимущества «наиболее удобных и полезных воксель-редакторов»?
Заметь,не только для скульптинга.
Несколько ты однобоко подошёл,с позициии весьма примитивной задачи-статичной модельки я так понимаю.
Если хочешь,давай устроим некий батл.
Вводные-мячик падает на поверхность,деформируясь отталкивается наследуя цвет вокселями от это поверхности по градиенту какому-нить.
Запишем оба видео,рассмотрим преимущества.)
Или предложи свой вариант,который по-твоему мнению позволит продемонстрировать преимущества твоего редактора. ред.

Ну ты рассуждаешь сугубо с позиции пайплайна повоксельного скульптинга.
Для некоторых такая концепция в целом сомнительна,особенно таким пожилым и ленивым уже как я.
И тут же приводишь в пример Блендер,хотя некорректо с ним сравнивать по удобству,потому что у Блендера все плюсы процедурности Гудини отсутствуют.
Туда же к Блендеру можно закинуть и Майку и Синьку,в них тоже есть свои вокселайзеры или можно собрать аналогичный сетап.
Но нативные или какие-то сторонние скрипты вокселайзеры захардлочены в функционале.
Появилась у тебя задача,например снести в массиве воксели по какому-то паттерну(цветовому например),ты это будешь делать ручками.Это частный момент,таких в процессе реальной работы в плане оптимизации может всплыть много.
Это я не рассматриваю ещё комплексную какую-то задачу которую ты можешь сделать в одном редакторе-процедурно все сгенерить:террейн,потом раскидать деревья по какой-то экосистеме.Или сгенерить кучу разных воксельных машинок параметрически с разными характеристиками.
Про анимацию вообще молчу,рандом пример-Pixels.
https://www.fxguide.com/fxfeatured/pixels-thinking-outside-the-voxel/
Как бы ты реализовал всё это в той же Магике,покадрово?)

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

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

Ты еще предложи свой редактор запилить.Воистину нужда в имплементарности как оценка юзабельности обывателем,ребёнком например.)

Ты мне свою работу привёл в пример как что?
Что в ней выдающегося кроме потраченного времени.
Ты хочешь объём работы с линейной сложностью и простыми микроэлементами в сермате выдать за оценку скорости и удобство работы в отдельном софте?
Так в ней ничего нет кроме твоего задротства и тем более удобство конкретной программы в динамике никак не прослеживается.
Не юродствуй,запиши как моделишь отдельный элемент по сложности укладываемый в час и покажи.
А я продублирую.
Потом поменяемся ролями.
Всё просто. ред.

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

Я за 25 лет что 3д занимаюсь мог оценить плюсы разнообразных пакетов.Ковырял и некоторые из статьи выше.
Мне ноды не страшны,5 лет как из Майки свалил и с лихвой их оценил преимущества(хотя и до этого в ней игрался в процедурность в SOuP),могу рассуждать о плюсах в сравнении адекватном.
Ты бойся лучше когдя я тебе свой «домик» выкачу за час,а не рассуждай сколько я твой буду моделить.)

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

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

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

Мне кисточка не ненавистна.
Я тупо вижу когда лучше применить тот или иной инструмент.
Тоже сгенерю.
У тебя вариативность у пропсов зависит от времени на отдельный оный,а у меня от времени что я потрачу на ассет что будет рандомные такие генерить в неком рейндже.
В итоге наступит момент финальный когда мне клик на генерацию нового диска подобного твоему понадобится,отличного от предыдущего.А ты будешь с нуля корпеть.) ред.

Ладно, удачи продолжать забивать гвозди микроскопом и кичиться этим в комментах.

Ок,и тебе удачи,я тебе желаю придти к процедурности в тех моментах где не надо играть в «художника».

А можете чуток поподробнее? можно ссылку на тутор

Надо 4 ноды ключевых зарюхать всего.
1)Points from Volume,2)Copy to Points,3)Attribute from Map,4)Attribute Transfer

Помню пользовался MV и он вызывал у меня проблемы. а он был самым легким

Источник