Как-то, давным-давно, обещал я рассказать об электропоезде «Сапсан». Пришло время выполнить свое обещание.



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

1. Немного общих цифр

Электропоезд «Сапсан» является локализованной версией семейства высокоскоростных поездов Velaro, на базе которого Siemens производит высокоскоростные поезда как для Deutsche Bahn (немецких железных дорог), так и много ещё для кого. У нас поезду дали обозначение ЭВС — Электропоезд Высокоскоростной Сименс. Дорога эксплуатирует два его варианта: ЭВС1 для участков, работающих на постоянном токе 3 кВ и ЭВС2 — двухсистемый электропоезд для сетей постоянного тока 3 кВ и переменного тока 25 кВ.

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


На этом вагоне — «Аммендорф», прошедшем капитально восстановительный ремонт (КВР), установлен воздухораспределитель (ВР) усл. №242 пассажирского типа. Он теперь устанавливается на все новые и «откавээреные» вагоны, взамен более раннего 292-го ВР. Вот об этих приборах, относящихся к семейству приборов торможения мы и поговорим сегодня.

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

Старый-добрый золотниковый кран 394 до сих пор используется на подвижном составе

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

Высокоскоростные поезда, вроде TGV уже не обходятся пневматическим торможением



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

Кинетическая энергия «Сапсана» на максимальной скорости — свыше 1500 мегаджоулей. Для полной остановки вся она должна быть рассеяна на тормозных устройствах


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

Наступил тот долгожданный мной день, когда я наконец могу представить эту разработку. Проект был начат ровно год назад, 1 сентября 2018 года, по крайней мере в репозитории RRS на Gtihub первый коммит имеет именно такую дату.

Пассажирский поезд на станции Ростов Главный (кликабельно)



Что такое RRS? Это открытый кроссплатформенный симулятор подвижного состава колеи 1520 мм. Читатель закономерно задаст вопрос: «Позвольте, а для чего нужен этот проект, если симуляторов железнодорожной тематики, как коммерческих, так и открытых, достаточное количество?» За ответом на этот вопрос я и предлагаю заглянуть под кат

Введение

С одной стороны движок OpenSceneGraph и сам по себе обладает развитой подсистемой управления окнами, обработки событий пользовательского ввода, отправки и приема пользовательских сообщений. Об этом мы довольно подробно поговорили в предыдущих статьях этого цикла. В общем, в сумме с возможностями C++/STL этого вполне достаточно для разработки сколь угодно сложных приложений.

Пример интеграции OSG в приложение, разработанной в QtDesigner. Этот пример будет подробно разобран ниже


С другой стороны, для ускорения разработки на C++ применяются как сторонние библиотеки, расширяющие возможности этого языка (вроде boost), так и целые фреймворки, позволяющие легко и непринужденно разрабатывать кроссплатформенные приложения широкого функционального назначения. Одним из таких фреймворков является ультра популярный Qt. Как бы не ругали Qt за его метаобъектный компилятор и прочие недостатки и неудобства, сила Qt в обширной библиотеке классов, решающей все мыслимые задачи кроссплатформенной разработки, а так же в концепции "сигналы — слоты", реализующей подсистему обмена сообщениями между классами. На сигналах и слотах основаны так же методы взаимодействия приложения с операционной системой, а так же межпроцессное взаимодействие.

И, черт возьми, было бы весьма интересно совместить две технологии: Qt и OSG. Подобную задачу пришлось решать моему коллективу, о чем я уже писал в одной из своих публикаций. Однако, этот вопрос хотелось бы раскрыть немного шире, и данная статья будет как раз на эту тему.

Введение

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

Типичный пример: «большой мир» при визуализации железной дороги на движке OSG. Не хватает только лангольеров, пожирающих мир за поездом...


В этой связи возникает необходимость управления ресурсами приложения, сводящаяся к очевидному решению: загрузке только тех ресурсов (моделей, текстур и так далее), которые необходимы для формирования сцены в текущий момент времени при текущем положении наблюдателя; уменьшении уровней детализации удаленных объектов; выгрузке не нужных более объектов из памяти системы. В большинстве своем графические и игровые движки предоставляют некоторый набор инструментов для решения подобных задач. Сегодня мы рассмотрим, какие из них имеются в OpenSceneGraph.

