Но вообще есть у меня дурацкая задумка. Т.е. далеко не факт, что ее стоит реализовывать. Но в общем итоге - стрельбу производить реальными снарядами: т.е. берётся два или четыре полигона, им присваивается масса и скорость. А дальше согласно третьему закону Ньютона рассчитывается сила воздействия снаряда на объект. Конечно это может создать слишком большую нагрузку на сервер и на клиент. Если так, то тогда по-старинке - рассчёт попадания и отрисовка красивого патикла.

В будущем - немного физики для обсчёта посадок на планеты и луны. Но это уж совсем в будущем.

Про поблемы синхронизации ничего сказать не могу, потому что о них ничего не знаю ), но могу предложить только обсуждение здесь и, в итоге, выбор соответствущей стратегии (свой движок vs PandaODE)

• 1) Обноружение столкновений с "логической точки зрения".
  Под этим я понимаю реакцию логической части объектов на столкновения, например: взрыв ракеты при столкновении с другим объектом, стыковка корабля - станции при их соприкосновении в соответствующих точках и т.п.

• 2) Обнаружение столкновений с физической точки зрения. Это то, о чём я писал в предыдущем посте ( т.е. моделиррвание Ньютоновской физики в части реакций на столкновений)

  В принципе, оба типа обнаружениня столкновения можно объединить. Основное их отличие в реакции на событие столкновения

• 3) Моделирование Ньютоновской физики по части воздействия сил на объекты, их масс и т.п.
  Это что-то вроде обработки следующей ситуации: У нас есть корабль с массой m с движком, котрый обеспечивает тягу с силой F1. Есть у нас ещё поворотные движки, со своей тягой F2 и т.п. Необходимо найти линейную и угловые скорости, при этом учитывая положение двигателей относительно корабля
  

• 1) Есть ODE - он написан на C.

• 2) Eсть PandaODE - это Python binding для ODE, созданный разработчиками Panda3d. Он представляет собой написанный на C++ враппер для С кода с последующими binding'ами C++ код --- Python. Он работает в терминах Panda3d примитивных типов, т.е., например, векторы, матрицы и т.п. совпадает как у Panda3d так и у PandaODE ( что понятно, т.к. PandaODE по сути часть Panda3d). Это большой плюс, это понятно.
  Но есть и минус у PandaODE. Не вдаваясь в подробности, скажу, что, в соответствии с классификацией в предыдущем посте, есть тут трудности с реализацией столкновений с логической точки зрения. А именнно: мы не можем задавать свои callback'и на столкновение двух тел, потому что, по какой-то причине, разработчики не стали предоставлять в Python коде вызов, позволяющий изменить callback, который есть в C++. Соответственно, приходится пользоваться стандартным callback'ом, работа которого заключается в обнаружении столкновений с физической точки зрения, и только.
  Чтобы получить функциональность, позволяющюю изменять callback, необходимо то ли перекомпилировать Panda3d, то ли как-то перербатывать её Python код. Кароч там дебри сплошные (мот вы и разберётесь, у меня терпения не хватило ).

• 3) Есть ещё PythonODE - это полнофункциональный враппер для ODE. Проблема в нём в несоответствии примитивных типов в нём и Panda3d. На склоько я помню в PyhtonODE вектор - это просто tuple (x, y, z) и т.п. Если браться за этот вариант, то придётся хитрить с конвертированиями и т.п. что не есть хорошо (. Зато он обладает всеми возможностями родного C ODE.
  

Жду комментариев

------------------------------------

Поясняю проблемы с синхронизацией:
Если обрабатывать всю физику только на сервере, то для более-менее крупного мира потребуется суперкомпьютер.
Если обрабатывать физику у клиентов, то проведите простой эксперимент - сделайте сцену с 10 падающими на плоскость кубиками, 10 цилиндрами, и 10 шарами и запустите её несколько раз с одинаковыми параметрами (но желательно на разных компах) - несмотря на одинаковые параметры результат окажется разным. Это происходит из-за погрешностей в симуляции. Для компенсации этих погрешностей даже на одной машине приходится использовать пачку ухищрений. А теперь представьте какой трафик придётся генерировать чтоб синхронизировать все объекты? Для каждого тела - положение, ориентация, угловая и линейная скорости, аккумулятор сил, состояние соединений.

Добавлено (18.02.2009, 12:51)
---------------------------------------------
Да и вообще постоянное принудительное задание состояния системы вызовет нестабильность и выглядеть это будет страшно глючно - для примера попробуйте поиграть в Halo на медленном соединении

Ага, ты собираешься переписать ODE? ))))

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