Определение того, находится ли многоугольник внутри усеченного конуса - PullRequest
1 голос
/ 16 июня 2011

вот мои вопросы. Я слышал, что opengl игнорирует вершины, находящиеся вне области просмотра, и не учитывает их в конвейере рендеринга. Недавно я наткнулся на тот же пост, в котором говорилось, что вы должны проверить это сами, и если точка не находится внутри, вы обязаны выяснить, не opengl! Теперь,

  1. Это правда об opengl? он понимает, если точка не внутри, и не рендерить ее?
  2. Я разрабатываю сцену с травой, на прямоугольниках которой около 4000 трав. У меня ужасный FPS, и единственное решение, которое я нашел, было решить, какие травы находятся внутри области просмотра, а затем только визуализировать их! Мой вопрос здесь заключается в том, что для меня лучше всего узнать, какой прямоугольник не находится внутри, а какой нет?

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

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

Ответы [ 4 ]

3 голосов
/ 16 июня 2011

Даже если true, то OpenGL не показывает многоугольники вне усеченного конуса (как любые другие 3d движки), он должен учитывать их, чтобы проверить, есть ли они внутри или нет, а затем замедлить fps. Обычно требуется некоторый интеллектуальный алгоритм оптимизации, чтобы избежать затопления сцены невидимыми объектами. Например, проверьте BSP деревья + PVS или порталы в качестве отправной точки. Чтобы проверить наличие узкого места в приложении, вы можете попробовать gDebugger . Если нет ничего разумного, неправильно оптимизировать, чтобы нарисовать только PVS (возможный видимый набор).

2 голосов
/ 16 июня 2011

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

Это означает, что в этом случае пиксель не растеризуется, но данные вершин обрабатываются одинаково; просто не производит фрагменты, полученные из невидимого треугольника!

Расширение OpenGL ARB_occlusion_query может помочь вам, но в разделе обсуждения проясните:

Делают ли запросы окклюзии устаревшими другие алгоритмы видимости?

    No.

    Occlusion queries are helpful, but they are not a cure-all.  They
    should be only one of many items in your bag of tricks to decide
    whether objects are visible or invisible.  They are not an excuse
    to skip frustum culling, or precomputing visibility using portals
    for static environments, or other standard visibility techniques.

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

2 голосов
/ 16 июня 2011

OpenGL не будет отображать пиксели («фрагменты») за пределами экрана, поэтому он должен каким-то образом обрезать ...

Точнее:

  • Вы отправляете свою геометрию
  • Вы делаете вызов Draw (glDrawArrays или glDrawElements)
  • Каждая вершина проходит через вершинный шейдер, который вычисляет конечную позицию вершины в пространстве камеры. Если вы не написали вершинный шейдер (= старый opengl), драйвер создаст его для вас.
  • Перспективное деление преобразует эти координаты в нормализованные координаты устройства. Грубо говоря, это означает, что усеченная поверхность вашей камеры деформируется, чтобы поместиться в поле [-1,1] x [-1,1] x [-1,1]
  • Все, что находится за пределами этой коробки, обрезано. Это может означать полное отбрасывание треугольника или подразделение его, если оно пересекает плоскость отсечения
  • Каждый оставшийся треугольник растеризуется на фрагменты
  • Каждый фрагмент проходит через фрагментный шейдер

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

Это, конечно, компромисс. Если вы потратите 10 мс на проверку каждого патча травы на ЦП, чтобы у графического процессора было только минимальное количество данных для рисования, это тоже не хорошее решение.

Если вы хотите оптимизировать траву, я советую отбирать большие участки (5 х 5 м или около того). Это стандартное тестирование AABB-усеченного конуса.

Если вы хотите оптимизировать более общую модель, вы можете исследовать quadtree для «плоских» моделей, октодеревьев и bsp-деревьев для более сложных объектов.

1 голос
/ 16 июня 2011
  1. Да.Как уже отмечали другие, OpenGL должен выполнить множество операций для каждой вершины, чтобы определить, находится ли он в усеченной области.Он должен делать это для каждой вершины, которую вы отправляете.Помимо накладных расходов на обработку, имейте в виду, что существуют также дополнительные накладные расходы при передаче этих вершин из CPU в GPU.Вы хотите избежать отправки информации в графический процессор, который он не собирается использовать.Хотя пропускная способность между центральным процессором и графическим процессором достаточно хороша для современного оборудования, ограничение все же есть.

  2. Вам нужен Scene Graph .Графы сцен часто реализуются с помощью некоторой схемы пространственного разделения, например, Quadtrees , Octrees , BSPTrees и т. Д. И т. Д. Пространственное разбиение позволяет вам интеллектуально определить, чтогеометрии видны.Вместо того, чтобы делать это для каждой вершины (как это делает OpenGL), он может исключать огромные пространственные подмножества геометрии за раз.При рендеринге сложной сцены экономия производительности может быть огромной.

...