Симулятор. Крэши.

А в шоке, чувствую себя дебилом не на что не способным. Это ведь не с нуля делалось, те каки то библиотеки использовались ?

Это ведь не с нуля делалось, те каки то библиотеки использовались ?

Не всё с нуля. Про библиотеки я писал в начале моих симуляторных записей. Правда после этого сменил графический и физический движки. Изза этого сроки как всегда сдвинулись. Зато увеличилось число фич.

Упругость присутствует практически всегда. Другое дело - её степень.
А иначе получается “абсолютно неупругий конь” 😃

Совершенно “дебильно”, как стеклянные, рассыпаются на мельчайшие обломки лопасти в Фениксе (2.5) 😃 Ни разу такого не видел (дерево - понятное дело) в жизни на карбоне. Как правило, лопасть “пополамит”, “раскрывает”, ну может пару кусочков отлетит ещё…

Лопасти я пока ломать вообще не буду. Т.к. они в реальности действительно, хоть и заламываются (даже на дереве - пленка) всеравно в основном держат форму.

Имел ввиду именно тушку, когда строго носом в землю. В среднем, при крэше с большой вертикальной скоростью вертолет обычно не отскакивает высоко (демпфирует кабина, валы, трава, грунт).
У меня на видео это не показано, но косяк есть.

Да вот же, буквально вчера “в тему” пришлось, дал ссылку на запись своего “крайнего” краша на 450-ке бесфлайбарной.
rcopen.com/forum/f107/topic167686/282

Оторвало в полёте самодельный рычаг цапфы.
Повреждения стандартные (валы в башке) + подкосы выскочили из крепежа и немного погнуло балку. Лопасти целы.

А верт - почти и не подпрыгнул на земле 😂 , подстрелило его “наповал”!

ИМХО конечно, но модель повреждений имеет смысл только с точки зрения выработки навыков “контр-аварийного” управления.
Скажем - отказ хвостового ротора, обламывание шасси (на авторотации частая болезнь), отказ двигателя/трансмиссии, может ещё что…
В случае более серьёзных повреждений - пилот всё равно может только наблюдать за падением, никак не влияя на его последствия.
Тогда “встаёт” вопрос - а нафига эта “красота” будет нужна? Только “для прикола”, не более того. 😃

Да вот же, буквально вчера …

Вам везет в Европе. А у нас уже 2ой месяц выше -20 не поднимается.
Какие там полеты. Выходить на улицу не хочется. Передатчик пылью покрылся.

Зато мобилизует на программирование 😁.

feature request: если будет генератор неполадок в вертолёте - сделать эмуляцию заглючившего гироскопа: резкиё дергания хвостом, дрейф хвоста, увод хвоста на фигурах.

Ну на самом деле дерганье хвоста, дрейф это штатная ситуация. Вопрос в величине этих процессов 😃
Этим уже занимаюсь.

Ну идея ясна, да? 😃
А то обычно эмулируется заклинившая серва, и отключение двигателя. А про гироскоп все почему-то забывают. Пусть при соответствующей опции, например, хвост время от времени сам по себе дергается в какую-нибудь сторону. Это будет сюрпризом во время многих фигур, особенно тех что хвостом вперед.
По-моему такие вещи в симуляторе нужно тренировать.

Да, но в полном объеме это будет напотом.
Сейчас добиваюсь просто штатной работы системы, а ее основная логика такова, что есть torque (вр. момент) ОР, есть антиторк ХР. Под воздействием загрузки ОР (ц и к шаги, скорость воздуха, мощность, просадки батарейки итд) обороты силовой установки системы плавают, но поскольку кривые функций torque(RPM) (а для ХР нужно еще учитывать и tail pitch) этих вращающих моментов различны, и в дело вступают говернер и и гироскоп с хвостовой машинкой, и в те моменты, когда (MainRotorTorque ≠ TailRotorTorque * -1) и возникает увод хвоста.

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

Но пардон, я немного увлекся внутренней релизацией.

