Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Отсечение невидимой геометрии (4 стр)

Отсечение невидимой геометрии (4 стр)

Поделиться
Страницы: 13 4 5 616 Следующая »
zombihelloПостоялецwww23 сен. 201714:27#45
Daniil Petrov
> но у тебя код получше проработан, чем мой!
:D уверен? Как по мне +/- твой и мой код одинаковый (небольшие различия только)

Daniil Petrov
> А это как?
По сути пока этого в движке нету, так как модели не трансформируются (пока это не надо), а
браши уровня уже находятся в мировой СК с учетом трансформации.

Но в теории это звучит как-то так: вершины BoundingBox'a обновляются с помощью матрицы трансформации.

вот пример псевдо кода:

void UpdateBoundingBox( glm::mat4 Transform )
{
//Vertexs - массив вершин типа glm::vec3 (их всего 8 у BoundingBox'a)
//Transform - матрица трансформации объекта

for ( int i = 0; i < 8; i++ )
Vertexs[i] *= Transform; // ну или примерно так, еще не проверял
}

Понимаю что объяснил коряво, но как-то так (у меня всегда был "талант" объяснения )) )

slava_mibМодераторwww23 сен. 201714:28#46
> А это как?
Daniil Petrov, берёшь OBB, трансформируешь его его же мировой матрице - и получаешь его OBB в пространстве мира. Для статической геометрии, которой обычно 95% игрового мира - оно будет константным и обновлять его больше не надо.

P/S Я у себя считаю вообще баундинг-сферами - проще код, быстрее работает, но менее точно (но и у нас и объектов иногда бывает по 100к и больше).

Daniil PetrovЗабаненwww23 сен. 201714:48#47
zombihello
> Как по мне +/- твой и мой код одинаковый
Я не допёр, что после вычисления каждой плоскости, идёт нормализация :)

> Но в теории это звучит как-то так: вершины BoundingBox'a обновляются с помощью матрицы трансформации.
Примерно так - http://www.mbsoftworks.sk/index.php?page=tutorials&series=1 - уроки 18, 19? Я сам ещё их не штудировал.

slava_mib
> берёшь OBB, трансформируешь его его же мировой матрице - и получаешь его OBB в пространстве мира.
При загрузке моделей?

> Я у себя считаю вообще баундинг-сферами - проще код, быстрее работает, но менее точно
Сделаю проверку и сфер, и боксов, а там уже буду плясать по ситуации.

zombihelloПостоялецwww23 сен. 201715:05#48
Daniil Petrov
> Примерно так - http://www.mbsoftworks.sk/index.php?page=tutorials&series=1 -
> уроки 18, 19? Я сам ещё их не штудировал.
Так там, как я понял, идет выбор объекта мышкой, а не обновления вершин BoundingBox'a
(я статью не читал, посмотрел демку только)

Тебе не понятно как обновить BoundingBox с учетом трансформации объекта? Если да, то вершины BoundingBox'a
обновляются так же само как ты, например, перемещаешь вершины модели в шейдере
(умножением вершины в локальной СК на матрицу трансформации)

zombihelloПостоялецwww23 сен. 201715:11#49
Daniil Petrov
> При загрузке моделей?
По началу да, а если модель сместилась, повернулась и т.п, то так же само обновляешь. (если я правильно понял мысль slava_mib)
Я ведь правильно понял OBB - это ограничивающее тело?
slava_mibМодераторwww23 сен. 201716:30#50
> При загрузке моделей?
Daniil Petrov, при загрузке моделей считаешь для каждой из них AABB. А при добавлении на сцену каждой из них, их же много инсансов - берушь исходный AABB у множаешь на матрицу инстанса - получаешь OBB для каждого объекта в мире.

> Я ведь правильно понял OBB - это ограничивающее тело?
zombihello, в общем и целом - да ) https://habrahabr.ru/post/257339/

zombihelloПостоялецwww23 сен. 201717:22#51
slava_mib
> zombihello, в общем и целом - да ) https://habrahabr.ru/post/257339/
Спасибо за статью, на днях почитаю
AslanПостоялецwww23 сен. 201719:22#52
zombihello
Если точка O - камера, d-расстояние до ближней плоскости отсечения, w,h-половины размеров фрустума, ex,ey,ez - базисные вектора ее ориентации,
то берешь точки A=ez*d-ex*w-ey*h, B=ez*d+ex*w-ey*h, C=ez*d+ex*w+ey*h, D=ez*d+ex*w-ey*h
Твои плоскости -  OAB, OBC, OCD, ODA
Для отсечения грани против пирамиды примени теорему о разделяющей оси
Для скорости же понадобится OctTree и пересечение бокса с пирамидой

ЗЫ. Frustum Culling отсекает пирамиду из сцены, например если угол обзора по горизонтали и вертикали 90, то остается 1/6 объема, и в среднем 1/6 геометрии
Так что данная техника глобально ничего не решает

По Occlusion Culling читал про метод, использующий OctTree, не могу ни найти статью, ни вспомнить название
Суть в использовании информации с предыдущего кадра:
У прошедшего Occlusion Test узла ставим флаг=true и на следующем кадре его уже не проверяем, сразу переходим к потомкам, там аналогично смотрим на их флаг итд.
Если ни один из 8 потомков не прошел Occlusion Test - сбрасываем флаг у их родителя и следующий кадр он также будет проверен. Таким образом изменения распостраняются
вверх-вниз по дереву

