English Новый сайт

Расширенный поиск

[ Новые сообщения · Пользователи · Правила ]
Страница 1 из 512345»
Форум » SpaceEngine » Обратная связь и предложения » Авиакосмический симулятор
Авиакосмический симулятор
BlackPhoenixДата: Суббота, 25.02.2012, 23:16 | Сообщение # 1
Космонавт
Группа: Пользователи
Украина
Сообщений: 47
Награды: 0
Статус: Offline
Я работаю над физическим симулятором. Основная цель - симуляция физики полёта в реальном времени на основе эскизных данных (т.е. на вход даются формы крыльев, фюзеляжа и т.п., либо таблица динамики, либо подключается внешняя динамика).

На данный момент я ещё не начал работать над именно этим проектом, но тот движок что сейчас есть работает на базе X-Plane (использует физику X-Plane на низких высотах, и свою на высоких). Он расширяет X-Plane до уровня авиакосмического симулятора - считает физику космического полёта, а так-же особенности скоросного полёта (нагрев).

Я пишу физический движок, но писать отрисовку ландшафта мне не хочется. Space Engine рисует ландшафт, и если бы он не вылетал так часто, как он делает сейчас - вполне подходит smile

Как альтернативный выбор я смотрю на Outerra, но мне нравится идея летать по вселенной. Плюс Space Engine работает быстро и ФПС стабилен (кроме подгрузок) - я уже поигрался с ним по этим пунктам. Да и мне только нужно двигать камеру - дорисовать всё остальное могу и сам.

Вообще в том что есть сейчас реализовано такое:

  • Физический движок, интеграция траекторий обьектов (всяких летающих), поддерживает ускорение времени (лимитировано, цель - realtime). Симулирует ступени, движение центра масс по ракете, считает трение на основе формы (очень грубо, и без физики крыльев - это делает X-Plane)
  • Моделирует форму земли и воздействие других тел вокруг (Space Engine тут был бы весьма полезным)
  • Модель высотной атмосферы (трение на "высоких" орбитах)
  • Симуляция нагрева. Примерно считает нагрев поверхности в реальном времени, на основе формы. Пока очень простая модель, но примерный результат она даёт. Симулирует распределение тепла по обшивке и теплозащите.
  • Знает про параметры материалов, из которых построен самолёт (правда пока только тепловые параметры)
  • Рисует всякие визуальные эффекты - свечение от излучения нагретого тела, плазма вокруг аппарата при входе в атмосферу, дым/выхлоп
  • Моделирует магнитное поле земли


Над чем я ещё работаю:

  • Сеть (с возможностью стыковки и совместного полёта)
  • Симулятор внутренних систем - отдельный проект
  • Редактор всего летающего - на данный момент используется редактор X-Plane


Картинки:






Использует OpenGL, C, GLSL. Ещё информация тут: http://brain.wireos.com/?tag=xspace

Чего хотелось бы в Space Engine:

  • Не вылетать
  • Не вылетать
  • Иметь возможность сунуть камеру куда хочется (из "плагина")
  • Получать координаты ближайших обьектов
  • Было бы хорошо получать геометрию ландшафта
  • Возможность рисовать с любой точки в rendertarget
  • Втыкаться в рисование Space Engine из-вне, что-бы добавить какие-то свои эффекты и обьекты
SpaceEngineerДата: Воскресенье, 26.02.2012, 00:30 | Сообщение # 2
Автор Space Engine
Группа: Администраторы
Российская Федерация
Сообщений: 5542
Награды: 54
Статус: Offline
Иметь возможность сунуть камеру куда хочется (из "плагина") - можно сделать
Получать координаты ближайших обьектов - если интересуют только планеты и солнце(а), есть
Было бы хорошо получать геометрию ландшафта - есть высота точки по координатам lon/lat
Возможность рисовать с любой точки в rendertarget - можно сделать
Втыкаться в рисование Space Engine из-вне, что-бы добавить какие-то свои эффекты и обьекты - нельзя

По сути это уже SpaceEngine SDK. Я планирую его сделать, но попозже, после выпуска игры. Использование движка SE в своих играх будет платным, так что если вы планируете бесплатную игру, будет нестыковка.