Введение

Где-то в предыдущих уроках уже говорилось о том, что OSG поддерживает загрузку разного рода ресурсов типа растровых изображений, 3D-моделей различных форматов, или, например, шрифтов через собственную систему плагинов. Плагин OSG является отдельным компонентом, расширяющим функционал движка и обладающий интерфейсом, стандартизированным в пределах OSG. Плагин реализуется как динамическая разделяемая библиотека (dll в Windows, so в Linux и т.д). Имена библиотек плагинов соответствуют определенному соглашению

osgdb_<расширение файла>.dll

то есть в имени плагина всегда присутствует префикс osgdb_. Расширение файла указывает движку какой плагин следует использовать для загрузки файла с данным расширением. Например, когда мы пишем в коде функцию

osg::ref_ptr<osg::Node> model = osgDB::readNodeFile("cessna.osg");

движок видит расширение osg и загружает плагин с именем osgdb_osg.dll (или osgdb_osg.so в случает Linux). Код плагина выполняет всю черную работу, возвращая нам указатель на ноду, описывающую модель цессны. Аналогичным образом, попытка загрузки изображения формата PNG

osg::ref_ptr<osg:Image> image = osgDB::readImageFile("picture.png");

приведет к тому, что будет загружен плагин osgdb_png.dll, в котором реализован алгоритм чтения данных из картинки в формате PNG и помещение этих данных в объект типа osg::Image.

Введение

Одной из особенностей языка C++, за которую его часто критикуют — отсутствие в стандарте механизма обработки событий. Между тем данный механизм это один из основных путей взаимодействия одних программных компонентов с другими программными компонентами и аппаратным обеспечением, и реализуется он на уровне конкретной ОС. Естественно, что каждая из платформ имеет свои нюансы реализации описанного механизма.

В связи со всем вышеперечисленным, при разработке на C++, возникает потребность в реализации обработки событий тем или иным способом, решаемая за счет использования сторонних библиотек и фреймворков. Всем известный фреймворк Qt предоставляет механизм сигналов и слотов, позволяющий организовать взаимодействие классов, наследуемых от QObject. Реализация событий присутствует и в библиотеке boost. И конечно же в движке OpenSceneGraph не обошлось без собственного «велосипеда», о применении которого и пойдет речь в статье.

Введение

Мы уже говорили о том, что класс osg::Camera управляет связанным с ним графическим контекстом OpenGL. Графический контекст инкапсулирует информацию о том, как и куда происходит отрисовка объектов и какие атрибуты состояния к ним применяются. Под контекстом понимают графическое окно, вернее его клиентскую область, или пиксельный буфер OpenGL, который хранит данные пикселей без передачи их в кадровый буфер.

OSG использует класс osg::GraphicsContext для представления абстрактного графического контекста, и класс osg::GraphicsWindow, для представления абстрактного графического окна. Последний имеет метод getEventQueue() для управления событиями от элементов GUI. Вообще говоря графический контекст есть платформоспецифичное понятие, поэтому большую часть работы по созданию окна и связыванию его контекста с контекстом OpenGL, OSG берет на себя. При вызове метода createGraphicsContext() класса osg::GraphicsContext() требуемый код (а его не мало, поверьте!) будет сгенерирован препроцессором автоматически, в зависимости от платформы. От нас лишь требуется передать этому методу аргумент типа osg::GraphicsContex::Traits, содержащий описание того, какое окно мы хотим получить.

Введение

Говоря о приемах программирования, специфичных для OSG в прошлый раз мы говорили о механизме обратных вызовов (Callback) и его реализации в движке. Настало время посмотреть на то, какие возможности дает нам применение этого механизма для управления содержимым трехмерной сцены.

Если говорить об анимации объектов, то OSG предоставляет разработчику две возможности её реализации:

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

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

Введение

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

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

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

Введение

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

OSG поддерживает несколько текстурных атрибутов и режимов текстурирования. Но, перед тем как говорить о текстурах, поговорим о том, как в OSG оперируют с растровыми изображениями. Для работы с растровыми изображениями предусмотрен специальный класс — osg::Image, хранящий внутри себя данные изображения, предназначенных, в конечном итоге, для текстурирования объекта.

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

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

