- Suslik
- Постоялец
Зачем в velocity-based вам хранить ускорение для каждой чсатицы? Достаточно скорости. Если есть внешнее поле, то это одно значение (константа) для все частиц.
Два метода не взаимозаменяемы, и как уже было отмечено, Position-Based, будет плохо работать когда большая концентрация частиц. У вас в примере большая концентрация и непонятно как вы их расталкивали. Проникших друг в друга частиц должно быть больше одной на каждый интервал времени. Не видно выгоды, кроме кажущейся простоты алгоритма.
При расталкивании все равно придется считать правильные углы отскока и скорости с поправкой времени пролета при проникновении частиц друг в друга.
Когда между частицами есть связи, то да, все красиво. Но это будет уже отделный метод, а не пришедший на замену velocity-based.
Видимо, Position-Based из FLASH пришел. Там dt - это время одного кадра.
P.S. удивило, что в havok коллизии разрешаются "методом расталкивания".
newline
> Зачем в velocity-based вам хранить ускорение для каждой чсатицы?
я его где-то храню?
struct PositionBasedParticle { Vector3 position; Vector3 prevPosition; float radius; void Move(); };
> Два метода не взаимозаменяемы, и как уже было отмечено, Position-Based, будет
> плохо работать когда большая концентрация частиц. У вас в примере большая
> концентрация и непонятно как вы их расталкивали.
забавно, но я их расталкиваю ровно так, как написал в статье. если не верите, можете потестить демку. елозить мышью.
> Проникших друг в друга частиц должно быть больше одной на каждый интервал времени.
это неверно. метод себя отлично зарекомендовал именно в стресс-ситуациях, когда обычные импульсные методы ведут себя плохо(неустойчиво или слишком мягко).
> При расталкивании все равно придется считать правильные углы отскока и скорости
во-первых, это, как я уже заметил в статье, не обязательно. хотя точность повышает достаточно существенно, согласен. во-вторых, это всего две строчки кода, а не килобайты импульсного солвера. обычно в подобных сценах импульсы примерно понятно как резолвить, с этим проблем не возникает. куда труднее обстоит дело с резолвингом позиций, именно с этой задачей position-based подход справляется неплохо.
> с поправкой времени пролета при проникновении частиц друг в друга
не могу себе представить ситуацию, когда кому-то в position-based подходе покажется важным учитывать поправку на время столкновения. там такие допущения принимаются, что это поправка по сравнению с ними просто таки исчезающе мала.
> Когда между частицами есть связи, то да, все красиво
этот подход ещё называется constraint-based. потому что расталкивание взаимопроникших тел эквивалентно добавлению связи в точке контакта. то есть резолвинг контакта математически эквивалентен тому, что в точку контакта временно добавляется жёсткая связь.
> Видимо, Position-Based из FLASH пришел. Там dt - это время одного кадра.
боюсь, position-based подход был придуман, когда флеша ещё и в задумках не было
так, для общего образования:
этот движок реализован полностью на position-based подходе. ну по крайней мере несколько лет назад это было так, сейчас уже не интересовался.
>я его где-то храню? (ускорение)
да. вы пишите:
>а положение — на velocity * dt. В коде это можно представить так:
void ClassicPoint::Move(float dt)
{
velocity += acceleration * dt;
position += velocity * dt;
}
>> Проникших друг в друга частиц должно быть больше одной на каждый интервал времени.
>это неверно.
Пусть плотный массив частиц. Растолкали одну пару. Они наехали на другие частицы. Их опять надо расталкивать. И так до момента пока частицы не вытолкаются за пределы этой плотной области. Визуально, конечно, это не видно, если не показывать до завершения расчета.
демка не качается, только 5 кб приходит.
>это всего две строчки кода, а не килобайты импульсного солвера
С выражением "солвер" не знаком. Сори.
Вы же все равно находите пару частиц проникших друг в друга и перелопачиваете весь массив.
>И если мы хотим предсказать, как изменится положение точки, когда пройдёт интервал времени dt...
Если вычислять dt до первого взаимодействия пары частиц?
>> с поправкой времени пролета при проникновении частиц друг в друга
>не могу себе представить ситуацию...
частицы могут не только проникать друг в руга, но и пролетать насквозь, что совсем не ловится методом позишин-бэйс.
Буду благодарен за разьяснение термина "резолвин".
Я не критикую сам метод, а акцентирусь на некоторых моментах при которых метод может не работать.
Хотел посмотреть пример, но не качается ваша демка.
newline
> void ClassicPoint::Move(float dt)
> {
> velocity += acceleration * dt;
> position += velocity * dt;
> }
ты уверен, что читал мою статью? я ж написал: "Рассмотрим обычный подход, ещё называемый velocity-based, к моделированию, например, движения материальной точки". следующий абзац: "Отличие же Position-Based подхода от Velocity-Based состоит в том, что мы не храним скорость и ускорение в явном виде.". я надеялся, что хотя бы до сюда все дочитают :(
> Пусть плотный массив частиц. Растолкали одну пару. Они наехали на другие
> частицы. Их опять надо расталкивать. И так до момента пока частицы не
> вытолкаются за пределы этой плотной области. Визуально, конечно, это не видно,
> если не показывать до завершения расчета.
скажу более того, обычно даже после завершения расчёта на кадре всё равно остаются взаимопроникшие частицы. сила метода в том, что это взаимопроникновение достаточно быстро и эффективно резолвится, в результате практически незаметно. скажу ещё более того, обычно импульсные методы расталкивания сводятся к чему-то подобному, к попарному расталкиванию, только это делается не через такие тривиальные операции и получается в конце концов не так эффективно.
> демка не качается, только 5 кб приходит.
боюсь, это у тебя какие-то проблемы. ну [url=отсюда попробуй.
> С выражением "солвер" не знаком. Сори.
ну так успехов в ознакомлении
>Вы же все равно находите пару частиц проникших друг в друга и перелопачиваете весь массив.
во-первых, "перелопачивание массива" делается вовсе не в лоб перебором. для оптимизации этого процесса есть много достаточно эффективных методик, Broad Phase в "терминах"
>Если вычислять dt до первого взаимодействия пары частиц?
Будем моделировать одну частицу, которая скачет по полу. Пусть частица после каждого отскока теряет половину своей энергии. Пусть между первым и вторым касанием частицы пола прошло время t. тогда между вторым и третьим пройдёт t / 2, между третьим и четвёртым - t / 4. таким образом, если мы хотим узнать, например, промотать время на 2 * t вперёд, мы это попросту не сможем сделать, потому что время между двумя соседними соударениями в районе этой точки устремится к нулю а теперь представим, что у нас не одна частица, а десять тысяч. представляешь, с какой частотой происходят соударения?
этот метод в первую очередь ориентирован не на физически полностью корректную модель, а на модель, которая выглядит физически правдоподобной, обычно в играх именно это и требуется. просто плюс ко всему, покрутив параметры его точность можно вполне приблизить к физически более-менее достоверной.
>частицы могут не только проникать друг в руга, но и пролетать насквозь, что совсем не ловится методом позишин-бэйс.
могут, ещё как. а ещё частицы могут совпасть в одной точке пространства, а ещё скорость может перевалить за пределы точности представления чисел с плавающей точкой, а ещё все частицы в память могут не влезть, много чего может пойти не так.
>Я не критикую сам метод, а акцентирусь на некоторых моментах при которых метод может не работать.
разумеется, у этого метода, как и любого другого, есть своя сфера применения, со своими ограничениями. просто я, основываясь на своём опыте, хочу сказать, что соотношение крутости результата к количеству затраченных на его реализацию сил у этого метода едва ли не максимальное. Наверно, надо было подробнее остановиться на ограничениях метода. Пожалуй, сейчас же и поправлю.
>Буду благодарен за разьяснение термина "резолвин".
eng resolving, решение, разрешение контакта.
>ты уверен, что читал мою статью? я ж написал: "Рассмотрим обычный подход, ещё называемый velocity-based
Спокойнее. Я по поводу этого метода и говорю. Что в нем не нужны ускорения для каждой частицы. Кроме узкой фазы (Narrow phase) (Broad Phase в терминах - спасибо за ссылку), где тела вращаются (сам себя поправил).
>во-первых, "перелопачивание массива" делается вовсе не в лоб перебором. для оптимизации этого процесса есть много >достаточно эффективных методик, Broad Phase в "терминах"
Обернули группы в оболочки, которые "резолвятся" тем же перебором.
>этот метод в первую очередь ориентирован не на физически полностью корректную модель, а на модель, которая >выглядит физически правдоподобной, обычно в играх именно это и требуется. просто плюс ко всему, покрутив параметры >его точность можно вполне приблизить к физически более-менее достоверной.
>Наверно, надо было подробнее остановиться на ограничениях метода.
Да, это ключевые фразы.
Прмер скачал. Понравилось. Сколко там частиц? 4 ядра по полной нагружены.
Solve(англ.) - решать(проблему, задачу), Solver(англ.) - тот кто занимается решением задачи, решатель если без намека на правильность русского. Resolve - разрешать. А вообще непонятно какое то слово, словарик в зубы и даже если само слово переводится в словаре както далеко от нужной тематики, всеравно можно найти перевод для него в контексте текста в котором данное слово употребляется.
Suslik
Ты принципиально не замечаешь меня или это случайность? )
Небольшой вопрос, может я где что-то упустил, но расталкивание можно осуществлять лишь с точками, пусть даже точками со связями, или можно прикрутить как-то прямые?
Интересная статья, для общего развития прочитал с удовольствием. )
Интересная статья!
MarkoPolo
> Небольшой вопрос, может я где что-то упустил, но расталкивание можно
> осуществлять лишь с точками, пусть даже точками со связями, или можно
> прикрутить как-то прямые?
можно по идее прикрутить не только отрезки, но и полноценные твёрдые тела. правда, там уже будет всё не так солнечно и удобно, поэтому я забил и не стал подробно рассказывать. погугли SPE же, ссылку выше я уже давал, у них твёрдые тела на position-based.
false3d
> Интересная статья, для общего развития прочитал с удовольствием. )
AxMeT
> Интересная статья!
большое спасибо, рад, что кто-то интересуется
Suslik
ок. А вот если прямую сделать из линии малых сфер, склеенных друг с другом, по идее, раз метод предназначен для большого числа объектов, то можно не скупиться на сферы?
MarkoPolo
> ок. А вот если прямую сделать из линии малых сфер, склеенных друг с другом, по
> идее, раз метод предназначен для большого числа объектов, то можно не скупиться
> на сферы?
да, вполне. при нормальном spacial hashing'е с broad phase'ом тут на форуме кому-то удавалось 30000 плотно упакованных патиклов считать за что-то порядка 2мс. но я бы советовал всё-таки отдельный класс для отрезка ввести, потом будет проще. если вкратце, то не очень приятный метод работы с отрезками следующий:
аналогично deltaPos для патиклов, для отрезков вводим ещё понятие deltaAngle - угол, на который отрезок повернулся за предыдущий шаг. и когда выталкиваем один отрезок из другого, ищем эвристическими методами такое взаимное положение отрезков, когда они оба как бы вытолкнулись. как это делать подробнее, мне объяснять лень, желающие могут почитать в advanced character physics, там кое-как описано. ну и интегрируем по времени точно так же: pos += deltaPos; angle += deltaAngle;
Suslik
ок.
Тема в архиве.