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

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

Страницы: 1 2 3 4 58 Следующая »
#30
17:39, 9 дек. 2020

Occlusion culling?


#31
(Правка: 10 дек. 2020, 9:01) 18:58, 9 дек. 2020

https://youtu.be/HHLvsFoOwzE

за видео извиняюсь сразу, приходится с руки снимать, потому что не хотят у меня записывать захватичики экранов всё что я делаю с OpenGL
да оно даже здесь не хочет воспроизводится нормально... я заколдован

Это порт Quake II на Delphi.
исходники до сих пор валяются в интернете

Данная версия спокойно запускается, без всяких тормозов и на древненьком Asus Eee PC 900.
FPS не отображается, но изображение достаточно гладкое, чтоб понять, что ни каких заваливаний FPS ниже 30 даже речи идти не может. И не забываем, что Quake  полностью трёхмерен!!!

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

И я не говорю, что не надо ограничивать то, что не попадает в кадр. Я про то, что не всё из этого надо ограничивать!

Всё надо тестировать и смотреть, какие куски кода заваливают FPS, какие объекты дают большую нагрузку. И, вероятно, не надо дальность прорисовки делать дальше, чем "видит глаз"? ))) Потому и делают разумное ограничение дальности прорисовки или меняют стратегию прорисовки дальних расстояний.

m210
> Я сейчас не понял. В выше представленных примерах я показывал карты у которой
> 4000 стен и 1000секторов, при этом на расчет видимости обрабатываются не все
> сектора, а только те, которые видят соседние порталы.
это может быть "двойной обработкой" информации. В первый раз вы обрабатывате информацию сами (просчитываете всё сами) и отправляете данные видеокарте, а второй раз те же данные обрабатывает видеокарта.

#32
(Правка: 19:16) 19:10, 9 дек. 2020

Mirrel
В Quake отсечение полигонов основано не на порталах, а BSP.
BSP (binary space partition), просто разбиение пространства в виде дерева, как иерархия.
Портал - это разбиение пространства в виде графа.
Совершенно разный подход.

#33
19:30, 9 дек. 2020

Funtik, это не означает, что довольно старые методы отрисовки должны сильно сказываться на FPS.

... а вот в трёхмерном пространстве...
почитал про порталы. Если использовать ось Z, то мы должны вводить дополнительные "порталы" для этой оси. И делить не пополам экран, а на 4 части. Лево/право, верх/низ.

тут в чём-то мой недочёт, забываю про разные методы вывода

#34
13:49, 10 дек. 2020

Mirrel

Данная версия спокойно запускается, без всяких тормозов и на древненьком Asus Eee PC 900.
FPS не отображается, но изображение достаточно гладкое, чтоб понять, что ни каких заваливаний FPS ниже 30 даже речи идти не может

А теперь запусти тоже самое, только чтобы карта рендерилась не surfacesами, а каждая стена - индивидуальный drawcall, и получишь то, что получаю я.

Я веду речь о том, что вероятно, движок, который вы используете или который переделали, может по нескольку раз делать одно и то же при чём на разных участках кода.

А причем тут движок, если речь идет о рендере?
Какая рендеру разница, чем занимается движок...не говоря уже о том, что функции движка я вообще не использую сейчас, он мне нужен только чтобы загрузить карту и чтобы вывести картинку по средствам glDrawArray

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

Вот тебе наглядный пример - как это должно выглядеть

Screenshot_20201210_134650 | Проблема с усечением Frustum области другим Frustumом

А вот как это бы выглядело на движке Quake

Screenshot_20201210_134724 | Проблема с усечением Frustum области другим Frustumом

Поэтому я не могу просто взять и втупую вывести все одним мешем и одним каким-нибудь текстурным атласом, как это делает Quake и сравнение тут абсолютно неуместно

#35
14:18, 10 дек. 2020

m210, я думаю мы на разных языках говорим. Потому моё дело дальше не лезть. )))

#36
7:04, 16 дек. 2020

Возможно мой коммент был незамечен, но по-моему ответ очевиден, occlusion culling, не? :)

#37
13:46, 16 дек. 2020

IIIarp
если ты про оклюдер, то нет, occlusion culling - это технология, а occluder - это объект.
Например если перед тобой стоит столб, за которым находится мусорное ведро и ты его не видишь, то столб будет являться оклюдером - строится фрустум от камеры через столб и все что попадает в этот фрустум - не видно.

По поводу конкретно моей темы - у меня пока совсем нет на это времени. Но я убедился, что верхняя и нижняя поверхность фрустума совершенно не работает даже без всяких обрезаний. Поэтому я решил левую и правую поверхности оставить, а попадание точек по Z я буду проверять проецированием пола и потолка каждого портала сектора и обрезать по уровням Y экранных координат. Должно быть быстрее, чем проецирование всех стен и не сильно медленее, чем построение и проверка через 3D фрустум.

Но надо будет проверять, возможно, на следующей неделе появится время

#38
17:00, 16 дек. 2020

m210
Я про технологию :)
Я к тому, что открываешь любую ссылку из гугла по запросу "occlusion culling" и видишь полное описание и порталов и оклюдеров и всего остального с псевдокодом.
И там 100% найдешь ответ какие плоскости юзать, а какие нет и каким образом.

#39
19:59, 16 дек. 2020

IIIarp
Ну это тоже самое, что сказать: чтобы написать игру надо в интернете ввести "игровой цикл" и готово :)
И occlusion culling и portal culling все же разные вещи. В любом случае я уже определил себе цель и путь к ее достижению, осталось найти на это время. А потом буду проводить оптимизацию, а то как оказалось raycasting достаточно тормозной алгоритм по сравнению с frustum culling ом

#40
(Правка: 11:23) 11:21, 25 янв. 2021

Всем привет!

Наконец-то появилось немного времени, чтобы продолжить ковырять "создание" фрустумов.
Для лучшего понимания процессов, написал метод рисования фрустума...на скриншоте показан фрустум синего сектора, который состоит из 5 стен (но визуально "дырка" одна)

В общем решил я попробовать строить верхнюю и нижнии поверхности по двум ближайшим к камере точкам и на первых двух скриншотах можно увидеть, что такой способ для выпуклой геометрии работает - фрустум охватывает все стены своего сектора. Далее, я решил облететь сектор и построить фрустум через вогнутую геометрию, ну и ничего не срослось (см 3й скриншот), т.к. выходит, что плоскости нужно строить не по ближ. точкам к камере, а по спроецированным на экран точкам, тем, что ближе к вехней и нижней границам экрана (т.е. при разрешении 640х480, нужно брать точки, которые ближе к 0 и 480 на экране) - в итоге во фрустум не попадают все стены сектор.

Неужели нельзя обойтись без медленных проецирований?

1 | Проблема с усечением Frustum области другим Frustumом
2 | Проблема с усечением Frustum области другим Frustumом
3 | Проблема с усечением Frustum области другим Frustumом

#41
11:32, 25 янв. 2021

Честно говоря вообще непонятно что на первом скриншоте.

#42
11:34, 25 янв. 2021

Три раза перечитал текст и тоже ничего не понял :-(

Какую задачу ты решаешь, можешь ещё раз переформулировать?

#43
14:04, 25 янв. 2021

Извиняюсь, опять отвлекают, даже не успел ответить тут :(

GLoom
> Какую задачу ты решаешь, можешь ещё раз переформулировать?

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

Если начинать с самого простого представьте себе сектор с окном в другой сектор, как на этом скриншоте:

+ Показать

Это вид из камеры, но я сделал вторую камеру, через которую можно смотреть на основную камеру с построенным фрустумом...т.е. можно смотреть со стороны на фрустум портала, выглядит это так:

+ Показать

В данном случае все просто - один портал, и один сектор, который видно через этот портал.

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

вид сверху:

+ Показать

и вид со стороны:

+ Показать

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

Но мой алгоритм работает только для левой и правой плоскости фрустума, т.е. в 2D координатах. Попытался изобразить это так:
Сначала строится фрустум 1 (его вы можете видеть на предыдущем скриншоте в виде со стороны),
потом строится 2й фрустум, находится точка их соединения и на выходе получается фрустум, который я указал жирной красной линией, как сумма двух маленьких.

+ Показать


Теперь возвращаясь к предыдущему моему посту:

+ Показать

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


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

+ Показать

И для выпуклого сектора крайние экранные точки как раз будут ближайшими к камере,  а я в своем воображении думал, что такой вариант сработает и для вогнутого сектора

+ Показать

А вот что получается у мены (как на 3м скриншоте)

+ Показать

Ну и на последок как это должно выглядеть

+ Показать


Ну и собственно тогда повторю вопрос:
Можно ли найти эти крайние точки без проецирования или хотя бы каким-нить более быстрым способом? Хотел бы решить задачу через расстояния до этих точек

#44
14:09, 25 янв. 2021

Вот еще два скриншота, что получается у меня

+ Показать

и что должно было получится

+ Показать

Страницы: 1 2 3 4 58 Следующая »
ПрограммированиеФорумГрафика