BlackPhoenixДата: Воскресенье, 26.02.2012, 01:12 | Сообщение # 3
Космонавт
Группа: Пользователи
Украина
Сообщений: 47
Награды: 0
Статус: Offline
Quote (SpaceEngineer)
По сути это уже SpaceEngine SDK. Я планирую его сделать, но попозже, после выпуска игры. Использование движка SE в своих играх будет платным, так что если вы планируете бесплатную игру, будет нестыковка.


Сам симулятор работает отдельно, просто подключается к какой-то визуализации.
DukeДата: Воскресенье, 26.02.2012, 12:33 | Сообщение # 4
Нет аватара
Первооткрыватель
Группа: Команда SE
Антарктика
Сообщений: 419
Награды: 2
Статус: Offline
А для чего разрабатывается данный физический симулятор?
BlackPhoenixДата: Воскресенье, 26.02.2012, 12:59 | Сообщение # 5
Космонавт
Группа: Пользователи
Украина
Сообщений: 47
Награды: 0
Статус: Offline
Quote (Duke)
А для чего разрабатывается данный физический симулятор?

Расчёт физики на встроеных системах, симуляция в реальном времени и в широком диапазоне параметров. Плюс возможность быстро разработать схему самолёта (положение крыльев и т.п.), полетать, экспортировать в внешний редактор (как набор параметрических кривых) и продолжить работу уже там. В этом плане очень похоже на X-Plane
НауДата: Воскресенье, 21.10.2012, 15:40 | Сообщение # 6
Нет аватара
Наблюдатель
Группа: Пользователи
Российская Федерация
Сообщений: 18
Награды: 0
Статус: Offline
Quote (BlackPhoenix)
Я работаю над физическим симулятором

попробуйте применить свои наработки в Orbiter или Kerbal space programm. в обоих случаях требуются наработки по аэродинамическому нагреву, и поведению аппаратов в атмосфере. хотелось бы увидеть плагины исправляющие эти недостатки. wink
SpaceEngineerДата: Воскресенье, 21.10.2012, 20:07 | Сообщение # 7
Автор Space Engine
Группа: Администраторы
Российская Федерация
Сообщений: 5542
Награды: 54
Статус: Offline
Кстати да, BlackPhoenix, как можно подключить вашу библиотеку? Есть документация?

BlackPhoenixДата: Понедельник, 22.10.2012, 02:07 | Сообщение # 8
Космонавт
Группа: Пользователи
Украина
Сообщений: 47
Награды: 0
Статус: Offline
Quote (SpaceEngineer)
Кстати да, BlackPhoenix, как можно подключить вашу библиотеку? Есть документация?

Как раз в процессе разработки именно новой физической библиотеки. Документацию по этой библиотеке ожидайте в скором времени (или не очень если первый вариант API не пройдёт smile ).

Старая библиотека уже не актуальна.

Я приведу вам разный код по IVSS (Internal Vessel Systems Simulator) - это фреймворк для моделирования внутрених систем. Физ движок (EVDS - External Vessel Dynamics Simulator) по философии почти идентичен.

API чем-то напоминает FMOD. На примере симулятора внутренних систем: http://www.everfall.com/paste/id.php?q4g61xe3rrhk

Для физ симулятора общая философия такая - есть обьекты, у каждого своя система координат. У каждого обьекта есть две функции (основные) - "Step", "Integrate". Первая функция обновляет общее состояние обьекта (например для ракетного двигателя пересчитывает тягу), вторая функция выдаёт производную от вектора состояния.

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

Вектор состояния - пока в разработке. На данных момент это просто вектор из компонент положения, скорости, угловой скорости, ориентации (как кватернион), и думаю ещё дополнительно произвольного набора параметров пользователя.

Можно функцию Integrate не определять - тогда обьект не будет учитываться в физике.

Отдельный класс обьектов не имеют состояния, а просто выполняют обновление состояния своих детей (т.е. обьект "инерциальная система планеты земля" и обьект "планета земля" оба производят интегрирование положения детей. Какое именно - это можно выбрать функцию подходящую).

Конфигурация задаётся как XML файл, например: http://www.everfall.com/paste/id.php?vnygy6at2evz

Поведение обьекта задаётся его типом или дополнительными параметрами. Физ. обьект представляет собой вектор состояния + набор параметров. В рантайме параметры можно только менять. Добавлять или убирать только при перезагрузке обьекта.

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

