Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Unlimited Detail (215 стр)

Unlimited Detail (215 стр)

Поделиться

Страницы: 1 2 3 4 ... 108 ... 214 215 216 217 Следующая

SuslikМодераторwww11 янв. 201523:00#3210
видео же выкладывай. можешь отдельную тему создать в разделе "утилиты" или "проекты".
EyeGemПостоялецwww12 янв. 20151:56#3211
Видео будет позже, пока только демка.
kvakvsПостоялецwww12 янв. 20152:25#3212
Попробовал прикольно.
Не найду чтото исходников самого демо. Ну не срочно, конечно, я сразу не брошусь что-нибудь там править, но зацепило, молодец :)
EyeGemПостоялецwww12 янв. 201510:43#3213
Спасибо.

Исходники самого демо внешние т.е. просто используют код pwtech.
В качестве примера могу выложить, но они не будут собираться без моего framework'а (в отличие от pwtech).
Думаю, сделаю отдельный проект и перенесу код демо туда.

Обнаружил два бага:
1) если файл e2.pwt "холодный", то подгрузка (в том же потоке) сильно убивает fps (сразу после unzip'а файл ОК)
2) изредка падает когда воксели слишком близко (проблема clipping'а)

ExecutorУдалёнwww5 мар. 20151:08#3214
Как там дела с этим UD? Уже почти 5 лет скоро будет как обещали сделать графоний в сто тысяч раз круче чем в играх и убить растеризацию окончательно.
В Вики написано, что мол игры пилят...
WISHMASTER35Участникwww12 мар. 201523:55#3215
EyeGem
> Алгоритм выполняет поиск (search) нужных нод дерева путём обхода дерева в
> сортированном порядке front-to-back (sorted order)
А сортируются они по расстоянию до позиции камеры или по расстоянию до near plane камеры? Т.е. с учетом перспективы?
EyeGem
> Плюс отдельно, скажем, вспомогательные таблицы предрасчитанных сумм битов для
> блоков.
EyeGem, ты так и не рассказал для чего эта таблица. И о каких блоках ты говоришь?
Я так понимаю дочерние ноды для ускорения хранятся в виде протсо 3д массива?
EyeGem
> При этом, думаю, оно и для чего-нибудь типа voxel cone tracing radiosity
> подойдёт.
Ах если бы. Но если бы можно было бы, то уже сделали бы.
Хотя, если алгоритм позволяет перебирать ноды в сортированном порядке по расстоянию до точки, а не плоскости, то возможно и можно применить этот алгоритм для Light Gathering. Еще бы отбрасывать невидимые ноды)

Правка: 13 мар. 2015 0:51

d.m.kУдалёнwww13 мар. 201516:38#3216
Executor
> В Вики написано, что мол деньги на игры пилят...
fixed
EyeGemПостоялецwww15 мар. 20155:42#3217
WISHMASTER35
> А сортируются они по расстоянию до позиции камеры или по расстоянию до near plane камеры? Т.е. с учетом перспективы?

С учётом перспективы, естественно, иначе occlusion culling неэффективно будет работать.
И не сортируются они, а просто перебираются в нужном (сортированном) порядке.

WISHMASTER35
> ты так и не рассказал для чего эта таблица. И о каких блоках ты говоришь?

Таблицы предрасчитанных сумм битов зачем?

Ну, например, у тебя 30 млн. битов в слое данных, они сгруппированны по 8 бит на ноду, но это не столь важно.
Чтобы вычислить индекс начала байтов чилдов в следующем слое данных нужно подсчитать количество бит равных 1 до позиции N.
Допустим, N = 29100500 для наглядности ;)

Есть два варианта:
1) цикл подсчёта бит равных 1 на 29100500 итераций (если словами, то 29100500 / 16 = 1818781 слов + 4 бита)
2) подсмотреть в таблицу сумм бит по индексу = 29100500 / 8 бит в байте / размер блока таблицы в байтах (пусть будет 256) = 14209; полученная сумма[14209] будет для начала блока бит (14209 * 8 * 256 = 29100032), далее циклом проверяем на равенство 1 оставшиеся 468 бит до позиции 29100500 (если словами, то 29 слов и ещё 4 бита) и прибавляем к сумме, получая тот же результат что и в первом варианте (сумму бит для N=29100500)

