Войти
ПрограммированиеФорумОбщее

Стоит ли использовать DirectXCollision?

Страницы: 1 2 Следующая »
#0
11:27, 22 дек. 2015

При поиске информации по FrustumCulling узнал о существовании уже таких готовых классов как BoundingFrustum, BoundingBox и BoundingSphere. Реализованы они в DirectXCollision.h.

Если кто-то их использовал можете сказать стоит ли их вообще использовать или все таки писать свой "велосипед" для этого?


#1
11:34, 22 дек. 2015

Да, стоит.

#2
12:42, 22 дек. 2015

k119_55524
Спасибо за ответ.

Посмотрел одну из перегрузок конструктора BoundingFrustum. Как он обходится только Projection матрицей? В примерах без DirectXCollision видел, что для построения плоскостей используют результат перемножения viewMatrix и projectionMatrix.

#3
17:17, 22 дек. 2015

Digan
Берет единичную матрицу вида, не?

#4
17:37, 22 дек. 2015

-Eugene-
Вот почти весь код оттуда:

+ Показать

Не похоже на единичную матрицу вида. Что за homogenous space?

#5
17:43, 22 дек. 2015

Digan
> Что за homogenous space?
Это гуглится.
А алгоритм... Ну, он берет экранные координаты c границ экранного куба [-1 1], обращает проекцию и получает реальные точки задней плоскости фрустума в view-space. Хз что он с этими точками делает, но короче я прав. Он просто не юзает матрицу вида.

#6
1:30, 23 дек. 2015

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

Сейчас каждый кадр выполняется следующий код:

m_frutum = BoundingFrustum(projectionMatrix);

//center - координаты сферы, radius - радиус сферы
BoundingSphere sh = BoundingSphere(center, radius);

ContainmentType type = m_frutum.Contains(sh);

bool renderModel = type != ContainmentType::DISJOINT;

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

Можете подсказать где я ошибся?

Пожалуй стоит использовать другой конструктор:

BoundingFrustum(
  [in, ref] const XMFLOAT3 &_Origin,
  [in, ref] const XMFLOAT4 &_Orientation,
  [in]            float    _RightSlope,
  [in]            float    _LeftSlope,
  [in]            float    _TopSlope,
  [in]            float    _BottomSlope,
  [in]            float    _Near,
  [in]            float    _Far
);

+ Показать

_Origin и _Orientation я так понял можно у камеры брать (position и target), _Near и  _Far тоже понятно. Непонятны остальные 4 параметра, т.е. _RightSlope, _LeftSlope, _TopSlope и _BottomSlope. Это вроде наклоны усеченной пирамиды. Откуда их получить?

#7
8:25, 23 дек. 2015

Digan
> Получается, что projectionMatrix можно обойтись только если камера статичная
> или я не правильно что-то пишу.
Примерно так. Ты можешь использовать конструктор с матрицей проекции, только если сам не используешь матрицу вида.
Насчет второго - хз.

#8
11:05, 23 дек. 2015

Получилось примерно так:

При инициализации:

BoundingFrustum::CreateFromMatrix(m_frustum, projectionMatrix);

Каждый кадр:

cameraPos = m_Camera->GetPosition()
frustumOrientation = m_Camera->GetTarget();

m_frustum = BoundingFrustum(cameraPos, frustumOrientation, m_frustum.RightSlope, m_frustum.LeftSlope, m_frustum.TopSlope, m_frustum.BottomSlope, 0.1f, 1000.0f);

BoundingSphere sh = BoundingSphere(center, radius);

ContainmentType type = m_frutum.Contains(sh);

bool renderModel = type != ContainmentType::DISJOINT;

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

Я правильно думаю, что вот это

_Origin [in, ref]
The origin of the frustum.
_Orientation [in, ref]
The orientation of the frustum.

это по сути позиция и направление камеры (lookAt) ?

#9
11:25, 23 дек. 2015

Digan
> Работает вроде неплохо, но объект рисоваться начинает раньше чем попадет в поле
> зрения.
Это ты как определяешь?

#10
12:32, 23 дек. 2015

-Eugene-
> Это ты как определяешь?
Есть счетчик и флаг:

bool renderModel = type != ContainmentType::DISJOINT;
Счетчик обнуляется в начале каждого кадра. Если true, то счетчик +1. Счетчик выводится на экран.

Кстати сейчас возникла мысль, что объект начинает рисоваться из-за того, что одна из плоскостей пирамиды начинает пересекать объект. Условие type != ContainmentType::DISJOINT выполняется в двух случаях: объект внутри пирамиды или объект и плоскости пирамиды пересекаются.

#11
12:37, 23 дек. 2015

Digan
Стандартный тест выкидывает модель, если она лежит снаружи хотя бы одной плоскости.

#12
14:54, 23 дек. 2015

-Eugene-
> Стандартный тест выкидывает модель, если она лежит снаружи хотя бы одной
> плоскости.
А если хотя бы одна плоскость пересекает модель? Рисовать или нет?

#13
15:12, 23 дек. 2015

Digan
> Рисовать или нет?
да, но если можешь, рисуй сабмеш (видимую часть от сетки)
Может ты видищь кусочек якоря от авианосца, зачем рисовать весь авианосец?

#14
15:56, 23 дек. 2015

Digan
> А если хотя бы одна плоскость пересекает модель? Рисовать или нет?
Это не имеет значения. Я уже написал стандартный алгоритм почти дословно:

"модель не видна, если она лежит снаружи хотя бы одной плоскости, иначе - видна"

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

Страницы: 1 2 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.