Простыми словами - просто загружаете XML файл, создаёте обьекты для локальной солнечной системы и локальной планеты (ну и соседних планет), и помещаете аппарат в обьект который есть локальная планета. Физ движок будет сам перебрасывать аппарат по правильно настроеным правилам (по этой части ещё наработок нет).

Физ движок (и симулятор систем) работают в отдельном потоке - чтение данных производится прямо во время их работы - просто текущие значения котороые возвращают функции API всегда считаются правильными на момент вызова.

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


Готовность этого всего такая:
IVSS - работает, моделировало компьютеры ракеты и третьей ступени, вывело виртуальный спутник. Вирт. спутник успешно передавал телеметрию 75 дней до окончания слежения за ним.
EVDS - пока только есть преобразование между системами координат. На данный момент пишу структуру обьекта, что-бы она хранила параметры и нормально работала в многопоточной среде.
Редактор - работает, можно даже чего-то редактировать, надо правда нормальную кнопку сохранения сделать. Редактора пока хватит на простые вещи (но глючные нормали делает):
SpaceEngineerДата: Понедельник, 22.10.2012, 06:26 | Сообщение # 9
Автор Space Engine
Группа: Администраторы
Российская Федерация
Сообщений: 5542
Награды: 54
Статус: Offline
Ещё раз по вашим пунктам:

  • Не вылетать
    Ну с этим раз от раза всё лучше:)

  • Иметь возможность сунуть камеру куда хочется (из "плагина")
    Камера в SpaceEngine хитрая. Координаты задаются в 128-битных числах с фиксированной запятой, ориентация - double кватернионом. В планетных системах поисходит переход к локальным коорбинатам в double (единица расстояния - километр, начало координат - в барицентре системы). Для рендера этого хвататет, для физики боюсь маловато будет. Я начал делать физику кораблей, столкнулся с проблемой несоответствия того что рассчитывает физдвижок и того что рассчитывает солвер орбитального движения планет. Планеты движутся как бы по рельсам - солвер сразу выдаёт барицентрические координаты и ориентацию планеты для любого момента времени, в то время как физдвижок интерирует силы и скорости корабля с каким-то шагом dt. В общем есть некая непостоянная ошибка - планеты и корабли "дёргаются" относительно друг друга с амплитудой в десятки метров. Думаю это в том числе связано с недостаточной точностью double на масштабах от барицентра системы до поверхности планеты. Для симуляции посадки и аэродинамики надо переходить в планетоцентрическую систему координат. Как я понял, у вас так и сделано, к тому же система координат ещё и вращается вместе с планетой, что в физдвижке учитывается вводом кориолисовых сил. Так?

  • Получать координаты ближайших обьектов
    Есть возможность получить координаты и ориентацию любого космического тела планетной системы в любой момент времени с точностью double (время кстати тоде в double, но планирую перейти на те же 128-битные числа).

  • Было бы хорошо получать геометрию ландшафта
    Вот тут нужно уточнить. Я так понимаю, это для проверки столкновений. Движок может сгенерировать/загрузить кусочек ландшафта любой планеты (даже в другой галактике) по заданным координатам (радиус-вектор или долгота/широта), и выдать его в виде сетки 256*256 - это карта высот определённого лода (только так, просто одну точку получить нельзя). Т.к. для генерации и рендера используется quad tree, каждый следующий лод покрывает вчетверо меньшую площадь. Т.е. выбирая, для какого лода нужно получить сетку, можно получать либо большое покрытие при низком разрешении, либо большое разрешение (до 1 метра между точками) при малом покрытии. Функция почти бесплатна для той планеты и того района, над которой в данный момент летит камера, но затратна для далёких районов планеты и очень затратна для другой планеты в другой системе/галактике (это если хотите иметь много кораблей, раскиданных по Вселенной, и чтобы для них честно считалась физика. Движок должен снегерировать всех "родителей" учатк поверхности - планету, планетную систему, блок звёздного quadree, галактику, блок галактического quadtree. Все созданные объекты кэшируются, поэтому повторный вызов функции при малом изменении координат будет опять почти бесплатным.

  • Возможность рисовать с любой точки в rendertarget
    Это есть, возможны варианты - нарисовать "вид из камеры" (обычный рендер), "вид на 3D карту" (рендер только того, что попадает в сферическую область заданного радиуса и заданными координатами центра), и вид на отдельный объект (планета, звезда, галактика, и т.д.) - для импостеров, интерфейса и т.д.

  • Втыкаться в рисование Space Engine из-вне, что-бы добавить какие-то свои эффекты и обьекты
    Вот это будет очень сложно сделать. Система рендера в SpaceEngine хитрая. На планетных масштабах нет z-буффера всей сцены, сцена режется неперекрывающиеся на слои по z (только планеты, пустота между ними выкидывается), и рендерится от дальних к ближним, с очисткой z-буффера перед каждым слоем. Т.е. если несколько планет/кораблей перекрываются по z, они получают общий z-буффер. На масштабах кораблей это иногда приводит к недостаточной точности (если с орьиты смотерть вдоль горизонта, может начаться z-файтинг). В принципе можно вклиниться в рендер на уровне кораблей. Движок предоставляет данные о источниках света - до четырёх самых ярких солнц/планет/лун (список строится и сортируется автоматически). Кроме интенсивности, цвета, относительных коордиинат и радиуса предоставляются данные о затмениях (до 4 штук на источник, посик автоматический) - относительные координаты и радиус затенителя. Т.к. движок рендерит всё в forward pipeline, каждый объект или эффект нужно рендерить с учётом освещения и затмений, т.е. надо иметь отдельные шейдеры для всех случаев (т.е. освещение, затмения и т.д. это не пост-эффект, который сам по себе возник бы). Более сложная вещь - атмосфера. Для её учёта также надо писать шейдер, ещё и правильно учесть прозрачность, и опять же 4 источника света и затмения.

  • BlackPhoenixДата: Понедельник, 22.10.2012, 11:17 | Сообщение # 10
    Космонавт
    Группа: Пользователи
    Украина
    Сообщений: 47
    Награды: 0
    Статус: Offline
    Quote (SpaceEngineer)
    Ещё раз по вашим пунктам:

    Не вылетать
    Ну с этим раз от раза всё лучше:)

    Иметь возможность сунуть камеру куда хочется (из "плагина")
    Для симуляции посадки и аэродинамики надо переходить в планетоцентрическую систему координат. Как я понял, у вас так и сделано, к тому же система координат ещё и вращается вместе с планетой, что в физдвижке учитывается вводом кориолисовых сил. Так?

    Ооо, забыл сказать. Делать расчёты в неинерциальных системах - огромная фича физ движка. Основное задание - например считать совмесный полёт двух космических аппаратов (один в инерциальной системе, второй в системе первого корабля!), либо например изгибы при стыковке и полёте ракеты (в инерциальной системе это можно только медленными итеративными способами посчитать, но для малых относительных скоростей есть например примерный vertlet метод).

    Хитрый код который переводит между системами координат - пользователь пишет, что на тело действует ускорение "a = a_user", но ведь это в системе координат обьекта пользователя. Интегратор когда собирает ускорения переводит их в свою систему координат - а ведь в его системе это "a = a_user - a_object - w' x r - 2*(w x v) - w x (w x r)". Он берёт свою угловую скорость из вектора состояния (а это вектор, который вы просто влоб задаёте в каждом шаге отрисовки - просто говорите, что линейное ускорение 0 - это будет достаточным приближением, но при этом обьекты внутри этой системы "не заметят" резкого скачка планеты за dt), угловое ускорение для планет нулевое (но можно влоб задать производную от вектора состояния).

    Камеру мне надо только задавать как-то относительно корабля. Вот хочу я поставить видеокамеру на его хвост - имею координаты камеры в локальных координатах обьекта. Пусть мне движок уже поставил камеру в reference точку аппарата - посчитать OpenGL преобразование для перевода камеры в хвост проблем нет. (правда там же наверно culling какой-то, и просто так двинуть камеру не сойдёт smile )

    reference точка может не совпадать с центром масс (reference точка это то, где у обьекта локальные 0,0,0). В этом случае локальная система координат обьекта будет неинерциальная кстати.

    Вычисления столкновений принципиально не будут поддерживаться интегратором, который считает изменение положения - для проверки столкновения с стандартным интегратором движок автоматически должен перекинуть оба обьекта во временный обьект, вектор состояния которого совпадает с первым обьектом (временная локальная система координат для двух обьектов), и этому временному обьекту назначить солвер который считает столкновения (тем-же vertletом например).

    Положение этой временной системы (а с этим и положение обьекта 1) продолжает интегрировать "планета". На первый обьект действуют нулевые неинерицальные силы (r = 0, v = 0, a_object = 0 --> a = a_user), на второй уже настоящие неинерциальные ускорения.

    В том коде, что буду писать я вычисления столкновений производятся в "Solve" (т.е. с дискретностью dt), и положение второго обьекта в инерциальном пространстве будет считаться с меньшей точностью (это приближение вполне достаточно для двух обьектов с примерно-равными орбитами).

    Для столкновений с землёй/на земле надо писать по другому - но привязки к одному методу нет, можно одновременно исползовать кучу солверов. Можно даже в неинерциальной системе планеты сделать ещё одну систему - для всяких медленных обьектов - и просто туда Bullet как интегратор поставить smile

    Такая возможность перекидывать обьекты и создавать вложеные физические вычисления есть одним из основным требований к физ движку.

    Quote (SpaceEngineer)

    Получать координаты ближайших обьектов
    Есть возможность получить координаты и ориентацию любого космического тела планетной системы в любой момент времени с точностью double (время кстати тоде в double, но планирую перейти на те же 128-битные числа).

    Это требование уже не актуально, пользователь движка сам задаёт координаты обьектов в 64-битных числах для локальной солнечной системы.

    Quote (SpaceEngineer)

    Было бы хорошо получать геометрию ландшафта
    Вот тут нужно уточнить. Я так понимаю, это для проверки столкновений. Движок может сгенерировать/загрузить кусочек ландшафта любой планеты (даже в другой галактике) по заданным координатам (радиус-вектор или долгота/широта), и выдать его в виде сетки 256*256 - это карта высот определённого лода (только так, просто одну точку получить нельзя). Т.к. для генерации и рендера используется quad tree, каждый следующий лод покрывает вчетверо меньшую площадь. Т.е. выбирая, для какого лода нужно получить сетку, можно получать либо большое покрытие при низком разрешении, либо большое разрешение (до 1 метра между точками) при малом покрытии. Функция почти бесплатна для той планеты и того района, над которой в данный момент летит камера, но затратна для далёких районов планеты и очень затратна для другой планеты в другой системе/галактике (это если хотите иметь много кораблей, раскиданных по Вселенной, и чтобы для них честно считалась физика. Движок должен снегерировать всех "родителей" учатк поверхности - планету, планетную систему, блок звёздного quadree, галактику, блок галактического quadtree. Все созданные объекты кэшируются, поэтому повторный вызов функции при малом изменении координат будет опять почти бесплатным.

    Этого будет достаточно.

    Quote (SpaceEngineer)

    Возможность рисовать с любой точки в rendertarget
    Это есть, возможны варианты - нарисовать "вид из камеры" (обычный рендер), "вид на 3D карту" (рендер только того, что попадает в сферическую область заданного радиуса и заданными координатами центра), и вид на отдельный объект (планета, звезда, галактика, и т.д.) - для импостеров, интерфейса и т.д.

    Втыкаться в рисование Space Engine из-вне, что-бы добавить какие-то свои эффекты и обьекты
    Вот это будет очень сложно сделать. Система рендера в SpaceEngine хитрая. На планетных масштабах нет z-буффера всей сцены, сцена режется неперекрывающиеся на слои по z (только планеты, пустота между ними выкидывается), и рендерится от дальних к ближним, с очисткой z-буффера перед каждым слоем. Т.е. если несколько планет/кораблей перекрываются по z, они получают общий z-буффер. На масштабах кораблей это иногда приводит к недостаточной точности (если с орьиты смотерть вдоль горизонта, может начаться z-файтинг). В принципе можно вклиниться в рендер на уровне кораблей. Движок предоставляет данные о источниках света - до четырёх самых ярких солнц/планет/лун (список строится и сортируется автоматически). Кроме интенсивности, цвета, относительных коордиинат и радиуса предоставляются данные о затмениях (до 4 штук на источник, посик автоматический) - относительные координаты и радиус затенителя. Т.к. движок рендерит всё в forward pipeline, каждый объект или эффект нужно рендерить с учётом освещения и затмений, т.е. надо иметь отдельные шейдеры для всех случаев (т.е. освещение, затмения и т.д. это не пост-эффект, который сам по себе возник бы). Более сложная вещь - атмосфера. Для её учёта также надо писать шейдер, ещё и правильно учесть прозрачность, и опять же 4 источника света и затмения.


    Втыкаться в рисование в принципе надо только для локального космического корабля. Шейдер написать не проблема, если в него будет передано достаточно информации.


    Сообщение отредактировал BlackPhoenix - Понедельник, 22.10.2012, 11:39
    НауДата: Понедельник, 22.10.2012, 12:15 | Сообщение # 11
    Нет аватара
    Наблюдатель
    Группа: Пользователи
    Российская Федерация
    Сообщений: 18
    Награды: 0
    Статус: Offline
    Quote (SpaceEngineer)
    В общем есть некая непостоянная ошибка - планеты и корабли "дёргаются" относительно друг друга с амплитудой в десятки метров. Думаю это в том числе связано с недостаточной точностью double на масштабах от барицентра системы до поверхности планеты.

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




    в начале грешил на другие небесные тела, но это не так.
    А так шикарный способ отображения траектории корабля "в динамике" smile всегда такое хотел увидеть. ну и безмерно радует возможность межзвездных перелетов, хоть и за тысячи лет biggrin
    Прикрепления: 9816056.jpg(258Kb)


    Сообщение отредактировал Нау - Понедельник, 22.10.2012, 12:24
    BlackPhoenixДата: Четверг, 25.10.2012, 20:35 | Сообщение # 12
    Космонавт
    Группа: Пользователи
    Украина
    Сообщений: 47
    Награды: 0
    Статус: Offline
    Пока занимался общей частью (менеджментом обьектов и т.п.) движка. Всё работает (можно создавать обьекты и задавать им параметры), правда пока нету самих "вычисляторов" что-бы что-то считать, и нет загрузки из XML.

    Движок заточен под многоядерные системы. Текущий приоритет - отладить переход между системами координат, дописать его полностью, написать простое интегрирование по RK4 и простое суммирование сил & масс.

    Вероятно, что каждый обьект будет пересчитывать свой центр масс и моменты инерции (если необходимо), затем переводить силу в ускорение вокруг ЦМ - и переводить из системы центра масс в систему относительно reference point. Т.е. координаты просто вращающегося (без трансляционного движения) обьекта будут описывать круг (если центр масс не в правильном центре.

    API сейчас такой (исключая математику): http://www.everfall.com/paste/id.php?8i7hm2bvaa7u (уже есть функции работы с обьектами).
    SpaceEngineerДата: Четверг, 25.10.2012, 21:28 | Сообщение # 13
    Автор Space Engine
    Группа: Администраторы
    Российская Федерация
    Сообщений: 5542
    Награды: 54
    Статус: Offline
    У меня API никакого ещё нет. Думаю начать праллельно делать вторую игру (стратегию о колонизации и терраформировании Соленчной системы), тогда сразу станет понятно, что требуется от API.

    Nikita11Дата: Четверг, 25.10.2012, 22:21 | Сообщение # 14
    Строитель Миров
    Группа: Пользователи
    Российская Федерация
    Сообщений: 762
    Награды: 4
    Статус: Offline
    Quote (SpaceEngineer)
    начать праллельно делать вторую игру (стратегию о колонизации и терраформировании)

    Скорей бы, а то на эту тематику игры либо военные, либо несеръёзные.
    BlackPhoenixДата: Вторник, 06.11.2012, 21:42 | Сообщение # 15
    Космонавт
    Группа: Пользователи
    Украина
    Сообщений: 47
    Награды: 0
    Статус: Offline
    Новый заголовочный файл (т.е. публичное API): http://www.everfall.com/paste/id.php?umdpfs1y33nc

    Симулятор уже может считать изменение положения со временем. Обьект типа "судно" считает притяжение от центра текущей системы координат (это пока просто хак - потом будет притяжение от всех планет в системе), считает ускорения за силами в обьектах-детях судна, выдаёт интегратору ускорения.

    Пример интегратора (пропагатора) за рунге-кутта 4 порядка: http://www.everfall.com/paste/id.php?tb7rxwa3hh8z (пока только положение интегрирует)

    Пример использования симулятора: http://www.everfall.com/paste/id.php?639a6cgjxm9h
    Форум » SpaceEngine » Обратная связь и предложения » Авиакосмический симулятор
    Страница 1 из 512345»
    Поиск:

    >