Введение

Как правило, работая с параметрами рендеринга, OpenGL действует как конечный автомат. Состояние рендеринга — это совокупность атрибутов состояния, таких как источники света, материалы, текстуры и режимы отображения, включаемые и выключаемые функциями glEnable() и glDisable(). При установке определенного состояния оно действует до тех пор, пока какая-либо другая функция не изменит его. Конвейер OpenGL поддерживает стек состояний для сохранения и восстановления состояний в любой момент времени. Машина состояний предоставляет разработчику полный контроль над текущими и сохраненными в стеке состояниями рендеринга.

Однако такой подход неудобен при работе с OSG. По этой причине машина состояний OpenGL инкапсулируется классом osg::StateSet, который берет на себя операции по работе со стеком состояний и их установке в процессе обхода графа сцены.

Введение

Когда происходит рисование точки, линии или сложного полигона в трехмерном мире, финальный результат, в конечном итоге, будет изображен на плоском, двухмерном экране. Соответственно, трехмерные объекты проходят некий путь преобразования, превращаясь в набор пикселей, выводимых в двумерное окно.

Развитие программных инструментов, реализующих трехмерную графику пришло, вне зависимости от того, какой из них вы выбираете, примерно к одинаковой концепции как математического, так и алгоритмического описания вышеупомянутых трансформаций. Идеологически и «чистые» графические API типа OpenGL, и крутые игровые движки типа Unity и Unreal, используют схожие механизмы описания преобразования трехмерной сцены. Не является исключением и OpenSceneGraph.

В этой статье мы сделаем обзор механизмов группировки и трансформации трехмерных объектов в OSG.

Введение

OpenGL, являющийся бэкэндом для OpenSceneGraph, использует геометрические примитивы (такие как точки, линии, треугольники и полигональные грани) для построения всех объектов трехмерного мира.

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

Кроме того, OpenGL может использовать механизм так называемых дисплейных списков, когда однажды подготовленные в видеопамяти примитивы могут использоваться повторно, что существенно ускоряет отображение статических объектов.

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

Введение

В прошлой статье мы рассмотрели сборку OpenSceneGraph из исходников и написали элементарный пример, в котором в пустом фиолетовом мире висит серый самолет. Согласен, не слишком впечатляет. Однако, как я говорил раньше, в этом маленьком примере присутствуют главные концепции, на которых основан данный графический движок. Рассмотрим их подробнее. В ниже приведенном материале использованы иллюстрации из блога Александра Бобкова об OSG (жаль, что автор забросил писать об OSG...). Статья базируется так же на материале и примерах из книги OpenSceneGraph 3.0. Beginner’s Guide

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

Введение

OpenSceneGraph (далее OSG) — открытый кроссплатформенный фреймворк, написанный на C++ и представляющий собой графический движок, предоставляющий программисту объектный интерфейс к OpenGL. В нашей стране этот движок не особенно популярен, даже на Хабре я видел только одну более-менее приличную публикацию о нем. OSG применяется за рубежом много где, например он является основой для свободного авиасимулятора FlightGear, существует открытая реализация игры Morrowind, называемая OpenMW разработка которой так же перенесена на OSG с движка Ogre. Русскоязычной документации по нему исчезающе мало, а среди англоязычной можно отметить лишь серию книг от разработчиков: OpenSceneGraph 3.0. Beginner’s Guide и OpenSceneGraph 3. Cookbook.

Тем не менее, движок достаточно интересен по следующим причинам:

1. Открытая кроссплатформенная реализация на C++.
   
2. Модульная архитектура.
   
3. Расширяемость за счет встроенной системы плагинов.
   
4. Возможность многопоточной обработки графических данных и встроенный инструментарий для её реализации
   
5. Управление динамической памятью через механизм умных указателей
   

Думаю, что читателям Хабра будет интересно более подробно ознакомится с этим проектом. Не лишним будет и пополнение русскоязычной базы знаний по OSG. Все материалы, которые будут публиковаться мной по данной теме основаны на книге OpenSceneGraph 3.0. Beginner’s Guide, но являются не её переводом, а скорее творческой переработкой изложенного там материала. Если вам интересна данная тема, прошу под кат