Да ладно, внутренняя реализация - это интересно 😃 Я одно время работал программистом в игровой индустрии, так что мне интересны и внутренние детали. Рассказывай 😉
Кстати, заходи на heli-spb.ru/forumheli, там можно устроить конструктивное обсуждение симулятора, услышать пожелания. Людей там мало, но зато общение в конструктивном русле. Тебе там будут рады!

К сожалению времени пока нет. Израсходовал его квоту на дурацкую болтовню в курилке. Больше туда не ногой.

Да, на heli-spb загляну.

Просто уже видимо скоро выложу для скачивания. Хотел вначале узкое тестирование сделать, но пусть уж сразу побольше косяков вылезет.
Просто есть вопросы по железу, как оно будет на Вистах, В7. На дохленьких видюхах.

Я бы не парился с отскоками. Можно хоть ядерный взрыв анимировать при краше. На качество симулятора не влияет.

На неделе еще раз окидывал мутным взглядом Blender - IMHO, есть смысл заценить, подойдет ли его графика и физика. Это бы решило вагон вопросов по портабельности, лицензиям, и инструментарию.

Виталий,

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

Но очень слабый набор API. Физика (и вообще вся автоматизация среды) там реализована через питон, и не предназначена для серьезного realtime рендеринга. Можно очень красиво отрендерить (в оффлайне) красивый и реалистичный фильм в виде MPEG. Даже можно с минимальным качеством сделать простую аркадную 3D-платформер стрелялку.

Но качественый симулятор не потянет (по моим оценкам).

На отскоках в принципе уже поставлена точка. Т.е. после представленного на видео варианте сделал доработки и отложил.

Оценка строилась именно по последним версиям? Сейчас в линуксовых инструментах каждые несколько месяцев гиганские улучшения идут. Посмотрите, есть ли у этого принципиальные ограничения: bulletphysics.org/wordpress/

Скрипты в реалтайме не всегда проблема, смотря как на них связки делать. Если будет серьезный разговор за опенсорц, я готов на доработки того же блендера, скажем, 10к$ личных денег потратить и людей найти, которые пофиксят необходимое.

По реальной физике (физике полёта) и реалтайме просится такая модель:
Не реалтайм обсчёт сложной физики для модели (построение интерполяционных таблиц сил и моментов в их связи с воздействиями), может быть даже в сторонних пакетах/приложения.
И потом - реалтайм полёт по ним.

В таком варианте а) может быть весьма высокая достоверность физики
и б) невысокие требования/загрузка в реалтайме.

Но, такая схема лишает быстрого и простого редактирования модели.
Точнее, вводит продолжительную фазу обсчёта отредактированой модели, если физика считается в симе.
И конечно, нужно их (таблицы) - хранить в самой моделе или её компонентах. Это уже вопрос формата.

Это вопросы в современных пакетах уже решены. Физика и графика считаются в разных компонентах и разных потоках. И можно отбрасывать кадры, сохраняя непрерывность физических процессов. Также есть плагины, которые обсчет графики переносят на GPU.

Я потому и удивился, что скрипты могут стать узким местом. На ютюбе можно найти немало демок по запросу “blender realtime physics performance” и “bullet engine realtime physics”. Сомневаюсь, что скрипты тормознут обсчет вертолета сильнее, чем на сценах, что я видел.

Вот если у bullet engine есть какие-то принципиальные ограничения - тогда другое дело. Но это я оценить не могу - не спец.

Пробовал ODE, потом перешел на Newton, изучал Bullet (на момент изучения по многим отзывам он был нестабилен) и PhysX. На самом деле они все очень похожи.

Остановился на Newton.
Хоть и без исходников, но мне вполне подходит. Кросплатформенный, стабильный, как и все остальные, используемые мной компонеты под лицензией ZLib: используй как хочешь, даже необязательно (хоть и желательно) упомянать авторов.
Ну и определяющее для меня: в целом он работает для моего приложения.
Когда(если) перестанет устраивать, буду думать.

Ну чтож.
Разработку физики пока приостановил (не то, чтобы всё сделано - а просто есть други задачи).
Занимаюсь доведением структуры и форматов файлов, их загрузчики, организация каталогов и т.д - в общем т.н. “packaging”.
На самом деле самая муторная часть.