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

Пересечение сферы и полигональной модели

Страницы: 1 2 Следующая »
#0
16:03, 10 июля 2014

Задача такая. Дана сфера в виде координат центра и радиуса. Дана полигональная модель с матрицей преобразования. Эта матрица произвольная, и неизвестно откуда она получилась. Она может содержать не только смещение и поворот, но и масштабирование, причём разное по разным осям.
Я могу найти пересечение сферы с моделью только умножая все позиции вершин модели на её матрицу. Но это медленно. Если бы было точно известно, что матрица не содержит масштабирования, то можно было бы один раз умножить координаты центра сферы на обратную матрицу, и вести расчёты уже в пространстве модели. Но в общем случае сфера станет не сферой, а эллипсоидом, да ещё неизвестно как повёрнутым и с неизвестными полуосями.
Как быть?


#1
16:27, 10 июля 2014

И мне интересно ... без масштабирования то все просто, а с ним ...

#2
19:49, 10 июля 2014

в чем проблема разложить матрицу на матрицы вращения, масштабирования, перемещения? Не для всякой матрицы конечно это можно сделать, но если намудрили при ее получении то сами себе буратины.

+ Показать

#3
20:29, 10 июля 2014

Aroch
> Не для всякой матрицы конечно это можно сделать, но если намудрили при ее
> получении то сами себе буратины.
А можно ли по матрице определить, можно ли это сделать или нет? Как этот код поведёт себя в случае, когда намудрили? Мне было бы достаточно наверное взять этот код, но поставить проверку на намудрённость.

Значит одну проблему решили. Масштабирование теперь известно. Если оно одинаковое по всем осям, то сфера останется сферой и всё будет хорошо. А если разное, то что делать? Хотя это будет довольно редко и наверное на оптимизацию этого случая можно забить...

#4
21:10, 10 июля 2014

gammaker
если намудрили то оси не будут перпендикулярны друг другу :) И да ты можешь закладывать масштабирование с учетом ориентации модели в формулу проверки на попадание точки в сферу, как это сделать реши самостоятельно.

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

#5
21:48, 10 июля 2014

Не понимаю, в чем проблема? Не хочется считать заранее преобразованную модель? Ну так считай по месту, вместо проверки

[cht]\[(\mathbf{p}-\mathbf{s})^2<R^2,\][/cht]

делай проверку

[cht]\[(M\mathbf{p}-\mathbf{s})^2<R^2.\][/cht]

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

#6
22:01, 10 июля 2014

Aroch
> з.ы. но вообще подход к решению твоей задачи должен быть другой, подготовь
> заранее для модели иерархическую структуру которая будут описывать модель теми
> же сферами, в итоге у тебя будут проверки сфера vs сфера и только при их
> коллизии для листьев дерева твоей структуры будешь уже по честному смотреть
> треугольник vs сфера
Я где-то тут видел код реализации с помощью AABB-деревьев. Я собираюсь его прикрутить, а тупой перебор треугольников у меня это временное решение. Но надо подкорректировать архитектуру движка, разобраться кто будет владеть этим деревом и всё такое.

Aroch
> А еще лучше взять любой физ. движок и использовать его/подсмотреть как у него.
Я планирую прикрутить Bullet, но элементарные коллизии хотелось бы сделать отдельно, чтобы не тащить его там, где не нужна сложная физика, а достаточно простой проверки столкновений. Но ближе к делу я посмотрю в его исходники. Там наверняка много полезного, что можно было бы позаимствовать.

Aroch
> если намудрили то оси не будут перпендикулярны друг другу :)
А ну это легко проверить.


}:+()___ [Smile]
> При желании можно раскрыть скобочки и поупрощать, но в общем случае выигрыша не
> будет.
Ну как бы если 100000 вершин у модели, то это 100000 лишних умножений на матрицу. Но даже без этого уже сильно тормозит. Понятно, что метод считать в лоб не годится, но к другому я пока не готов перейти.


А вообще где можно найти математические функции связанные с работой с OBB, AABB, всякими сферами и их пересечениями? Желательно целиком, например в составе какой-то библиотеки, а не отрывками кода из статей, где надо что-то додумывать.

#7
22:10, 10 июля 2014

gammaker
Может бить мэш на конвексы?

#8
22:18, 10 июля 2014

ExeLord
> Может бить мэш на конвексы?
Слышал про такое. Только понятия не имею, как это делается. По-моему что-то в Bullet'е по этому поводу видел.

#9
11:45, 11 июля 2014

Зачем вообще может понадобиться непропорциональное масштабирование по разным ортам?
Приведите хоть один нормальный пример?
Может лучше вообще убрать такую функцию из проекта?=)))

PS Причем масштабирование не какого-то бокса, а уже готового меша..

#10
12:07, 11 июля 2014

AMM1AK
> Зачем вообще может понадобиться непропорциональное масштабирование по разным
> ортам?
Ну например можно немного регулировать рост персонажа. Можно сферу превратить в эллипсоид, не создавая новый меш.
С точки зрения столкновений это позволит сделать наоборот: свести задачу эллипсоида с немасштабированным мешем к задаче столкновения сферы с масштабированным мешем. Сейчас камера у меня представляется в виде сферы, из-за чего персонаж получается маленьким и толстым. Если растянуть её по вертикали, то получится как надо.

AMM1AK
> Может лучше вообще убрать такую функцию из проекта?=)))
У меня матрица поступает извне, а не отдельно поворот, перемещение и масштабирование, на которые можно было бы наложить какие-то ограничения на уровне архитектуры. Это очень гибко и удобно, но поначалу возникают вот такие вот проблемы.

#11
13:01, 11 июля 2014

gammaker
Можно ещё использовать (Local) Axes Aligned Vertex Sort. Получится эдакий трехмерный массив вершин, и с ним уже намного проще будет работать
(бинарным поиском, к примеру, при желании можно даже окт-три сделать).

#12
14:55, 11 июля 2014

gammaker
> Сейчас камера у меня представляется в виде сферы, из-за чего персонаж
> получается маленьким и толстым. Если растянуть её по вертикали, то получится
> как надо.
сделай его из трех сфер делов то, как бонус можно будет детектить ноги торс голову :)

#13
15:04, 11 июля 2014

ExeLord
> Можно ещё использовать (Local) Axes Aligned Vertex Sort. Получится эдакий
> трехмерный массив вершин, и с ним уже намного проще будет работать
Не понял, каким образом получится трёхмерный массив? Сортировать ведь можно только по одной оси.

Aroch
> сделай его из трех сфер делов то, как бонус можно будет детектить ноги торс
> голову :)
А с приседанием как быть? Эллипсоид можно просто сжимать по высоте, а с тремя сферами так не получится. Разве что уменьшать торс и голову и увеличивать ноги, но это как-то совсем нереалистично.

#14
15:55, 11 июля 2014

gammaker
> А с приседанием как быть? Эллипсоид можно просто сжимать по высоте, а с тремя
> сферами так не получится. Разве что уменьшать торс и голову и увеличивать ноги,
> но это как-то совсем нереалистично.
ну что же так всё плохо :) Кто тебе запрещает анимировать сферы коллизии вместе с персонажем?
стоим:
o
O
o
сидим:
o
O
сфера ног будет почти в сфере торса.

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

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