Войти
ПрограммированиеФорумГрафика

Проблема с усечением Frustum области другим Frustumом (7 стр)

Страницы: 13 4 5 6 7 8 Следующая »
#90
18:26, 12 фев. 2021

Я сбрасывал это видео когда-то на этот форум, но сброшу еще раз
https://www.youtube.com/watch?v=kcxONrduNs8

А аффтару хочу посоветовать решать эту проблему в world space'е вместо Screen Space'а


#91
18:55, 13 фев. 2021

Aslan
> У тебя портал - любая открытая линия между секторами?
Не совсем, у меня портал - это массив линий, смотрящий в один и тот же сектор, но в большинстве случаев да, одна линия - один портал.

> Рендер или что?
Сам алгоритм проверки видимости. Этот алгоритм работает в среднем от 0.01мс (для пары видимых линий) и до 0.5мс на закрытых не больших пространствах (но их в игре большенство)
На открытых пространствах, конечно, побольше - до 3-5мс, особенно в проблемных местах, о которых я писал выше, там алгоритм может завершиться и через 15-20мс (т.к. просчитывает много лишнего и ненужного как видимое)

> Есть демка погонять?
Нет, но я скомпилил бинарник, с которым сам работаю (поэтому там нет юзер-френдли интерфейса)

Загрузил бинарник сюда:
http://m210.ucoz.ru/Files/RenderGDX.jar (10мб)
Помимо самого файла понадобятся файлы движка и ресурсы Duke3D
tables.dat
palette.dat
все ART файлы и карты...желателен lookup.dat (для правильного отображения текстур с цветной палитрой)

Прога будет пробовать загрузить E1L1.map, если загрузит, далее можно будет нажимать на Enter и переходить на следующую карту.

Навигация WSAD + QE. на R можно вывести рисование всей карты, тоже самое будет происходить при вылете за границы карты.
"1" - основной 3D экран
"2" - экран с рисованием без текстур линиями, можно видеть что рисуется в данный момент
"3" - экран с видом сверху, аля 2D

на "9" можно включить 2ю камеру, а этом режиме на "F" будет выводиться фрустум камеры 1й  камеры.
на 0 выключается мышь (это мне для дебага)
в режиме 2й камеры на "8" можно включить управление 1й камерой


Deamon
> А аффтару хочу посоветовать решать эту проблему в world space'е вместо Screen Space'а
Я тоже себе это советую, но пока не получается :)

#92
(Правка: 8:52) 8:51, 14 фев. 2021

m210
> Сам алгоритм проверки видимости
Одного сектора через портал?
Я пока что не спеша пишу редактор уровней из секторов
Сектора невыпуклые, непересекающиеся, но могут быть вложенные, BSP/Quad-tree ненужно

+ фрагмент ТЗ
#93
10:36, 14 фев. 2021

Aslan
> left mouse down - выделяет вершину или линию...
я так понимаю, тут должен был быть бинарник? :)

#94
10:50, 14 фев. 2021

m210
> я так понимаю, тут должен был быть бинарник? :)
В ТЗ?

#95
10:59, 14 фев. 2021

Aslan
Ок, тогда зачем мне информация, какая кнопка мыши в твоем редакторе за что отвечает?

#96
11:12, 14 фев. 2021

m210
Удобный интерфейс может быть важнее алгоритмов, алгоритмы все уже продумал. А бинарник будет как допишу

#97
(Правка: 15:28) 15:27, 16 мая 2021

m210
У тебя свой редактор карты или Duke-овский?
Интересует алгоритм разбиения на сектора (замкнутые полигональные области, возможно вложенные)

#98
18:11, 16 мая 2021

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

Кстати сканер секторов я дописал...идеи по оптимизации еще имеются, но пока оставлю как есть. Запустил на Raspberry Pi3, выдает от 30 до 60 кадров (там вроде лок на 60 кадров)

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

#99
18:05, 17 мая 2021

m210
Я написал алгоритм разбиения, но слишком сложный

А от чего были тормоза? Мне кажется уровни 1го Duke можно выводить и без оптимизаций

#100
22:04, 17 мая 2021

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

Ну и мне нравится, что с рейкастом у меня максимум 100-200 gl вызовов, а без рейкаста - в легкую переваливает за 1000, а для мобилок 1000 вызовов это уже серьёзная нагрузка.

Но в будущем от рейкаста я думаю можно будет уйти, идеи все ещё есть, но надоело штудировать одно и тоже на протяжении полугода, решил отвлечься написанием другой части рендера.

#101
14:03, 18 мая 2021

m210
У тебя все порталы вертикальные прямоугольники? Если так, можно легко посчитать геометрически.
Хотя помню в Дюке наклонные полы/стены

#102
19:03, 18 мая 2021

Я тоже думал что все легко, и также думали мои конкуренты :) Однако ни у конкурентов ни у меня пока нет идеально работающего варианта. А если считать порталы влоб, без объединения, тогда время алгоритма будет не 11мс, а 110мс - это тоже уже проверено и проверено еще 100+ разных методов.

#103
19:05, 18 мая 2021

Еще я пробовал Occlusion Query, так это вообще дико медленная хреновина, которая будет кое-как работать с запозданием в 1 кадр и я полагаю с проживанием половины памяти видюхи

#104
21:41, 18 мая 2021

Есть не совсем типичный способ решения подобных задач - использовать CSG.

Фрустум - это объемная фигура. Можно из него вырезать другие объемы. Можно вытягивать его для случая, когда нужно найти охваченные объекты тенями. Можно искать пересечение (общее пространство) между двумя фигурами. Возможно для данного случая тоже применимо.

Страницы: 13 4 5 6 7 8 Следующая »
ПрограммированиеФорумГрафика