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

Гравитация при х/0 и х/100500 (2 стр)

Страницы: 1 2 3 Следующая »
#15
21:48, 9 дек. 2019

slepov
> Почему бы просто не взять готовое двигло аля Bullet? Заодно покажите как
> интегрировать свою ламповую графику с чем то сторонним.
Как раз таки Bullet под задачу N тел не нужен чуть более, чем полностью. Это как для того, чтобы посчитать 2+2 использовать Word.


#16
22:24, 9 дек. 2019

MrShoor
> Как раз таки Bullet под задачу N тел не нужен чуть более, чем полностью.

Ога..в курсе по _графике_ начать писать про то почему надо ввести радиус, зачем там твоя очередь с приоритетами и т.д. и т.п. Поучили Графике. Экзель кстати запускают чтобы суммировать всякую х..ню и не парятся.

#17
22:52, 9 дек. 2019

slepov
> Ога..в курсе по _графике_ начать писать про то почему надо ввести радиус, зачем
> там твоя очередь с приоритетами и т.д. и т.п.
В курсе по графике вообще задачу N тел не стоит считать.

> Экзель кстати запускают чтобы суммировать всякую х..ню и не парятся.
Хорошо, как ты себе представляешь решение задачи N тел на Bullet? Опиши.

#18
23:04, 9 дек. 2019

MrShoor
> Хорошо, как ты себе представляешь решение задачи N тел на Bullet? Опиши.
>
Создаешь N тел с геометрией сферы радиуса R (того самого где не хочется делить малые радиусы).
К каждому телу на каждом шаге прибавляешь N-1 сил. Вот это проблема да, ибо квадратичная сложность на этапе расчета поля. Но она и в твоем случае не решена. Подозреваю distance fields, в котором ты явно преуспел, будет как раз к месту. Но по крайней мере Bullet решит проблему столкновений (не надо лепить квадродерево из г-на и палок), и даже может проблему больших сил (интегрирование там не тупо x += v*dt)

#19
23:52, 9 дек. 2019

slepov
> Но по крайней мере Bullet решит проблему столкновений (не надо лепить
> квадродерево из г-на и палок)
Вот только проблема там не со столкновениями, а таки с большими силами. Наличие радиуса только частично скроет эту самую проблему.

> и даже может проблему больших сил (интегрирование там не тупо x += v*dt)
Именно в такое интегрирование оно и вырождается, если между телами нет столкновений. Есть addForce, который ты сам считаешь. Есть stepSimulation в который ты подставляешь дельтатайм. И сила, которую ты приложил в addForce действует весь dt. Так что bullet в этом случае только мешает сделать переменный dt для объектов.

#20
0:23, 10 дек. 2019

MrShoor
> Наличие радиуса только частично скроет эту самую проблему.

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

#21
0:50, 10 дек. 2019

slepov
> Ты о том что большие силы вызовут большие скорости и шаг надо меньше? Я давно
> ковырял буллет, кажется там было чтото посложнее умножения на шаг..
Причем тут посложнее умножения на шаг? Да, там внутри посложнее, чем просто умножение на шаг, там подшаги есть. Но силу ты задаешь 1 раз снаружи, и она не меняется весь stepSimulation.

> имеешь сокральные знания темы - пиши пейпер почитаю.
Там нет никаких особых сокральных знаний. Все что нужно сделать - я уже описал. В priority очередь пушишь объекты с временем симуляции следующего шага. Достаешь самые ближние по времени объекты, симулируешь, оцениваешь dt для них, заталкиваешь обратно в очередь.

#22
(Правка: 1:03) 1:01, 10 дек. 2019

slepov
Вот тебе псевдокод:

while (true) do {
  queue.pop(nextime, obj); //вытаскиваем с очереди ближайший объект для симуляции
  dt = nextime - currtime;
  if (dt > 0) { //если время изменилось - двигаем все объекты на dt с учетом текущих сил
    foreach(obj in objects) {
      obj.MoveBy(dt);
    }
  }
  new_force = EvalForce(obj); //вычисляем силы, влияющие на данный объект
  obj.dt = EvalDetlaTime(obj.current_force, new_force, obj.dt); //оцениваем dt по разнице текущей и предыдущей силы
  obj.current_force = new_force;
  queue.push(nextime + obj.dt, obj); //кладем обратно в очередь с новым временем симуляции
  currtime = nextime;
}
#23
2:23, 10 дек. 2019

