Войти
3DTetraWavesФорумОбзор существующих алгоритмов

Воксельная графика (3 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 4 Следующая »
#30
18:49, 26 окт. 2012

Dag
Честно говоря, порылся я по тому блогу, и увидел вот такую надпись там:

The demo uses the VOXLAP engine by Ken Silverman.
Because of the limitations of the VOXLAP engine, Hans Krieg decided to create a new engine from scratch.
Hans Krieg stopped working on the engine in June 2, 2011. Now I am stuck with an unfinished engine and a ton of content.
But I'm still getting help and support, so there's still hope in all this madness.

То есть, по сути, используется как основа Voxlap, который серьезно допилен неким Гансом Кригером (я не думаю, что Ганс Кригер все абсолютно с нуля начал писать). Но автор перестал его делать, а автор блога смог получить исходники сего чуда, и развлекается с ним, стараясь в нем разобраться и что-то делать интересное. Не столь хорошо, как думалось в начале, но и не столь плохо.

#31
18:59, 26 окт. 2012

Vismar
Ага, даже солдатики из вокселей и разрушаемые! Как к ним приделали скелет, интересно

#32
19:24, 26 окт. 2012

Aslan
Честно говоря, все никак не решусь посмотреть в исходниках voxlap`а этот момент. Там просто отдельно вынесена эта вещь(анимация воксельных моделей), но с учетом того,как писался Кеном этот движок... Желания туда лезть почти никакого, так как каждый раз, когда туда залезаю, чувствую себя в жутчайших дебрях чужого кода, понятного, во многих случаях, только самому автору.

#33
21:18, 26 окт. 2012

Vismar
То, что Кен Силверман уже сделал наследника Вокслапа мне удалось узнать от него самого. Так как никто не хотел попробовать некие нелепо часто упомянутые алгоритмы, я их предложил ему (он ведь супер-программист). К сожалению, неэффективность моей реализации угасила его интерес. Неужели они теоретически неприемлемы? (Да, слишком рано дробятся фрустумы на плоскостях в середине кубов).
> чувствую себя в жутчайших дебрях чужого кода, понятного, во многих случаях, только самому автору.
+

#34
21:51, 26 окт. 2012

Dag
На счет дробления фруструмов я видел что-то интересно в доках Giga Voxels. Да и не только дробление фруструмов там интересное =)
Честно признаться, не очень разбирался в тех алгоритмах, что ты писал. Так как нечто подобное уже видел. Вообще, как по мне, рендерить воксели все же стоит рей трейсом, по причине того, что картинка от этого способа получается просто великолепная. Хоть это все дело и жрет неимоверное количество ресурсов, но что поделать. Это все дело оптимизируется всяческими kd деревьями, октодеревьями и прочее. Я, к сожалению своему большому, пока в этом всем деле плохо разбираюсь (занимаюсь больше хранением геометрии, а сейчас перехожу к сжатию цветов, ну там и геометрию еще сжимать буду тоже).

#35
11:32, 27 окт. 2012

Vismar
Кинь ссылку про дробление фруструмов. Я так понял речь о трассировке пирамидами?

#36
12:26, 27 окт. 2012

http://maverick.inria.fr/Publications/2011/Cra11/
Там есть ссылка на загрузку .pdf, в нем описано многое, там и есть разбиение фруструмов. Надеюсь,поможет.

#37
12:32, 27 окт. 2012

Vismar
Спс

#38
12:39, 27 окт. 2012

Не по теме, но классно!
http://sfw.org.ua/1149006322-stereografichnye-risunki-dain-fagerholm.html

#39
12:48, 27 окт. 2012

Aslan
Недурственно!

#40
23:44, 1 мар. 2013

Прошло более 9 месяцев
#41
9:34, 17 дек. 2013

Хочу рассказать идею, думаю реализовать её возможно:
Суть её в том, что воксели бесцветны - они либо есть, либо их нет. Т.е. упрощёнка хранения вокселей, дискретное состояние.
Это позволяет сократить объём в разы, т.к. пустоты описываются уже не вокселями - координаты дискретного 0 можно не хранить, они заполняются автоматически.
И того мы храним только те воксели у который дискретное состояние 1 (это состояние мы используем вместо цвета).
картинка обозначение | Воксельная графика
На картинке я нарисовал квадратик (я кэп очевидность) и поделил его на 9 частей.
Предположим, что это одна из сторон куба, видимая нам - т.е. наблюдателям. Куб состоит из вокселей "x"
Теперь главное: все "x" являются полностью индеитичными, и уникальных среди них нет, причина известна: воксели либо есть, либо их нет, никакой информации о прозрачности и цвете они не несут. Следовательно весь куб мы можем описать дискретным состоянием (есть/нет), вместо того, чтобы хранить воксели данного куба.
Для удачной реализации идеи необходимо использовать SVO. Каждый узел дерева хранит дискреную информацию о том, заполнен его лист, или нет - колличество вокселей как и объём информации который они несут, соращается на порядки.

Но есть и минусы:
- необходимо хранить текстуру (не будем же белым рисовать воксели), её координаты
- при большом количестве мелких деталей объем многократно увеличивается (впрочем не критично)

#42
10:37, 17 дек. 2013

Odin P. Morgan
> Но есть и минусы:
> - необходимо хранить текстуру (не будем же белым рисовать воксели), её
> координаты
> - при большом количестве мелких деталей объем многократно увеличивается
> (впрочем не критично)
- Исчезает 1 из главных причин использования вокселей, динамическое изменение.
То есть да, мы можем менять геометрию, при том ОЧЕНЬ быстро и легко,всего-то парой-тройкой битовых операций. Но херня вся в том, что нам тогда надо либо хранить текстуру(что идентично хранению цветных вокселей), либо же динамически генерировать. Ну тут сам понимаешь, в чем проблемы. В целом же проблема стоит даже не в том, как хранить воксели. Это не так сложно, да и, вполне, решаемая проблема. А вот то, как воксели БЫСТРО рендерить в большом количестве... Вот это уже очень трудный вопрос.

#43
9:31, 18 дек. 2013

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

Прошло более 1 года
#44
16:20, 23 янв. 2015

Сорри за небольшой оффтоп.
Объясните тупому, как реализована воксельная графика в таких движках как id tech6 или CryEngine? Ведь современные видеокарты заточены только под D3D и OpenGL а значит под полигональную графику, только полигональную графику они могут ускорять, т.е. оперировать на GPU только теми данными которые связаны с полигонами, нормалями, вертексами и т.д.

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

Так как заставить GPU выполнять другие этапы кроме последнего (фрагментный этап - он вообще должен присутствовать всегда)?

GPGPU? А дальше, как быстро определить цвет каждого пикселя на экране аппаратно?

Страницы: 1 2 3 4 Следующая »
3DTetraWavesФорумОбзор существующих алгоритмов

Тема в архиве.