Трехмерная визуализация в тренажерах подвижного состава на базе движка OpenSceneGraph



    Чуть меньше года назад увидела свет публикация, где мы рассказывали об учебно-лабораторном комплексе (УЛК) электропоезда ЭС1 «Ласточка», разработанном нашем университете. Тогда я обещал, что это будет не последняя публикация на данную тему, в частности грозился рассказать о проблемах создания трехмерной визуализации для подобного рода симуляторов и очертить основные подходы к их решению.

    Прошедший год порадовал нас очередным релизом — УЛК высокоскоростного электропоезда ЭВС2 «Сапсан», который состоялся ещё в августе прошлого года. Сам по себе учебно-лабораторный комплекс данного электропоезда заслуживает отдельного рассказа, но в контексте этой публикации речь пойдет о наболевшем — проблеме создания адекватной подсистемы трехмерной визуализации, к решению которой наша команда подступалась с разных сторон около двух лет. Релиз симулятора «Сапсана» знаменателен (среди прочего) и тем, что определил вектор развития наших разработок в этой области.

    1. Кратко об УЛК ЭВС2 «Сапсан»


    Хочу подчеркнуть ещё раз (что я делаю с завидной периодичностью) что учебно-лабораторные комплексы подвижного состава, разрабатываемые в нашем университете, не предназначены для подготовки локомотивных бригад. Как справедливо заметил один из комментаторов предыдущей статьи, наши УЛК являются не тренажерами, а симуляторами, где основной упор делается на грамотную реализацию физики движения поезда и моделирование работы подсистем подвижного состава, обеспечивающих его движение и остановку. Не является исключением и симулятор «Сапсана», на котором решены следующие задачи:

    • Реализована динамическая модель механической части поезда с учетом продольных сил и профиля пути
    • Построена подробная компьютерная модель работы ключевых подсистем электропоезда: силовой электрической схемы, тягового электрического привода, пневматических и электропневматических тормозов
    • Воспроизведены основные алгоритмы работы системы управления электропоездом на разных уровнях

    Кроме того, учебно-лабораторный комплекс имеет в своем составе полноразмерный макет кабины электропоезда с основными органами управления и средствами отображения информации. В отличие от тренажера «Ласточки» эта кабина не изготавливалась нами самостоятельно, а была приобретена в 2015 году у одной известной в нашей стране конторы, занимающейся выпуском учебных тренажеров. Поэтому в процесс разработки симулятора сосредоточился на создании программного обеспечения.

    Фото кабины
    Общий вид интерьера кабины


    Вид через лобовое стекло


    Дисплей комплексного локомотивного устройства безопасности (КЛУБ-У). Красное «290» — это текущее ограничение скорости, получаемое из электронной карты КЛУБ-У. Пока здесь красуется предельная скорость, достигнутая «Сапсаном» на Октябрьской железной дороге. В будущем электронная карта будет реализована так, как это сделано в жизни


    Главный дисплей «Интерфейс человек-машина»


    Дисплей индикации состояния тормозной системы электропоезда


    Задатчик скорости и контроллер тяги


    Контроллер управления тормозами электропоезда


    Тумблеры управления токоприемниками и аппаратами защиты (БВ/ГВ) — черные тумблеры около задатчика скорости


    Интерфейс управления тренировкой — экран выбора маршрута движения


    Экран управления громкостью аудиоэффектов


    Счетчик пробега. С его появлением связана забавная история. Когда мы сдавали первый наш тренажер тепловоза 2ТЭ116, на наш вопрос когда будет подписан акт выполненных работ представитель заказчика отшутился: «Ну, давайте поступим как в жизни — при вводе нового локомотива в эксплуатацию он должен пройти 5000-километровый пробег. Вот пройдет...». Акт конечно был подписан намного раньше, но мы, оценив юмор ситуации, сделали подобный счетчик уже на тренажере «Ласточки». Счетчик можно сбросить в «0» введя сервисный пароль.


    Правая вспомогательная панель с контрольными манометрами тормозной системы и клапаном экстренного торможения. Здесь установлены не все элементы присущие настоящему «Сапсану» — такой пульт был получен нами от поставщика


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


    Разработка ПО подобного тренажера-симулятора вопрос очень широкий, и я постараюсь (в меру разумного) удовлетворить интерес читателей к этим вопросам в будущем (если таковой появится), но пока что, вернемся к основной теме статьи — трехмерной визуализации процесса движения поезда.

    2. История вопроса и технологии прошлого


    В комментариях к прошлой статье был задан вопрос, который, признаюсь честно, изрядно меня позабавил. Да, действительно, во многих, до сих пор эксплуатируемых сегодня тренажерах до сих пор применяется такой подход: снимается видео на реальном участке железной дороги, а затем прокручивается на тренажере со скоростью, пропорциональной скорости движения. Так делали только потому, что в те далекие времена, когда подобные тренажеры создавались, качество трехмерной графики, оставляло желать лучшего, причем это касалось и суровых графических станций на коммерческих юниксах, а уж о ПК и речи не шло. Поэтому, даже производители компьютерных игр, например вот этой, не гнушались использовать такой подход.

    На сегодняшний день это не имеет смысла, потому что:

    1. Недостаточная частота смены кадров на низких скоростях движения поезда не обеспечивает нужной плавности обновления картинки. Заветные 25 fps мы будем иметь только при той скорости, на которой снималось видео из кабины машиниста. И этот фатальный недостаток ничем не преодолеть — ни съемкой скоростной камерой (сколько будет весить видео, снятое на 120 кадрах в секунду? То-то же...), ни программной генерацией промежуточных кадров. Последнее предпринималось нами с использованием технологии OpenCV, но к нормальным результатам не привело. Этот вопрос многократно прорабатывался со всех сторон и в итоге был сделан вывод, что затраты ресурсов на создание такой системы намного превышают разработку аналогичной системы, но на базе 3D-графики
    2. Трудности с плавной прокруткой видео назад. И даже учитывая, что они будут преодолены, то куда побегут бежавшие по перрону собаки, вздумай мы поехать задним ходом?
    3. Отсутствие всяческой «интерактивности». Как быть со сменой сигнала светофора, с движением стрелочных переводов, движением встречных и попутных поездов?

    Поэтому все современные тренажеры и симуляторы создаются с применением интерактивной 3D-графики, благо сегодня нет никаких препятствий ни с программной, ни с аппаратной точки зрения.

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

    3. Графический движок против игрового движка или почему был выбран OpenSceneGraph


    Могу ошибаться, но заранее предчувствую комментарии, в которых будет задаваться вполне закономерный вопрос, почему при анализе существующих технологий наш выбор не остановился на таких мастодонтах как Unity или Unreal Engine 4? Я отвечу на этот вопрос, более того, я обосную свой ответ.

    Кратко — ни Unity ни Unreal Engine не удовлетворяют требованиям решаемой задачи. Более подробный ответ предусматривает, прежде всего перечисления тех требований, о которых идет речь. ТЗ, составленной нами на подсистему трехмерной визуализации, включает в себя (в порядке убывания значимости) следующие положения:

    1. Независимость процесса разработки ПО подсистемы визуализации и процесса создания ресурсов для неё. К ресурсам, в данном случае, относятся трехмерные модели, текстуры, а так же так называемые маршруты. Под маршрутом понимается совокупность объектов конфигурации и ресурсов, позволяющих видеоподсистеме отобразить желаемый участок железной дороги и обеспечить симуляцию движения поезда по нему. Сюда же стоит отнести и возможность смены маршрута без пересборки программной части видеоподсистемы
    2. Создание маршрутов неограниченной протяженности. Оговорюсь, что неограниченная протяженность в принципе недостижима по причине ограниченности аппаратных ресурсов. Данное требование следует понимать, что протяженность маршрута должна быть как минимум в пределах одно «плеча», то есть участка дороги между оборотными пунктами, а это, в зависимости от разных факторов достаточно большое расстояние, исчисляемое не одной сотней километров. Это требование накладывает необходимость обеспечивать динамическую загрузку/выгрузку ресурсов программы с достаточной плавностью при разумном потреблении памяти. И желательно, чтобы движок содержал такой функционал «из коробки»
    3. Удобная интеграция с используемым стеком технологий. Традиционно, в силу опять таки причин объективных, для разработки ПО УЛК ПС в нашей команде используется язык C++ с фреймворком Qt, в качестве IDE QtCreator, а в качестве системы контроля версий — Git. В качестве системной платформы УЛК ПС используется ОС на базе ядра Linux

    Что же не так с Unity и UE? Что тот, что другой движки способны импортировать ресурсы совершенно разных форматов. Однако при сборке проекта происходит их необратимое преобразование во внутренний бинарный формат, делающее невозможным добавление и изменение ресурсов без повторной сборки проекта. Технологии типа prefabs и asset bundles, доступные в Unity не решают задачу, так как редактор движка — не лучшее место для создания железнодорожных локаций, из-за чего возникает потребность расширения редактора, что приводит к необходимости писать «движок внутри движка». Кроме того, создание префабов и бандлов невозможно без применения редактора Unity, а это, как показала практика, не слишком удобно, особенно для чистых моделлеров и левел-дизайнеров. Что же касается UE, и на этом и на других ресурсах за два года мной было задано достаточно вопросов, о том как отделить процесс сборки проекта от процесса добавления/изменения используемых им ресурсов, и адекватного ответа я не получил ни в документации, ни от «матерых» геймдевелоперов. Буду очень рад (без сарказма) если меня аргументировано натыкают носом во что-то, что было мной упущено.

    Что касается второго требования, то и Unity и UE вроде как обеспечивают возможность создания динамически загружаемых локаций, но остается нераскрытым вопрос, каким образом подобные локации можно создавать независимо от редактора и без пересборки проекта? Выход один — писать «движок внутри движка», который будет загружать «сырую» (в любом из наперед заданном формате экспорта из 3D-редакторов) геометрию и текстуры, применять к ним все необходимые эффекты и позиционировать в пространстве опираясь на данные, описанные в стороннем, независимом от движка формате, который нужно ещё разработать и научить движок его интерпретировать.

    В связи с вышеперечисленным возникает вопрос — если для решения поставленной задачи необходимо писать мощную программную прослойку над игровым движком, большая часть функциональности которого в рассматриваемой задаче просто не нужна, то зачем нужен игровой движок?

    Может быть достаточно графического движка? Этот вопрос я задавал предыдущей команде, бравшейся за обсуждаемую проблему опираясь на Unity (и закономерно слившейся чуть позже). В ответ получил встречный вопрос: «А что предлагаете вы?», ответив на который в духе приведенного выше текста получил саркастическую улыбку оппонента.

    Если обойтись без сарказма, то представленная задача является типичной задачей визуализации — здесь требуется только фреймворк для работы с графикой, так как и физика, и аудиоподсистема, опирающаяся на физику реализованы на серверной стороне. Я и моя команды пришли к пониманию этого факта двигаясь по инерции предыдущих разработчиков сначала в сторону Unity, через UE и попытки прикрутить графическую подсистему от оного из открытых железнодорожных симуляторов (OpenBVE, что кстати получилось, но стало временным костылем)

    OpenSceneGraph является на сегодняшний день самым развитым (из открытых и бесплатных) графическим движком, ориентированным на C++ разработку. Он достаточно широко применяется за рубежом именно для технической трехмерной визуализации. Этот движок не обошли стороной и разного рода симулятора, наиболее известный из которых — FlightGear. Некогда существовал и железнодорожный симулятор на базе этого движка — Indra, от которого, впрочем, остались только унылые скриншоты по вышеприведенной ссылке и его дальнейшая судьба мне неизвестна.

    В контексте решаемой задачи графический движок OSG обладает следующими положительными качествами:

    • Кроссплатформенность, что делает возможным применить его в экосистеме GNU/Linux
    • Язык разработки C++/STL, что дает возможность легко и непринужденно интегрировать его в устоявшийся в нашей команде технологический процесс разработки;
    • Широчайший спектр поддерживаемых «из коробки» форматов ресурсов — 3D-геометрии и текстур за счет развитой системы плагинов. Простой и понятный интерфейс написания собственных плагинов для настройки менеджера ресурсов на нестандартные форматы, чем мы и воспользовались (об этом я напишу ниже);
    • Система управления памятью на основе собственной модели умных указателей (собственный формат умных указателей используется исторически, в связи с тем что в начале разработки движка умных указатель в стандарте C++ не было);
    • Гибкая модульная архитектура;
    • Диспетчер объектов сцены, выполняющий динамическую загрузку объектов, обеспечивающий загрузку и отрисовку только тех объектов, которые попадают в пределы пирамиды отсечения (за счет класса osg::PagedLOD)
    • Возможность интеграции с фреймворком Qt. Благодаря удобной модели «сигналы — слоты», предоставляемой Qt, существенно упрощающей и ускоряющей разработку на C++, мы широко применяем данный фреймворк для разработки ПО тренажерных комплексов. Соответственно, у нас накоплена значительная повторно используемая в разных проектах кодовая база, особенно это касается библиотеки межпроцессоной коммуникации на базе TCP-сокетов. Использовать возможности Qt и в проекте видеоподсистемы представляется вполне логичным решением;
    • Достаточное для решаемой задачи качество картинки.

    Потребовалось около полугода напряженного изучения возможностей OSG для того чтобы тщательно «прощупать почву» и найти подходы к решению поставленной задачи с помощью этого движка. То что родилось в итоге заслуживает отдельного разговора.

    4. От архитектуры к рабочему прототипу


    Видеоподсистема тренажеров подвижного состава (ВТПС) является клиентским приложением, буднично именуемым video3d-client и выполняет следующие функции:

    • Запрос на подключение к серверной части тренажера, авторизация на сервере с последующим периодическим запросом идентификатора загружаемого маршрута, а затем и текущего положения поезда. При разрыве соединения со стороны сервера переход в режим ожидания возможности повторного подключения;
    • Загрузка выбранного маршрута, организация динамического управления содержимым отрисовываемой сцены;
    • Собственно рендеринг сцены в соответствии с текущим положением поезда на маршруте

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

    • filesystem — библиотека для работы с файловой системой, обеспечивает генерацию путей к конфигурационным файлам и ресурсам приложения
    • library — кроссплатформенная реализация загрузчика динамических библиотек. В общем-то костыль, написаный в период, когда возможности интеграции с Qt (где есть готовый к бою модуль QLibrary) была ещё расплывчатой
    • osgdb_dmd — плагин для загрузки моделей формата, специфичного для движка DGLEngine версии 1.1. Для чего это потребовалось я объясню чуть ниже
    • route-loader — библиотека, обеспечивающая абстрактный интерфейс к загрузчику маршрутов. Предполагается возможность загрузки маршрутов произвольного формата
    • tcp-connection — библиотека межпроцессного взаимодействия через TCP-сокеты
    • viewer — основной исполняемый модуль программы
    • zds-route-loader — плагин для загрузки маршрутов формата ZDSimulator

    При проектировании ВТПС встал вопрос выбора: разрабатывать формат маршрутов самостоятельно, либо воспользоваться существующим форматом маршрутов, а так же готовыми маршрутами отечественных железных дорог для существующего железнодорожного симулятора. На счастье подвернулось решение — закрытый проприетарный продукт ZDSimulator, обладающий той особенностью, что он заточен под отечественный подвижной состав и специфику работы сети железных дорог. Несмотря на похвальбу авторов проекта, он имеет массу существенных недостатков, но при этом имеет простой и понятный формат маршрутов, находящихся в открытом доступе. На первом этапе было грех не воспользоваться имеющейся возможностью, при том что графическая часть симулятора основана на открытом движке DGLEngine. Беда в том, что данный движок хоть и развивается (текущее состояние проекта можно увидеть тут), но его текущая вторая версия несовместима с версией 1.1, на которой основан ZDSimulator. Исходники версии 1.1 утеряны, ссылки ведущие к ним давно протухли.

    Тщательный поиск в вебархиве позволил найти утерянное и спасти, разместив DGLEngine v1.1 на Gtihub. Этот движок использует свой, специфический формат 3D-моделей. Имея исходники движка нетрудно было написать соответствующий плагин для OSG.

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

    Иерархия основных классов ВТПС представлена на следующей диаграмме


    Иерархия классов загрузчика маршрутов выглядит так


    Загрузчик любого другого формата маршрутов может быть написан как плагин, содержащий класс, наследующий от класса RouteLoader. При старте ВТПС ей передается путь к каталогу с маршрутом, определяется формат маршрута и динамически загружается соответствующий плагин, выполняющий далее остальную грязную работу.

    Принципиально важным нюансом явилась интеграция движка OSG и Qt. Таковая интеграция существует и именуется osgQt. Эта библиотека не использована в данном проекте по двум причинам:

    1. Отсутствие необходимости в средствах управления окнами, предоставляемыми Qt. OSG имеет свою достаточно развитую систему управления окнами GUI и нет смысла городить GUI поверх другого GUI, так как osgQt предназначена прежде всего для интеграции вьювера OSG в GUI на базе Qt
    2. osgQt подвержена багу — некорректная работа с контекстом OpenGL, который она в некоторых случаях не может поделить между OSG и QGLWidget, из-за чего сцена отображается где угодно, только не на виджете Qt. Причем доискаться причин пока не удалось, поскольку на некоторых системах данный баг не проявляет себя.

    Возникло понимание того, что интеграция с Qt нужна в части использования концепции «сигналы-слоты», для обеспечения взаимодействия с сетевой подсистемой tcp-connection, использующей Qt и являющейся стандартом де-факто в наших разработках. Опираться на систему сообщений OSG и заново писать TCP-клиент (да ещё и кроссплатформенный) очень не хотелось. Нашлось элегантное решение, опирающееся на то, что если мы хотим, чтобы один объект послал сигнал, инициирующий срабатывание слота у другого объекта мы должны выполнить три условия:

    1. Наследовать взаимодействующие классы от QObject
    2. Организовать цикл обработки сигналов
    3. Создать экземпляр класса QApplication (или QCoreApplication) существующий в памяти в процессе работы приложения

    При этом вовсе ни в коем случае не следует выполнять вызов QApplication::exec(), запускающий штатный цикл обработки сигналов, достаточно организовать цикл в котором просто обрабатывать сигналы вызовом QApplication::processEvents(). В OSG таковой цикл имеется (тот цикл, в котором выполняется рендеринг) и имеется возможность создать обработчик событий, в котором обрабатывается событие osgGA::GUIEventAdapter::FRAME, генерируемое движком при отрисовке очередного кадра. Таким образом вся интеграция свелась к коду

    qt-events.h

    #ifndef     QT_EVENTS_H
    #define     QT_EVENTS_H
    
    #include    <osgGA/GUIEventHandler>
    #include    <QtCore/QtCore>
    
    class QtEventsHandler : public osgGA::GUIEventHandler
    {
    public:
    
        QtEventsHandler(){}
    
        virtual bool handle(const osgGA::GUIEventAdapter &ea, osgGA::GUIActionAdapter &aa);
    
    protected:
    
    
    };
    
    #endif // QT_EVENTS_H
    


    qt-events.cpp
    #include    "qt-events.h"
    
    bool QtEventsHandler::handle(const osgGA::GUIEventAdapter &ea, osgGA::GUIActionAdapter &aa)
    {
        switch (ea.getEventType())
        {
        case osgGA::GUIEventAdapter::FRAME:
            {
                QCoreApplication::processEvents(QEventLoop::AllEvents, 100);
    
                break;
            }
    
        default:
    
            break;
        }
    
        return false;
    }
    

    main.cpp

    #include    "main.h"
    
    /*!
     * \fn
     * \brief Entry point
     */
    //------------------------------------------------------------------------------
    //
    //------------------------------------------------------------------------------
    int main(int argc, char *argv[])
    {
        QCoreApplication app(argc, argv);
        RouteViewer viewer(argc, argv);
    
        if (viewer.isReady())
            return viewer.run();
    
        return 0;
    }
    

    после чего, классы унаследованные от QObject и его производных могут обмениваться сигналами до потери пульса.

    Всё вышеперечисленной позволило за два месяца создать первый рабочий прототип ВТПС. Чтобы продемонстрировать что вышло в итоге, предлагаю следующую нарезку из опытных поездок по реальным маршрутам. Заранее прошу прощения за качество съемки — не разжились толковой техникой


    Заключение и выводы


    Главным выводом, по крайней мере для нашей команды стало то, что «серябрянной пули» не существует и в вопросах выбора технологии реализации проекта. Агрессивно продвигаемые на рынок игровые движки не всегда подходят для решения специфических задач, к каким относится визуализация результатов моделирования технических систем. А если и подходят, то не являются оптимальными с точки зрения усилий, потраченных на разработку и сопровождение проекта.

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

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

    Благодарю за внимание!

    (с) Центр развития инновационных компетенций РГУПС
    Поделиться публикацией

    Комментарии 45

      0
      А это просто совпадение, что скриншоты ну ооочень похожи например на это? rustrain3d.ru/sites/default/files/ed4m_pult_03.jpg Особенно рельсы. Плюс стиль изложения немного похож например на это: rustrain3d.ru/ru/main-train-simulators Да и описанную архитектуру (клиент-сервер, железки, отказ от игровых движков в пользу просто графического, Linux, Qt) я где-то уже видел… Вот честно — вы вдохновлялись рустрейновскими тренажёрами, или просто так совпало, что пошли почти тем же путем, только на несколько лет позже?

      UPD. На всякий случай — речь про копирование кода не идёт, просто в целом всё очень похоже.
        0
        вы вдохновлялись рустрейновскими тренажёрами

        Нет, про рустрейн я сам узнал только летом прошлого года

        Что до схожести идей и подходов, так история науки и техники знает немало примеров, когда одна и та же мысль посещала нескольких исследователей, незнакомых друг с другом. Некоторые логические выводы проистекают из законов природы, естественного порядка вещей и базовых принципов отрасли знаний. Так что не удивительно это.

        Особенно рельсы

        Нюансом графики именно для ж/д симуляторов является то, что рельсы это всегда lowpoly-модель, ибо нет смысла рисовать каждый костыль, особенно учитывая протяженность этих самых рельс. Так что верхнее строение пути в разных симуляторах выглядит похоже. Плюс есть ряд текстур, кочующих из MSTS в ZDS и обратно. Дошли они и до нас.
      0
      Шелдон просил передать спасибочки и попросил уточнить несколько вопросов.
      * На сапсанах действительно такое обзорное дупло или это ограничение тренажера, чтобы удешевить?
      * зачем такое переусложнение? Куча мониторов с кучей информации. На наш дурацкий взгляд, достаточно кнопок «автопилот», «погудеть» и рычажка «ехать-тормозить». Для внештатных ситуаций достаточно одного монитора, на который выводить проблемную ситуацию.
      * Я не знаю, чья разработка эти сапсаны, но почему производитель сам не делает тренажеров? Боинг делает, эйрбас делает, сапсан не делает. Или вы как-то к этим поездам относитесь?
      ЗЫЖ момент негодования
      К сожалению, на нашей стороне планеты абсолютно не развита культура съемки видео. Это не зависит от величины и крутости конторы. Все снимают на дрожащий телефон. Некоторые, к счастью, не пытаются добавить фоновое «музло». Некоторые, к счастью, делают его действительно фоновым. Счастье мимолетно.
        0
        Я не знаю, чья разработка эти сапсаны

        Есть очень крутой сайт, там все ответы на ваши вопросы. Если только вопрос задан не затем чтобы задать вопрос…

        На сапсанах действительно такое обзорное дупло или это ограничение тренажера, чтобы удешевить?

        на сапсане там нормальное лобовое стекло, а здесь телевизор
          0
          Три проектора на полукруг не делали или движок такое не позволяет?
            0
            Движок допускает многомониторные конфигурации, легко и непринужденно. Позволяет анаглиф-псевдостерео. Позволяет VR-шлем. Всему свое время
              0
              Нее, после трех проекторов — motion-платформу. На МВПС, конечно, это не актуально, а в грузе ничто так не стимулирует мозг, как сжатие состава в спину или раскачка налива…
                0
                Можно просто сделать тракинг головы, благо пилот (вроде) один. Стерео не даст, зато позволит посмотреть по сторонам. И цена вопроса копеечная.
              0
              Потому что тренажер от Альстома и Сименса будет стоить как два новых поезда.
              0
              * Из кокпита действительно не очень большой обзор (на фото пример ICE3 который конструктивно сильно похож), да и что машинисту разглядывать? главное чтоб сигналы были видны…
              кокпит ICE
              image

              * Куча мониторов тк много информации которая является необходимой во время движения, либо для безопасности (показания скорости, индикаторы пож. безопасности, индикаторы ATP (automatic train protection)), одних тормозов у такого поезда 5 или 6(точно не знаю) видов, либо вспомогательная информация (расписание движения, состояние двигателей, текущая тяга/торможение и тд)
              * ЭВС «Сапсан» (Velaro RUS) производства компании Siemens. Тренажеры есть для ICE. Для Сапсанов возможно РЖД не заказывала…

                0
                одних тормозов у такого поезда 5 или 6(точно не знаю) видов

                ЭВС «Сапсан» оснащен:

                1. Электродинамическим тормозом (рекуперация или реостат, в зависимости от насыщения контактной сети, переключение происходит автоматически)
                2. Автоматическим непрямодействующим тормозом с пневматическим управлением
                3. Электро-пневматическим непрямодействующим тормозом (реализуется за счет электроклапанов, разряжающих и заряжающих тормозную магистраль непосредственно около воздухораспределителя)
                4. Пружинным стояночным тормозом с пневматическим отпуском (пружинные энергоаккумуляторы)

                ICE3 в отличие от «Сапсана» оснащен ещё магниторельсовым тормозом, но РЖД отказалось от этого типа тормоза

                Для Сапсанов возможно РЖД не заказывала


                У РЖД есть тренажер Сапсана, причем на динамической платформе. Кем он разработан не знаю. Но, повторюсь, что наш вуз к подготовке локомотивных бригад не имеет никакого отношения и соответственно тренажеры, заточенные под это нас мало интересуют
                  0
                  У РЖД есть тренажер Сапсана, причем на динамической платформе. Кем он разработан не знаю. Но, повторюсь, что наш вуз к подготовке локомотивных бригад не имеет никакого отношения и соответственно тренажеры, заточенные под это нас мало интересуют
                  тренажёр был изготовлен KMW (Krauss Maffei Wegmann в 2009г), но в середине 2017 года лично мной был разобран (кроме кабины и динамической платформы). Далее были установлены новые компьютеры и новое ПО. Органы управления не менялись, стоят оригинальные с реального Сапсана.
                    0
                    тренажёр был изготовлен KMW (Krauss Maffei Wegmann в 2009г), но в середине 2017 года лично мной был разобран

                    Этот?
                      0
                      Да, но это совсем старое фото (сбоку даже радиостанции нет). Сейчас там новая визуализация, новые ПО на приборах управления, новая мат. модель управления. Проектор остался старым т.к. там специальный выгнутый экран, а установка другого проектора привела только к ухудшению картинки. Разбирал и плакал. Немецкое качество. Всё закручено, всё подписано, качественные комплектующие, грамотное общее проектирование и т.д. P.S а разбирали т.к. очень дорогое обслуживание получается у немцев и долго всё очень.
                        0
                        Разбирал и плакал. Немецкое качество

                        Чего у нас, к сожалению не хватает. На примере нашего «Сапсана» — кабину мы купили на стороне, фирму называть не буду, чтобы не делать ей антирекламу (хотя следовало бы!). Пульт не содержит всего необходимого для реализации симулятора поезда, мы его дорабатывали: монтировали дополнительное оборудование, немного изменили схему проводки и т.п.

                        Сказать что там плохое качество, это не сказать ничего! Начиная от элементарной механики органов управления, заканчивая архитектурой УСО и его прошивкой — всё детский сад. Единственное — изготовленные на заводе платы. Остальное… я был настолько взбешен соотнеся увиденное с ценой, которую за это дали в 2015 году что даже забыл сфотографировать этот ужас.

                        Не смотря на этот саркастический комментарий, в отличие от господ из той фирмы у нас: большая часть механики, кроме не несущей серьезных нагрузок выполнена в металле; проводка выбрана с запасом с учетом опять таки механической надежности; распределенная архитектура УСО, позволяющая расширять систему. Да, сделано полукустарно, но надежно, для себя, и работает без сбоев. До совершенства, конечно как до Солнца.
              0
              Движок Unigine не рассматривали? Он как раз для тренажёров сделан.
                0
                Движок Unigine не рассматривали?

                Нет, в виду проприетарной лицензии
                0

                Всё замечательно, но бросилась в глаза сломанная альфа на деревьях, отчего крона как будто светится или оконтурена. Почему так? Неверный порядок отрисовки, из-за чего в полупрозрачных местах просвечивает не следующее дерево, а небо?

                  0
                  Такая проблема существует. Несмотря на то, что движок самостоятельно сортирует грани, помеченные как допускающие прозрачность. В ресурсах маршрута прозрачными являются все грани на которые накладывается *.tga текстура, так что проблемы пометить не стоит. Разбираемся, думаю починим скоро
                    0
                    А это не тот артефакт, что обычно лечится с помощью premultiplied alpha?
                      +1

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

                        0
                        Спасибо за поправку, на телефоне автоисправление иногда очень неожиданно и незаметно срабатывает.

                        Насчет того, что premultiplied alpha не отменяет порядка отрисовки полностью согласен, просто не имея перед глазами конкретного скриншота не совсем понятно какого рода там артефакт. А неудачная текстура без premultiplied очень даже может давать светлые ореолы на границах, даже при корректном порядке.
                          0
                          Например, вот кадр:

                          image

                            +1
                            Выглядит и правда странно, но если это все-таки проблема в порядке отрисовки, то по любому там еще и z-write не выключен на полупрозрачной геометрии, что по мне немного странное решение. С другой стороны — границы там далеко не все «прямые», хотя возможно это из-за дополнительного альфа-теста.
                              0
                              С другой стороны — границы там далеко не все «прямые», хотя возможно это из-за дополнительного альфа-теста

                              Испытываю искреннее уважение к людям, умеющим вести конструктивную дискуссию. Вашими советами (по всей ветке комментариев) и настроил альфа-тест и функцию смешения, получив такой результат


                              Огромное спасибо за участие, если удастся развернуть этот фикс на тренажер, покажу скрин с моста
                                0
                                Получилось как-то так…
                                  0
                                  Хало по границам крон деревьев, которое вы наблюдаете в видео — как раз из-за использования классического альфа-бленда вместо рекомендованного в таких случаях premultiplied. Идея вкратце:
                                  1) исходные текстуры преобразовать как (rgb, a) -> (a*rgb, a)
                                  2) использовать бленд-функцию src * ONE + dst * (1 — SRC_ALPHA)
                                  Почему именно так — можно почитать тут:
                                  www.realtimerendering.com/blog/gpus-prefer-premultiplication
                                  blogs.msdn.microsoft.com/shawnhar/2009/11/02/texture-filtering-alpha-cutouts
                                  blogs.msdn.microsoft.com/shawnhar/2009/11/06/premultiplied-alpha

                                  Другой вариант — не использовать alpha blending вообще, вместо этого включить MSAA, и для листвы использовать режим alpha to coverage, эффект достаточно хороший, особенно при MSAA 4x и выше, при этом геометрию не обязательно сортировать — традиционный z-buffer при этом отлично работает. Минусы — если будете использовать полноэкранные эффекты и особенно технику deferred shading — включенный MSAA даст очень много мороки. Подробнее тут:
                                  medium.com/@bgolus/anti-aliased-alpha-test-the-esoteric-alpha-to-coverage-8b177335ae4f
                                    0
                                    Реализовал первый метод. Вот результат (кликабельно)
                                      0
                                      1) в исходной текстуре в прозрачных местах случайно не белый был? по хорошему в таких штуках цвет заливки должен хотя бы примерно совпадать с цветом границ, как например тут (смотреть на левую текстуру):
                                      us.v-cdn.net/5021068/uploads/editor/b0/5mlwn87s58ip.jpg

                                      2) перед тем, как загрузить текстуры в видеокарту вы точно сделали предумножение rgb канала на альфу? В итоге в прозрачных местах rgb того, что лежит в видеопамяти должно быть черным.
                                        0
                                        1) в исходной текстуре в прозрачных местах случайно не белый был?

                                        Белый
                                        2) перед тем, как загрузить текстуры в видеокарту вы точно сделали предумножение rgb канала на альфу?

                                        Да, конечно, вот так
                                        void convertTexture(osg::Image *image)
                                        {
                                            unsigned char *data = image->data();
                                        
                                            for (unsigned int i = 0; i < image->getTotalDataSize(); i += 4)
                                            {
                                                pixel_t pixel;
                                        
                                                pixel.r = data[i + 2];
                                                pixel.g = data[i + 1];
                                                pixel.b = data[i];
                                                pixel.a = data[i + 3];
                                        
                                                pixel.r = pixel.r * pixel.a / 255;
                                                pixel.g = pixel.g * pixel.a / 255;
                                                pixel.b = pixel.b * pixel.a / 255;
                                        
                                                data[i + 2] = pixel.r;
                                                data[i + 1] = pixel.g;
                                                data[i] = pixel.b;
                                            }
                                        }
                                        

                                        Ааааа! Я идиот! Восьмибитные числа перемножаю и кладу в восьмибитные!!! Умножай не умножай результат обрежется до восьми бит(((
                                          0
                                          Белый

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


                                          Кстати, судя по окнам локомотива альфа-тест у вас включен для всех текстур с альфа-каналом, что зря. Лучше все-таки разделять кейсы:
                                          1) трава, деревья, возможно какие-то заборы — альфа-тест, в идеале — без альфа бленда, но со включенными MSAA, alpha to coverage и z-write, и можно не сортировать (но выводить все равно лучше после полностью непрозрачных объектов по соображениям производительности z-буфера)
                                          2) действительно полупрозрачные объекты типа окон — z-test и альфа-бленд включен (и используется как раз premultiplied вариант), альфа-тест и z-write выключен, сортировка от дальнего к ближнему, выводить после полностью непрозрачных объектов

                      0
                      А интерфейс на мониторах у машиниста близок к реальности?
                      Неужели в реальной жизни интерфейс также уныл и запутан? На всех ЖК-экранах привет из 80-х.
                        0
                        А интерфейс на мониторах у машиниста близок к реальности?

                        Да, это точная копия того что установлено на Сапсане
                        На всех ЖК-экранах привет из 80-х.

                        Вы знаете о существовании европейского стандарта на интерфейс дисплейных модулей машиниста? Кстати, центральный дисплей — КЛУБ-У — отечественный и он не соответствует этому стандарту

                        И вопрос — а какова, с вашей точки зрения примета 2010-х в этой области? Что должно быть?
                          0
                          Вы знаете о существовании европейского стандарта на интерфейс дисплейных модулей машиниста?

                          Честно говоря — не знал.
                          А «псевдообъёмные» кнопки — это тоже стандарт? А шрифты?

                          image
                          Убрав, например, (как минимум) заливку всех кнопок, расположенных по периметру монитора, можно значительно упростить и облегчить восприятие…
                          + наверняка можно, например, уменьшить толщину горизонтальных линий на шкалах ТМ и ПМ.

                          … какова, с вашей точки зрения примета 2010-х в этой области? Что должно быть?

                          Не совсем понятна фраза «примета 2010-х в этой области». Полагаю, что Вы имеете в виду тренд 2010-х годов? :)
                          Я не специалист в области интерфейсов дисплеев комплексных локомотивных устройств безопасности, но здесь много что можно (читать: нужно) переделать для того, чтобы время считывания машинистом информации уменьшить в разы:

                          image

                          На самом деле, проектирование любого интерфейса — задача всегда интересная и связана с погружением в предметную область по самую макУшку.
                            +1
                            А «псевдообъёмные» кнопки — это тоже стандарт? А шрифты?

                            На настоящем дисплейном блоке кнопки аппаратные. У нас — имитация на сенсорном дисплее. Кстати, центральная зона, где экран, невосприимчива к нажатиям. Чувствительна только имитация рамки дисплея с кнопками

                            Вот так выглядит настоящий дисплейный блок. Правда на фото — «Ласточкин» блок на котором другое ПО, но аппаратно он идентичен Сапсановскому
                            image

                            + наверняка можно, например, уменьшить толщину горизонтальных линий на шкалах ТМ и ПМ

                            Это не к нам, это в фирму Siemens

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

                            а с этим вопросом нужно на Ижевский радиозавод
                        0
                        А выбор сразу такой сделали насчет движка? Ogre3d рассматривали? Qt3D появился с версии 5.5 — его не рассматривали?
                          0
                          А выбор сразу такой сделали насчет движка?

                          Ой не сразу...! Два года я водил команду как Моисей по пустыне в поисках удобной технологии и борясь с наследием в виде убеждения что задачу можно решить только на Unity (и с утверждениями типа «да я видел видео на ютубе, там же все просто, берешь мышкой вытягиваешь...»)
                          Qt3D появился с версии 5.5

                          Qt3D это средство для создания трехмерных презентаций
                          Ogre3d рассматривали?

                          Это был один из первых вероятных кандидатов. У меня даже где-то были тестовые примеры. Что смутило:
                          1. Две параллельные мажорные версии — официальная ветка 1.x и предвечная и не рожденная 2.x с различающейся архитектурой.
                          2. OSG гибче, не зря создатели OpenMW мигрировали с него с Ogre. У них на сайте есть подробный список причин, который был нами изучен. Из яркого — в Ogre нет такой ультрамощной системы плагинов как в OSG, а мы уже успели оценить её по достоинству
                          3. В Windows Ogre для рендера использует DirectX, который лично я считаю технологией: а) не нужной б) медленно умирающей
                            0
                            Qt3D это средство для создания трехмерных презентаций

                            Это вы со студией их, наверное, путаете. Сейчас Qt активно продвигает свой модуль для работы с 3d графикой. Описание.

                            Ogre

                            После того, как основатель и бессменный лидер проекта Steve Streeting ушел по состоянию здоровья, движок очень затормозил. Вроде бы сейчас его тоже пилят, но как-то все медленно, половина вики не работает, а большое русское комьюнити просто развалилось. Жаль, я в свое время активно использовал этот движок и тоже делал на нем различные симуляции, и он был отличным.

                            OSG гибче, не зря создатели OpenMW мигрировали с него с Ogre.

                            Я как-то тоже решил для пробы (один небольшой проект) взять OSG, и тоже могу сказать, что работать с ним приятнее и стабильнее, чем с Огром. Работает именно так, как ожидаешь, что не скажешь о последних версия Огра.
                            Ну и OSG тоже до сих пор пишет автор движка, уже очень много лет.

                            В Windows Ogre для рендера использует DirectX

                            В Ogre3D используются OpenGL и DirectX 9/11, рендер можно выбрать.
                              0
                              Сейчас Qt активно продвигает свой модуль для работы с 3d графикой

                              Возможно я что-то упустил. С какой версии Qt появилась эта возможность? Мне стыдно, что я упустил этот момент, так как, по крайней мере у нас в универе я выступаю в роли евангелиста Qt)

                              Это вы со студией их, наверное, путаете.

                              Да, Вы правы, я спутал это с Qt3D Studio.
                              Что ж… спасибо за наводку, буду изучать и следить
                                0
                                С какой версии Qt появилась эта возможность?

                                С версии 5.5.
                                Не знаю, насколько эта штука юзабельная, потому что потыкать не было возможности, но кажется, что для всяких симуляций выглядит вполне себе подходящим инструментом. Ну и плюс Qt со всеми ништяками, удобно.
                                  0
                                  Определенно сфера применимости есть для разного рода учебных приложений
                              0
                              Ой не сразу...! Два года я водил команду как Моисей по пустыне в поисках удобной технологии
                              Много лет назад, работая в другой конторе, которая пилит деньги на оборонных заказах, я выбрал в качестве языка С++ и рендер Ogre3d. На этой связке выпустил 3-и тренажёра для военных.
                              Потом разругался и работал год тут (у них там полностью свои разработки).
                              Уже на должности тех. директора в СимРэйле, начиная с 2011 года, мы делали тренажёр Ласточки, для обучения локомотивных бригад.
                              Язык программирования я сменил на С# (он проще/компилируется быстрее/ошибок меньше), а рендер был выбран снова Ogre3d (с оберткой для C# mogre) и это была ошибка.
                              Ogre3d это только рэндер и практически полное отсутствие вменяемых инструментов для пользователей и если на первой моей работе такой выбор прокатил, то тут были другие масштабы.
                              Даже примитивная операция конвертации модельки из макса в движок представляла из себя боль и страдания.
                              В конечном итоге силами 3 программистов были написаны: редактор пути, редактор графических интерфейсов (для HMI), визуальный редактор и ещё куча всего для работы тренажёра.
                              Наличие такого объёма кода и поддержки всего этого сильно выматывали. Первыми начали сливаться левел дизайнеры и надо было решать эту проблему…
                              В один прекрасный день акционеры притащили ещё один заказ и для МЧС, нужно было сварганить интерактивный тренажёр для детей, а там есть главный герой, скрипты, анимации, звуковое сопровождение и т.д.
                              От художника! прозвучала мысль, что нужно делать его на Unity. Сказано-сделано. В результате мы сделали его настолько быстро и просто, что было решено отказаться от своих редакторов и полностью перейти в Unity3D.
                              Потом был Сапсан, МТК-1, LNG и т.д, а в прошлом году я уволился.
                                0
                                было решено отказаться от своих редакторов и полностью перейти в Unity3D

                                Как были решены описанные в статье проблемы?

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое