Occlusion culling?
за видео извиняюсь сразу, приходится с руки снимать, потому что не хотят у меня записывать захватичики экранов всё что я делаю с OpenGL
да оно даже здесь не хочет воспроизводится нормально... я заколдован
Это порт Quake II на Delphi.
исходники до сих пор валяются в интернете
Данная версия спокойно запускается, без всяких тормозов и на древненьком Asus Eee PC 900.
FPS не отображается, но изображение достаточно гладкое, чтоб понять, что ни каких заваливаний FPS ниже 30 даже речи идти не может. И не забываем, что Quake полностью трёхмерен!!!
Я веду речь о том, что вероятно, движок, который вы используете или который переделали, может по нескольку раз делать одно и то же при чём на разных участках кода. Может иметь проблемные участки кода, которые надо было решить двести лет назад, но их отложили до "скорого времени.
И я не говорю, что не надо ограничивать то, что не попадает в кадр. Я про то, что не всё из этого надо ограничивать!
Всё надо тестировать и смотреть, какие куски кода заваливают FPS, какие объекты дают большую нагрузку. И, вероятно, не надо дальность прорисовки делать дальше, чем "видит глаз"? ))) Потому и делают разумное ограничение дальности прорисовки или меняют стратегию прорисовки дальних расстояний.
m210
> Я сейчас не понял. В выше представленных примерах я показывал карты у которой
> 4000 стен и 1000секторов, при этом на расчет видимости обрабатываются не все
> сектора, а только те, которые видят соседние порталы.
это может быть "двойной обработкой" информации. В первый раз вы обрабатывате информацию сами (просчитываете всё сами) и отправляете данные видеокарте, а второй раз те же данные обрабатывает видеокарта.
Mirrel
В Quake отсечение полигонов основано не на порталах, а BSP.
BSP (binary space partition), просто разбиение пространства в виде дерева, как иерархия.
Портал - это разбиение пространства в виде графа.
Совершенно разный подход.
Funtik, это не означает, что довольно старые методы отрисовки должны сильно сказываться на FPS.
... а вот в трёхмерном пространстве...
почитал про порталы. Если использовать ось Z, то мы должны вводить дополнительные "порталы" для этой оси. И делить не пополам экран, а на 4 части. Лево/право, верх/низ.
тут в чём-то мой недочёт, забываю про разные методы вывода
Mirrel
Данная версия спокойно запускается, без всяких тормозов и на древненьком Asus Eee PC 900.
FPS не отображается, но изображение достаточно гладкое, чтоб понять, что ни каких заваливаний FPS ниже 30 даже речи идти не может
А теперь запусти тоже самое, только чтобы карта рендерилась не surfacesами, а каждая стена - индивидуальный drawcall, и получишь то, что получаю я.
Я веду речь о том, что вероятно, движок, который вы используете или который переделали, может по нескольку раз делать одно и то же при чём на разных участках кода.
А причем тут движок, если речь идет о рендере?
Какая рендеру разница, чем занимается движок...не говоря уже о том, что функции движка я вообще не использую сейчас, он мне нужен только чтобы загрузить карту и чтобы вывести картинку по средствам glDrawArray
Главное отличие кваковского BSP от моего рендера в том, что в BSP неважно сколько частей карты ты выводишь, количество вызовов будет равно количеству подключенных текстур, а т.к. в портальном движке в одном и том же пространстве может находиться несколько секторов, я не могу просто взять и объединить несколько мешей в один вызов GL. И оптимизации по объединению вызовов у меня нет, но это не отменяет того факта, что проблема есть и будет, а видеокарта не всемогуща....я тоже могу как и ты вывести всю карту за 1 вызов, но игра работать не будет, в кадр будет лезть то, чего ты видеть не должен.
Вот тебе наглядный пример - как это должно выглядеть
А вот как это бы выглядело на движке Quake
Поэтому я не могу просто взять и втупую вывести все одним мешем и одним каким-нибудь текстурным атласом, как это делает Quake и сравнение тут абсолютно неуместно
m210, я думаю мы на разных языках говорим. Потому моё дело дальше не лезть. )))
Возможно мой коммент был незамечен, но по-моему ответ очевиден, occlusion culling, не? :)
IIIarp
если ты про оклюдер, то нет, occlusion culling - это технология, а occluder - это объект.
Например если перед тобой стоит столб, за которым находится мусорное ведро и ты его не видишь, то столб будет являться оклюдером - строится фрустум от камеры через столб и все что попадает в этот фрустум - не видно.
По поводу конкретно моей темы - у меня пока совсем нет на это времени. Но я убедился, что верхняя и нижняя поверхность фрустума совершенно не работает даже без всяких обрезаний. Поэтому я решил левую и правую поверхности оставить, а попадание точек по Z я буду проверять проецированием пола и потолка каждого портала сектора и обрезать по уровням Y экранных координат. Должно быть быстрее, чем проецирование всех стен и не сильно медленее, чем построение и проверка через 3D фрустум.
Но надо будет проверять, возможно, на следующей неделе появится время
m210
Я про технологию :)
Я к тому, что открываешь любую ссылку из гугла по запросу "occlusion culling" и видишь полное описание и порталов и оклюдеров и всего остального с псевдокодом.
И там 100% найдешь ответ какие плоскости юзать, а какие нет и каким образом.
IIIarp
Ну это тоже самое, что сказать: чтобы написать игру надо в интернете ввести "игровой цикл" и готово :)
И occlusion culling и portal culling все же разные вещи. В любом случае я уже определил себе цель и путь к ее достижению, осталось найти на это время. А потом буду проводить оптимизацию, а то как оказалось raycasting достаточно тормозной алгоритм по сравнению с frustum culling ом
Всем привет!
Наконец-то появилось немного времени, чтобы продолжить ковырять "создание" фрустумов.
Для лучшего понимания процессов, написал метод рисования фрустума...на скриншоте показан фрустум синего сектора, который состоит из 5 стен (но визуально "дырка" одна)
В общем решил я попробовать строить верхнюю и нижнии поверхности по двум ближайшим к камере точкам и на первых двух скриншотах можно увидеть, что такой способ для выпуклой геометрии работает - фрустум охватывает все стены своего сектора. Далее, я решил облететь сектор и построить фрустум через вогнутую геометрию, ну и ничего не срослось (см 3й скриншот), т.к. выходит, что плоскости нужно строить не по ближ. точкам к камере, а по спроецированным на экран точкам, тем, что ближе к вехней и нижней границам экрана (т.е. при разрешении 640х480, нужно брать точки, которые ближе к 0 и 480 на экране) - в итоге во фрустум не попадают все стены сектор.
Неужели нельзя обойтись без медленных проецирований?
Честно говоря вообще непонятно что на первом скриншоте.
Три раза перечитал текст и тоже ничего не понял :-(
Какую задачу ты решаешь, можешь ещё раз переформулировать?
Извиняюсь, опять отвлекают, даже не успел ответить тут :(
GLoom
> Какую задачу ты решаешь, можешь ещё раз переформулировать?
Понимаю, тут лучше было бы записать видео, но попробую объяснить на скриншотах, т.к. сделать видео я смогу минимум вечером.
Если начинать с самого простого представьте себе сектор с окном в другой сектор, как на этом скриншоте:
Это вид из камеры, но я сделал вторую камеру, через которую можно смотреть на основную камеру с построенным фрустумом...т.е. можно смотреть со стороны на фрустум портала, выглядит это так:
В данном случае все просто - один портал, и один сектор, который видно через этот портал.
Но если мы разобьем стену портала на две части, т.е. вместо одной стены у портала будет две стены, получим такую картину:
вид сверху:
и вид со стороны:
т.е. фрустум портала уже не полный.
Поэтому я написал код, который соединяет все видимые через камеру стены и строит из всех этих стен один большой фрустум портала и после прогона такого алгоритма мы будем видеть такую же картину, какую Вы видели на первом скриншоте.
Но мой алгоритм работает только для левой и правой плоскости фрустума, т.е. в 2D координатах. Попытался изобразить это так:
Сначала строится фрустум 1 (его вы можете видеть на предыдущем скриншоте в виде со стороны),
потом строится 2й фрустум, находится точка их соединения и на выходе получается фрустум, который я указал жирной красной линией, как сумма двух маленьких.
Теперь возвращаясь к предыдущему моему посту:
Вот так выглядит фрустум синего сектора с видом сверху...вроде тут ничего объяснять не надо.
И теперь мне нужно построить верхнюю и нижнюю плоскость фрустума, и результат попытки я и показал в первом скриншоте с видом со стороны.
И теперь возможный вариант решения для вогнутого сектора:
Надо взять по две ближайшие точки (зеленые и построить через них плоскости (3я точка - сама камера)
И для выпуклого сектора крайние экранные точки как раз будут ближайшими к камере, а я в своем воображении думал, что такой вариант сработает и для вогнутого сектора
А вот что получается у мены (как на 3м скриншоте)
Ну и на последок как это должно выглядеть
Ну и собственно тогда повторю вопрос:
Можно ли найти эти крайние точки без проецирования или хотя бы каким-нить более быстрым способом? Хотел бы решить задачу через расстояния до этих точек
Вот еще два скриншота, что получается у меня
и что должно было получится
Тема в архиве.