Правка: 23 сен. 2017 20:06

slava_mibМодераторwww23 сен. 201721:58#53
> метод, использующий OctTree
Aslan, в целом - это старьё, никем сейчас не используемое по большей части. Задачи всех этих BSP/OcTree/QuadTree и прочих - пихнуть как можно геометрии в кадр. Для старого железа (лет 5-10-15 назад) это было очень актуально, ибо отсечь треугольник на проце было эффективнее, чем на видюхе. Сейчас уже - нет.

Они все применяются по-прежнему, но в более специфических и извращённых методах, а в чистом исходном виде - они давно мертвы, ибо нет смысла - они времени и памяти сжирают больше, чем дают эффекта. Если посчитать доки того же самого DICE, то они прямым текстом пишут, что когда отказались от всяких ***Tree, то не только получили в разы меньше кода, но и значительный прирост производительности.

zombihelloПостоялецwww23 сен. 201722:08#54
Aslan
> По Occlusion Culling читал про метод, использующий OctTree
Хотелось бы почитать эту статью, так как в интернете не нашел статьи по этому
поводу, яндекс выдает только Occlusion Culling в Unity. Для начала даже без
OctTree хотелось бы сделать (чтобы с OctTree пока не мучатся и понять сам алгоритм)

Еще хотел бы спросить, что лучше делать Occlusion Culling или Occlusion Queries?
Но в Occlusion Queries меня смущают glBindQueries/glEndQueries то, что
производительность будет как с glBind/glEnd.

slava_mibМодераторwww23 сен. 201722:15#55
> что лучше делать Occlusion Culling или Occlusion Queries?
zombihello, это не взаимоисключающие вещи.
Кверисы - у них латентность и всё такое, правильная их реализация далеко не проста и не очевидна.
Окклюжен - можно и софтварный делать.
Но и то и другое имеет смысл, наверное, только если много индора, либо атудор но с очень большой степенью перекрытия объектами друг-друга.
Daniil PetrovЗабаненwww24 сен. 20172:44#56
zombihello
> Тебе не понятно как обновить BoundingBox с учетом трансформации объекта?
Мне не понятно даже как это сделать для статичного объекта :))) если честно.

slava_mib
> берушь исходный AABB у множаешь на матрицу инстанса - получаешь OBB для каждого объекта в мире.
Т.е. в функцию проверки пихаешь тело, помноженное на матрицу трансформации, да?

> P/S Я у себя считаю вообще баундинг-сферами - проще код, быстрее работает, но менее точно
Так?

bool SphereInFrustum(glm::vec3 Center, float Radius)
{
  int p;

  for (p = 0; p < 6; p++)
    if (FrustumPyramid[p].x * Center.x + FrustumPyramid[p].y * Center.y + FrustumPyramid[p].z * Center.z + FrustumPyramid[p].w <= -Radius)
      return false;
  return true;
}

Парни, а есть у кого ссылка на пример исполнения Ray Casting? Хотелось бы после Frustum Culling добавить его и на долго про это всё забыть :) у меня очень не скоро появятся достаточно большие и сложные локации.
И как корректно умножить glm::vec3 на glm::mat4 - glm::vec3 = glm::mat4 * glm::vec3, правильно?

Правка: 24 сен. 2017 4:34

AslanПостоялецwww24 сен. 20178:10#57
slava_mib
> это старьё, никем сейчас не используемое по большей части. Задачи всех этих BSP/OcTree/QuadTree и прочих - пихнуть как можно геометрии в кадр. Для старого железа (лет 5-10-15 назад) это было очень актуально, > ибо отсечь треугольник на проце было эффективнее, чем на видюхе. Сейчас уже - нет
А что сейчас видеокарты научились МГНОВЕННО рисовать?
ОДИН треугольник видеокарта конечно быстрее отсечет, а всякие деревья-порталы за раз отсекают КУЧУ треугольников, значительные части сцены
> Они все применяются по-прежнему, но в более специфических и извращённых методах, а в чистом исходном виде - они давно мертвы, ибо нет смысла - они времени и памяти сжирают больше, чем дают эффекта
Окто-дерево мало занимает, в узлах лишь VBO ID. Ты не понял принцип, там рендерится не вся иерархия объемов, а лишь изменения видимости с пред кадра, в среднем очень эффективно
> Если посчитать доки того же самого DICE, то они прямым текстом пишут, что когда отказались от всяких ***Tree, то не только получили в разы меньше кода, но и значительный прирост производительности
Кто такой DICE? Doom, Half-Life от порталов отказались?
AslanПостоялецwww24 сен. 20178:20#58
zombihello
> Хотелось бы почитать эту статью, так как в интернете не нашел статьи по этому поводу, яндекс выдает только Occlusion Culling в Unity.
Чтото вроде Hierarchical Occlusion Culling, если найду - скину тебе. Я вкратце описал принцип. Пользуйся гуглом, а не яндексом
> Еще хотел бы спросить, что лучше делать Occlusion Culling или Occlusion Queries?
Видимо первое делается через второе ). Я сам не пользовался, только читал статью, понравился принцип.
innuendoПостоялецwww24 сен. 20178:24#59
Страницы: 13 4 5 616 Следующая »

/ Форум / Программирование игр / Графика

2001—2017 © GameDev.ru — Разработка игр