Тупо первым способом, как понимаешь, для больших N считать, мягко говоря, очень медленно и неэффективно.
А второй способ практически сводит максимальное время получения суммы до худшего случая, когда нужно проверить дополнительно 256 байт в блоке * 8 бит в байте - 1 = 2047 бит.

Замечу также, что искать чилдов нужно не на каждом кадре, а только когда выполняется подгрузка данных т.к. уже загруженные (активные) ноды в памяти хранятся НЕ в формате linkless octree.

Вообще читай код, там всё есть ^__^

EyeGemПостоялецwww15 мар. 20155:54#3218
Кто не видел, статья в четырёх частях по реализации версии алгоритма: http://ecstatica2.livejournal.com/44936.html
Оптимизации, а именно ортохак и группировка нод в cache-friendly блоки, там не рассматриваются.
ВийЗабаненwww15 мар. 201513:08#3219
EyeGem
> Оптимизации, а именно ортохак и группировка нод в cache-friendly блоки, там не
> рассматриваются.
А зачем она тогда вообще нужна ?
Единственное, чем интересна Unlimited Detail - это оптимизациями
glukhПостоялецwww15 мар. 201514:41#3220
шевеление по теме! респектую! :) (ЗЫ твёротельный растеризатор обкакался - идея не рабочая, новая есть но сырая что писец, так что сории - темп даун)
WISHMASTER35Участникwww15 мар. 201515:24#3221
EyeGem
> Замечу также, что искать чилдов нужно не на каждом кадре, а только когда
> выполняется подгрузка данных т.к. уже загруженные (активные) ноды в памяти
> хранятся НЕ в формате linkless octree.
В SVO ноды и листья занимают одинаковое количество памяти, там проще вычислить начало следующего уровня. Впрочем подгрузка мне пока не нужна.
> хранятся НЕ в формате linkless octree.
А в каком еще формате можно хранить? Обычно каждый нод имеет индекс на дочерний child или child tile. Это и есть linkless.

Кстати, у меня есть идея как это перенести на видеокарту.
Можно просто разделить экран на несколько частей и рендерить каждую часть отдельно. В DX11 есть возможность писать в рандомный тексель текстуры. Так что должно все работать.

Есть идея как совместить эту технологию с Voxel Cone Tracing.
- Перебираем все ноды в порядке удаления от точки начала конусов;
- Определяем lod по расстоянию до этой точки;
- Определяем попадает ли нод в полусферу.
- Определяем в какой конус попадает нод;
- А дальше освещаем этот конус так же как и в VCT.
В результате каждый нод обрабатывается строго один раз. При трассировки конусов можно пропустить нод или несколько конусов попадут в один и тот же нод.
И структура октри будет проще т.к. для трассировки конусов надо, чтобы каждый нод хранил индексы на соседние ноды.
Но будет ли такой перебор быстрее, чем трассировка 16 конусов, я не знаю.

Правка: 17 мар. 2015 18:05

WISHMASTER35Участникwww17 мар. 201518:32#3222
Не, с VCT это вряд ли совместишь.
В результате каждый нод обрабатывается строго один раз.

В этом и проблема. Нод может перекрывать несколько конусов. Поэтому и обрабатываться должен для каждого конуса, а не для одного.
Разве для каждого конуса пускать этот алгоритм. Но боюсь это уже будет очень медленно.

Но все же, раз начал, то хочу копнуть глубже.
EyeGem, как делается front-to-end перебор нод?
Думаю по вектору направления надо вычислить к какой (из 8) частей ноды ближе позиция камеры?

+ Показать

Но как это реализовать без кучи if'ов не знаю.

ZvzПостоялецwww24 мар. 20150:54#3223
eyegem'y ++

если кто еще не видел http://www.youtube.com/watch?v=DbMpqqCCrFQ

ZvzПостоялецwww10 апр. 201523:22#3224
"теперь и в браузере"
http://udserver.euclideon.com/demo/

судя по шлейфам при резких сдвигах без обсуждавшейся Вием репроекции с предыдущих кадров не обошлось. ;)

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

Правка: 11 апр. 2015 0:28

Страницы: 1 2 3 4 ... 108 ... 214 215 216 217 Следующая

/ Форум / Программирование игр / Графика

2001—2017 © GameDev.ru — Разработка игр