slepov
> Нахрена для курсов по графике такие замуты? вы же графике учить взялись а не
> физике.
Это что-то типа промежуточных итогов.
Суть не столько в физике, сколько в технологиях которые там будут задействованы, типа вычислительных шейдеров и инстансинга с ubo/ssbo.

> Почему бы просто не взять готовое двигло аля Bullet?
Он тяжелый и у него свои нюансы. Да и смысла тащить физдвиг нет, т.к. в примере нужны не столкновения а вычислительные шейдеры.

#24
10:47, 10 дек. 2019

Great V.
> т.к. в примере нужны не столкновения а вычислительные шейдеры.


ыы.. т.е. курс то не совсем уж и по графике. Интересно как тогда очередь с приоритетом, предлагаемая MrShoor,  зайдет в шейдер.

#25
11:04, 10 дек. 2019

MrShoor
> Но силу ты задаешь 1 раз снаружи, и она не меняется весь stepSimulation

Конечно не меняется. А при решении системы дифф уравнений она меняется чтоли? На каждом шаге мы все равно вынужденны иметь дело с неким фиксированым состоянием. Поэтому я не пойму причем тут большие силы, и чем Буллет не угодил в задаче N тел. Ты предлагаешь какой то свой метод с очередью с приоритетами.. ну может он и клевый, я не знаю, а разбираться причин нет и времени.

>queue.push(nextime + obj.dt, obj); //кладем обратно в очередь с новым временем симуляции

Понятно, твоя очередь автоматически уменьшает  шаг там где надо. Ну круто, наверно. Я бы просто уменьшал общий шаг для всей системы. А чтобы не пересчитывать след. состояние заного там где не надо - так это на уровне объекта можно решать. Тем более ТС вон говорит что по шейдерам пишет на самом деле чтото, а как там быть с очередью по приоритетам - я хз. В общем твоя алг понятен, спасибо за потраченое время.

#26
12:28, 10 дек. 2019

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

#27
(Правка: 19:17) 19:13, 10 дек. 2019

slepov
> Интересно как тогда очередь с приоритетом, предлагаемая MrShoor, зайдет в
> шейдер.
Да легко. Сделай фиксированные dt, под каждый dt заведи свой бакет, и складывай туда через InterlockedIncrement. Бакеты зацикли.

> На каждом шаге мы все равно вынужденны иметь дело с неким фиксированым
> состоянием.
У меня шаг переменный. Буллетом ты этого не сделаешь. Чтобы сделать переменный шаг - тебе всё равно придется городить очередь с приоритетом вокруг буллета. И в результате ты Буллет будешь использовать исключительно для: v = v0 + a*dt; x = x0 + v*dt;
А для этого тянуть Буллет - равно как для того, чтобы посчитать 2*2 тянуть Word.

> В общем твоя алг понятен, спасибо за потраченое время.
Да не за что. Главное, что мои объяснения в целом оказались понятными.

#28
20:48, 10 дек. 2019

MrShoor
> и складывай туда через InterlockedIncrement. Бакеты зацикли.

InterlockedIncrement - это ж лочит потоки, не понял. Не знаю что такое бакет.

>if (dt > 0) { //если время изменилось - двигаем все объекты на dt с учетом текущих сил

Вот это смущает. Это условие же всегда будет выполняться. Иначе система как то зависает.
А если оно всегда выполняется то и всегда делаем цикл по объектам:

foreach(obj in objects) {
      obj.MoveBy(dt);
    }

Дальше ты в очередь снова кладешь какое то время. Итого, вытаскиваешь кладешь, вытаскиваешь кладешь. А в результате все равно каждую итерацию обходишь каждый объект. Чтото тут не так. Поэтому у меня сомнения - а зачем тогда очередь? Ну определяй просто размер минимального шага как min dt по всем объектам.

#29
23:51, 10 дек. 2019

slepov
> InterlockedIncrement - это ж лочит потоки, не понял.
Это неблокирующие атомарные функции:
https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/interlockedadd

> Не знаю что такое бакет.
Бакет - элемент массива, куда можно складывать другие элементы.
Грубо говоря заводишь массив массивов. По одному измерению - время, по второму - индексы объектов. Открой любую имплементацию hash map-ы с closed addressing и посмотри как реализованы бакеты там.

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