Продолжаем отвечать на вопросы по технологиям.
Сегодня поговорим о вокселях.
Слово воксель - voxel - образовано от слова VOlume и аббревиатуры piXEL (pixel, расшифровывается как PICture'S ELement, элемент картины). То есть, переводится как "элемент объемного изображения" или "элемент объема изображения".. Обычно это шар или куб.
Не стоит приписывать пикселу и вокселю равносторонность. Это удобно, не более того. Иногда даже удобнее считать воксель неким параллепипедом - например, в карте высот.
Что есть ВоксельКак работают воксельные движки
Давайте попытаемся разобраться, как именно воксельный движок создает трехмерный ландшафт. Вначале берется плоская картинка (как будто мы сфотографировали кусок земли сверху) и так называемая "карта высот" (heightmap) - массив данных, в котором хранятся значения высоты для каждого пикселя нашей картинки. Теперь движок в состоянии превратить плоский пиксель в трехмерный воксель. При этом - чем точнее будет наша карта высот, тем реалистичнее будет наш трехмерный ландшафт. И наоборот, если взятая карта высот будет слишком неточной (скажем, сможет хранить лишь десять различных отсчетов по оси Z), то финальная картинка получится весьма угловатой (так называемый эффект лесенки).
Окружающий нас мир изобилует мельчайшими деталями. Поэтому в воксельных движках используются специальные технологии, улучшающие качество heightmap низкого разрешения. Два наиболее распространенных способа основаны на диаметрально противоположных алгоритмах: первый добавляет множество новых отсчетов в карту высот, используя псевдослучайные карты смещения (displacement maps), второй сглаживает угловатости, получая новые значения по оси Z путем интерполяции между существующими.
К этому моменту наш движок вполне может построить трехмерный скелет кусочка земли. Осталось лишь найти цветовую карту (color map) и покрасить верхний слой вокселей всеми цветами радуги. Для этого потребуется обыкновенная плоская текстура. Теперь, если ставить кубики-воксели друг на друга и присваивать самому верхнему определенный цвет, рано или поздно можно добиться желаемого результата. Впрочем, результат мы получим скорее поздно, нежели рано, ибо движок наш выполняет слишком много ненужной работы. Человечество еще не научилось видеть сквозь предметы, поэтому глаза наши фиксируют только верхний слой кубиков и даже не задумываются о том, что под всем этим кроется груда вокселей, каждый из которых рендерил наш трудолюбивый движок. Чтобы избавить его от лишней работы, конечный рендеринг использует технологию трассировки лучей. Несмотря на громоздкое название, ничего сложного в ней нет.
Представьте себе невидимый луч, испускаемый из вашего глаза на определенную точку экрана. Проходя через экран монитора, луч попадает в наш виртуальный мир и продолжает двигаться в пространстве до тех пор, пока не натолкнется на какой-либо объект. Допустим, этим объектом стал красный кубик. Теперь глаз знает, что в этой точке экрана находится нечто красное. Просмотрев весь экран, глаза формируют полную картинку и скармливают ее мозгу. Ну, не совсем так, но вряд ли офтальмологи будут читать эту статью.
Движок наш с офтальмологами не знаком, поэтому считает, что человеческий глаз работает именно так, как описано в предыдущем абзаце. И поэтому рендеринг финальной картинки методом трассировки лучей происходит следующим образом: нашли самую нижнюю координату в карте высот, выпустили туда луч, натолкнулись на какое-нибудь препятствие, считали значение в карте цветов, покрасили пиксель и поднялись на один пиксель повыше. Снова пустили луч, натолкнулись на что-то твердое и т. п. Интересно, что и на этом этапе можно немножко ускорить работу движка, слегка изменив алгоритм. Предположим, пущенный луч уперся в стенку красного кубика, причем в самый низ. Следующий по счету пиксель сверху тоже будет красным, и что самое важное - будет иметь те же координаты по осям X и Y. Зачем же, спрашивается, пускать еще один луч от самого "глаза", если можно сначала подняться наверх и посмотреть, что там такое. Если стенка, то сразу ее покрасить, и снова наверх - до тех пор, пока на свежий воздух не выберемся, сиречь ничего не найдем. Вот тогда и новый луч выпустим. Недостатков у такого подхода никаких - сплошная экономия времени.
Если воксельный движок написан без глюков (а они такие), то рано или поздно луч упрется в пластмассовый ободок монитора, а на экране появится очередной кадр. Потом все начнется с самого начала, но повторение, хоть и мать учения, но совсем не повод писать еще два-три абзаца с кратким пересказом предыдущих двух-трех абзацев.
Воксели это гораздо более реалистичный подход к представлению трехмерной модели на экране монитора чем полигоны. Просто так уж случилось что в пору зарождения 3D, производители аппаратных частей, в частности 3D акселераторов, избрали технологию полигонов а не вокселей.
Может быть если бы тогда все получилось иначе, сейчас бы мы играли в полностью воксельные игрушки и интересовались поддержкой полигонов.
Что есть ВоксельСейчас на рынке представлено совсем немного игр с воксельной графикой: как пример C&c Tiberian Sun (на скрине сверху), Периметр от Российских разработчиков, но чаще воксели используют в авиасимуляторах. Однако уже существуют игры, сочетающие в себе как полигональную, так и воксельную графику (первыми такое проделали создатели Zar). И результат получается прямо-таки великолепный: красивые детализированные ландшафты и аккуратненькие модели с цветным освещением.
Так что будущее, как мне кажется, именно за таким вот симбиозом. Но это зависит от крупных магнатов, производителей "железа". Многие считают технологию тупиковой и устаревшей.
Добавление №1 Взято с
Новый Воксельный движок (Острожно! Много умного текста)
Описание
В движке будет использоваться инновационная технология «Sparse Voxel Octree» (SVO, русск. Разреженное воксельное октодерево). Геометрия игрового уровня, поддерживаемая этой технологией, будет иметь не полигональную, а воксельную геометрию, т.е. геометрические объекты будут состоять из вокселей. Воксели будут сохраняться в октодереве. Для освещения будет использоваться технология рейкастинга (англ. raycasting, бросание лучей). Одна из целей технологии «SVO» состоит в том, чтобы иметь возможность «подгружать» части октодерева в графическую память (видеопамять), идя вниз вдоль ветвей дерева. Это значит, что объекты на нижних ветвях октодерева, т.е. те объекты, которые расположены к наблюдателю ближе всего, будут рендерится в максимальном качестве, с максимальной детализацией и текстурами максимального разрешения. Соответственно, для дальних объектов, которые расположены на более высоких ветках октодерева, будет использоваться меньшее качество, они будут построены на вокселях больших размеров. Таким образом, данная технология является способом контроля уровня детализации (англ. level of detail — LOD).
Геометрические объекты, полученные благодаря SVO, теоретически могут иметь неограниченное число уровней детализации, более того, данные уровни детализации генерируются автоматически. Это устраняет потребность в использовании разных псевдотрёхмерных методик типа параллакс-маппинга. Тем не менее, все тесты с использованием SVO нуждаются в большом количестве памяти (вплоть до нескольких гигабайт). Йон Олик заявил, что является возможным сжатие такого SVO до уровня 1,15 битов на один воксел.
В id Tech 6 с помощью SVO будет рендериться только статическая геометрия, например ландшафт, строения и т.д. Также из-за этого рейкастинг-освещение также будет статическим. Все динамические объекты типа персонажей, транспорта и т.д. будут «построены» на классических полигонах и динамически освещаться с помощью стандартных растеризационных методик. Олик заявил, что создание динамических объектов и динамического освещения с помощью SVO возможно, однако это потребует быстрого обновления октодерева для рендеринга. Согласно Олику, динамические освещение и геометрия, представленные SVO, которые позволят создавать изменяемую геометрию, будут присутствовать в id Tech 7.
Кроме SVO, id Tech 6 будет использовать более продвинутую технологию мегатекстуры, которая впервые использовалась ещё в id Tech 4. При помощи данной технологии вся поверхность уровня покрывается одной текстурой.
Разработчики id Tech 6 и SVO ориентируются не на текущее аппаратное обеспечение, а на аппаратное обеспечение, которое на момент начала разработки ещё не доступно. В частности, id Tech 6 ориентируется на CUDA, Intel Larrabee и AMD Fusion. Также Кармак заявил, что если игровые консоли следующего поколения (наследники Xbox 360 и PlayStation 3) будут иметь такие аппаратные спецификации, которые будут удовлетворять архитектуре движка, то, возможно, id Tech 6 будет работать и на этих консолях.
Согласно Олику, на видеокарте GeForce GTX 280 при стандарте 720p (1280х720 пикселей) id Tech 6, возможно, сможет «выдавать» 60 кадров/сек. При этом движок стабильно будет «выдавать» не менее 30 кадров/сек.В интервью сайту PC Perspective на вопрос о том, каким должно быть и на сколько должно измениться аппаратное обеспечение, чтобы быть подходящим для SVO, Кармак ответил следующим образом: «Аппаратное обеспечение, спроектированное специально для SVO, может быть намного меньше, проше и эффективнее, чем средства общего назначения, но никто, кто находится в здоровом уме, не захочет сделать ставку на нашу технологию и не захочет создавать специфическое аппаратное решение для технологии, которую ещё не использовал ни один разработчик».
25 мая 2009 года id Software показала немецкому сайту GameStar.de видео-демонстрацию id Tech 6, на которой демонстрировалась модель гуманоидного монстра, созданная с использованием технологий id Tech 6. ()
