Vor etwas weniger als einem Jahr wurde eine Veröffentlichung veröffentlicht, in der wir über den Trainings- und Laborkomplex (ULK) des von unserer Universität entwickelten elektrischen Zuges ES1 Lastochka sprachen. Dann versprach ich, dass dies nicht die letzte Veröffentlichung zu diesem Thema sein würde, insbesondere drohte ich, über die Probleme bei der Erstellung einer dreidimensionalen Visualisierung für solche Simulatoren zu sprechen und die wichtigsten Lösungsansätze zu skizzieren.

Letztes Jahr waren wir mit unserer nächsten Veröffentlichung zufrieden - dem ULK des elektrischen Hochgeschwindigkeitszuges EVS2 von Sapsan, der im August letzten Jahres stattfand. Der Bildungs- und Laborkomplex dieses elektrischen Zuges selbst verdient eine eigene Geschichte, aber im Rahmen dieser Veröffentlichung werden wir über die Wunde sprechen - das Problem der Schaffung eines adäquaten Subsystems der dreidimensionalen Visualisierung, das unser Team etwa zwei Jahre lang von zwei Seiten angesprochen hat. Die Veröffentlichung des Sapsan-Simulators ist (unter anderem) von Bedeutung und hat den Entwicklungsvektor unserer Entwicklungen in diesem Bereich bestimmt.

1. Kurz über ULK EVS2 „Sapsan“

Ich möchte noch einmal betonen (was ich mit beneidenswerter Häufigkeit mache), dass die an unserer Universität entwickelten Bildungs- und Laborkomplexe von Schienenfahrzeugen nicht für die Vorbereitung von Lokomotivenbrigaden bestimmt sind. Wie einer der Kommentatoren des vorherigen Artikels zu Recht feststellte , handelt es sich bei unseren ULK nicht um Simulatoren, sondern um Simulatoren, bei denen der Schwerpunkt auf der kompetenten Umsetzung der Physik der Zugbewegung und der Simulation des Betriebs der Teilsysteme des rollenden Materials liegt, die dessen Bewegung und Stopp sicherstellen. Der Sapsan-Simulator ist keine Ausnahme, bei der folgende Aufgaben gelöst werden:

• Unter Berücksichtigung der Längskräfte und des Gleisprofils wurde ein dynamisches Modell des mechanischen Teils des Zuges implementiert
• Es wurde ein detailliertes Computermodell für den Betrieb der wichtigsten Teilsysteme des elektrischen Zuges erstellt: Stromkreis, elektrischer Traktionsantrieb, pneumatische und elektropneumatische Bremsen
• Die grundlegenden Algorithmen für den Betrieb des elektrischen Zugsteuerungssystems auf verschiedenen Ebenen werden reproduziert.

Darüber hinaus umfasst der Schulungs- und Laborkomplex ein Modell der Kabine des elektrischen Zuges in Originalgröße mit den Hauptsteuerungen und Mitteln zur Anzeige von Informationen. Im Gegensatz zum Swallows-Simulator wurde diese Kabine nicht von uns selbst hergestellt, sondern 2015 von einem Büro im Land gekauft, das Trainingssimulatoren herstellt. Daher konzentrierte sich der Entwicklungsprozess des Simulators auf die Erstellung von Software.


Die Entwicklung von Software für einen solchen Simulatorsimulator ist eine sehr weit gefasste Frage, und ich werde (nach besten Kräften) versuchen, das Interesse der Leser an diesen Themen in Zukunft (falls vorhanden) zu befriedigen. Kehren wir jedoch zunächst zum Hauptthema des Artikels zurück - der dreidimensionalen Visualisierung des Zugbewegungsprozesses.

2. Hintergrund und Technologie der Vergangenheit

In den Kommentaren zum letzten Artikel wurde eine Frage gestellt , die mich ehrlich gesagt ziemlich amüsierte. Ja, in der Tat wird dieser Ansatz in vielen heute noch verwendeten Simulatoren immer noch verwendet: Video wird auf einem realen Abschnitt der Eisenbahn aufgenommen und dann mit einer Geschwindigkeit, die proportional zur Bewegungsgeschwindigkeit ist, auf dem Simulator gescrollt. Dies geschah nur, weil in jenen Tagen, als solche Simulatoren erstellt wurden, die Qualität dreidimensionaler Grafiken zu wünschen übrig ließ, und dies galt auch für raue Grafikstationen auf kommerziellen Unixen, und es gab keine Frage eines PCs. Daher zögerten auch Hersteller von Computerspielen, beispielsweise dieses , nicht, diesen Ansatz zu verwenden.

Das macht heute keinen Sinn, weil:

1. Die unzureichende Bildrate bei niedrigen Zuggeschwindigkeiten bietet nicht die gewünschte Glätte der Bildaktualisierung. Wir werden die geschätzten 25 fps nur bei der Geschwindigkeit haben, mit der das Video aus der Fahrerkabine aufgenommen wurde. Und dieser fatale Fehler kann in keiner Weise behoben werden - weder durch Aufnahmen mit einer Hochgeschwindigkeitskamera (wie viel wiegt das mit 120 Bildern pro Sekunde aufgenommene Video? Das ist das gleiche ...) noch durch die programmierte Erzeugung von Zwischenbildern. Letzteres wurde von uns mit OpenCV-Technologie durchgeführt, führte jedoch nicht zu normalen Ergebnissen. Diese Frage wurde wiederholt von allen Seiten untersucht, und als Ergebnis wurde der Schluss gezogen, dass die Kosten für Ressourcen zur Erstellung eines solchen Systems viel höher sind als für die Entwicklung eines ähnlichen Systems, jedoch basierend auf 3D-Grafiken
2. Schwierigkeiten beim reibungslosen Zurückblättern des Videos. Und selbst wenn man bedenkt, dass sie überwunden werden, wo werden dann die Hunde, die auf der Plattform laufen, rennen? Denken wir, wir sollten umgekehrt vorgehen?
3. Das Fehlen aller "Interaktivität". Was tun mit einem Ampelwechsel, mit der Bewegung von Weichen, der Bewegung entgegenkommender und vorbeifahrender Züge?

Daher werden alle modernen Simulatoren und Simulatoren mit interaktiven 3D-Grafiken erstellt, da es heute weder aus Software- noch aus Hardwaresicht Hindernisse gibt.

Wenn aus Hardware-Sicht alles sehr klar ist - der anstelle der Windschutzscheibe installierte Monitor ist mit einer normalen Grafikkarte (nicht einmal der Top-End-Karte) an einen PC angeschlossen -, stellt sich aus Sicht der Software die Frage, welche Technologie für die Implementierung der Aufgabe ausgewählt werden soll.

3. Die Grafik-Engine im Vergleich zur Game-Engine oder warum OpenSceneGraph ausgewählt wurde

Ich kann mich irren, aber ich erwarte Kommentare im Voraus, die eine völlig logische Frage stellen, warum unsere Wahl bei der Analyse bestehender Technologien nicht bei Mastodons wie Unity oder Unreal Engine 4 aufgehört hat. Ich werde diese Frage beantworten, außerdem werde ich meine Antwort rechtfertigen.

Kurz gesagt - weder Unity noch Unreal Engine erfüllen die Anforderungen der zu lösenden Aufgabe. Eine detailliertere Antwort enthält zunächst eine Auflistung der betreffenden Anforderungen. TK, zusammengestellt von uns auf dem Teilsystem der dreidimensionalen Visualisierung, enthält (in absteigender Reihenfolge der Wichtigkeit) die folgenden Bestimmungen:

1. Unabhängigkeit des Softwareentwicklungsprozesses des Visualisierungssubsystems und des Prozesses der Erstellung von Ressourcen dafür. Zu den Ressourcen gehören in diesem Fall dreidimensionale Modelle, Texturen sowie die sogenannten Routen . Unter einer Route wird eine Kombination von Konfigurationsobjekten und Ressourcen verstanden, die es dem Videosubsystem ermöglichen, den gewünschten Abschnitt der Eisenbahn anzuzeigen und die Bewegung des Zuges entlang dieser zu simulieren. Dies beinhaltet auch die Möglichkeit, die Route zu ändern, ohne den Softwareteil des Video-Subsystems neu zu erstellen
2. Erstellen Sie Routen mit unbegrenzter Länge. Ich werde reservieren, dass eine unbegrenzte Länge aufgrund begrenzter Hardwareressourcen grundsätzlich nicht erreichbar ist. Diese Anforderung sollte verstanden werden, dass die Länge der Route mindestens innerhalb einer „Schulter“ liegen sollte, dh eines Straßenabschnitts zwischen den Wendepunkten, und dies ist in Abhängigkeit von verschiedenen Faktoren eine ziemlich große Entfernung, die auf mehr als einhundert Kilometer geschätzt wird. Diese Anforderung erfordert ein dynamisches Laden / Entladen von Programmressourcen mit ausreichender Glätte bei angemessenem Speicherverbrauch. Und es ist wünschenswert, dass die Engine solche Funktionen "out of the box" enthält.
3. Bequeme Integration in den verwendeten Technologie-Stack. Aus objektiven Gründen verwendet unser Team traditionell die C ++ - Sprache mit Qt-Framework, QtCreator IDE und Git als Versionskontrollsystem für die Entwicklung von Software für ULK PS. Als Systemplattform ULK PS wird ein auf dem Linux-Kernel basierendes Betriebssystem verwendet

Was ist los mit Unity und UE? Was ist die Tatsache, dass andere Engines Ressourcen in völlig anderen Formaten importieren können. Beim Zusammenstellen des Projekts werden sie jedoch irreversibel in das interne Binärformat konvertiert, wodurch das Hinzufügen und Ändern von Ressourcen ohne erneutes Zusammensetzen des Projekts unmöglich wird. In Unity verfügbare Technologien wie Fertighäuser und Asset-Bundles lösen das Problem nicht, da der Motoreneditor nicht der beste Ort ist, um Bahnstandorte zu erstellen. Dies erfordert die Erweiterung des Editors, was dazu führt, dass ein „Motor im Motor“ geschrieben werden muss. Darüber hinaus ist die Erstellung von Fertighäusern und Bundles ohne die Verwendung des Unity-Editors nicht möglich, und dies ist, wie die Praxis gezeigt hat, insbesondere für reine Modellierer und Leveldesigner nicht sehr praktisch. In Bezug auf die UE habe ich über zwei Jahre hinweg viele Fragen zu dieser und anderen Ressourcen gestellt, wie der Prozess des Erstellens eines Projekts vom Prozess des Hinzufügens / Änderns der verwendeten Ressourcen getrennt werden kann, und ich habe weder in der Dokumentation noch in „ eingefleischte "Spieleentwickler. Ich würde mich sehr freuen (ohne Sarkasmus), wenn ich vernünftigerweise auf etwas stoßen würde, das ich verpasst habe.

Was die zweite Anforderung betrifft, scheinen sowohl Unity als auch UE die Möglichkeit zu bieten, dynamisch geladene Speicherorte zu erstellen. Die Frage bleibt jedoch unbeantwortet, wie solche Speicherorte unabhängig vom Editor und ohne Neuerstellung des Projekts erstellt werden können. Es gibt nur einen Ausweg: Schreiben Sie eine „Engine in die Engine“, die die „Roh“ -Geometrie und -Texturen (in einem der zuvor angegebenen Exportformate von 3D-Editoren) lädt, alle erforderlichen Effekte auf sie anwendet und sie basierend auf den von einem Drittanbieter beschriebenen Daten im Raum positioniert unabhängig vom Motorformat, das noch entwickelt und gelehrt werden muss, um den Motor zu interpretieren.

Im Zusammenhang mit dem oben Gesagten stellt sich die Frage: Wenn zur Lösung dieses Problems eine leistungsstarke Softwareschicht über die Spiel-Engine geschrieben werden muss, deren Funktionalität für das betreffende Problem größtenteils nicht benötigt wird, warum benötigen wir dann eine Spiel-Engine?

Vielleicht reicht die Grafik-Engine? Ich habe diese Frage dem vorherigen Team gestellt, das das zur Diskussion stehende Problem unter Berufung auf Unity angegangen ist (und natürlich etwas später zusammengeführt hat). Als Antwort erhielt er eine Gegenfrage: "Was schlagen Sie vor?", Auf die er antwortete, und im Geiste des obigen Textes erhielt er das sarkastische Lächeln eines Gegners.

Wenn Sie auf Sarkasmus verzichten, ist die vorgestellte Aufgabe eine typische Visualisierungsaufgabe - sie erfordert nur ein Framework für die Arbeit mit Grafiken, da sowohl die Physik als auch das auf Physik basierende Audio-Subsystem auf der Serverseite implementiert sind. Mein Team und ich haben diese Tatsache verstanden, indem wir uns durch die Trägheit früherer Entwickler zunächst in Richtung Unity durch UE bewegt und versucht haben, das Grafik-Subsystem von einem der offenen Eisenbahnsimulatoren (OpenBVE, das sich übrigens herausstellte, aber es wurde zu einer vorübergehenden Krücke) zu befestigen.

OpenSceneGraph ist mit Abstand die am weitesten entwickelte (offene und kostenlose) Grafik-Engine, die sich auf die C ++ - Entwicklung konzentriert. Es wird im Ausland gerade zur technischen dreidimensionalen Visualisierung weit verbreitet. Dieser Motor wurde von keinem Simulator verschont, von dem der bekannteste FlightGear ist . Es gab einmal einen Eisenbahnsimulator, der auf diesem Motor basierte - Indra , der jedoch nur langweilige Screenshots des obigen Links hinterließ und dessen weiteres Schicksal mir unbekannt ist.

Im Rahmen der vorliegenden Aufgabe weist die OSG-Grafik-Engine die folgenden positiven Eigenschaften auf:

• Plattformübergreifend, wodurch es möglich ist, es im GNU / Linux-Ökosystem anzuwenden
• Die Entwicklungssprache ist C ++ / STL, was es ermöglicht, sie einfach und natürlich in den etablierten technologischen Entwicklungsprozess zu integrieren.
• Die größte Auswahl an Ressourcenformaten wird "out of the box" unterstützt - 3D-Geometrie und Texturen aufgrund des entwickelten Plug-In-Systems. Eine einfache und intuitive Oberfläche zum Schreiben eigener Plug-Ins zum Einrichten des Ressourcenmanagers für nicht standardmäßige Formate, die wir verwendet haben (darüber werde ich weiter unten schreiben).
• Ein Speicherverwaltungssystem, das auf einem proprietären Modell von intelligenten Zeigern basiert (ein proprietäres Format von intelligenten Zeigern wurde in der Vergangenheit verwendet, da es zu Beginn der Entwicklung keine intelligente Zeiger-Engine im C ++ - Standard gab).
• Flexible modulare Architektur;
• Der Szenenobjekt-Manager, der Objekte dynamisch lädt, ermöglicht das Laden und Rendern nur der Objekte, die in die Beschneidungspyramide fallen (aufgrund der Klasse osg :: PagedLOD).
• Integrationsfähigkeit in das Qt-Framework. Dank des praktischen Qs-Slots-Modells von Qt, das die C ++ - Entwicklung erheblich vereinfacht und beschleunigt, verwenden wir dieses Framework häufig für die Entwicklung komplexer Schulungssoftware. Dementsprechend haben wir eine signifikante Codebasis angesammelt, die in verschiedenen Projekten wiederverwendet wurde, insbesondere im Hinblick auf die Bibliothek der Interprozesskommunikation basierend auf TCP-Sockets. Die Verwendung der Funktionen von Qt im Video-Subsystem-Projekt scheint eine logische Entscheidung zu sein.
• Ausreichende Bildqualität für die zu lösende Aufgabe.

Es dauerte ungefähr sechs Monate intensiver Untersuchung der OSG-Fähigkeiten, um den Boden gründlich zu "untersuchen" und Ansätze zur Lösung des Problems mit dieser Engine zu finden. Was als Ergebnis geboren wurde, verdient eine gesonderte Diskussion.

4. Von der Architektur zum funktionierenden Prototyp

Das Video-Subsystem der Rollmaterial-Trainingssimulatoren (HTSC) ist eine Client-Anwendung, die routinemäßig als Video3d-Client bezeichnet wird und die folgenden Funktionen ausführt:

• Eine Anforderung zum Herstellen einer Verbindung zum Serverteil des Simulators, Autorisierung auf dem Server, gefolgt von einer regelmäßigen Anforderung nach der Kennung der geladenen Route und anschließend zur aktuellen Position des Zuges. Wenn die Verbindung von der Serverseite getrennt wird, wechselt das System zum erneuten Herstellen der Verbindung in den Standby-Modus.
• Herunterladen der ausgewählten Route, Organisation der dynamischen Verwaltung des Inhalts der gerenderten Szene;
• Tatsächliches Rendern der Szene in Übereinstimmung mit der aktuellen Position des Zuges auf der Strecke

Nicht dass dieses Projekt Open Source war, aber den Code einer voll funktionsfähigen Technologiedemo finden Sie hier . Das Projekt besteht aus folgenden Modulen:

• Dateisystem - Eine Bibliothek für die Arbeit mit dem Dateisystem bietet die Generierung von Pfaden zu Konfigurationsdateien und Anwendungsressourcen
• Bibliothek - eine plattformübergreifende Implementierung des dynamischen Bibliotheksladers. Im Allgemeinen war eine Krücke, die zu einer Zeit geschrieben wurde, als die Möglichkeiten der Integration mit Qt (wo ein QLibrary-Modul für den Kampf bereit ist) noch vage waren
• osgdb_dmd - ein Plugin zum Laden von Modellen eines Formats, das für die DGLEngine Engine Version 1.1 spezifisch ist. Für das, was es brauchte, werde ich etwas weiter unten erklären
• route-loader ist eine Bibliothek, die eine abstrakte Schnittstelle zum route loader bietet. Es ist möglich, Routen mit beliebigem Format zu laden
• TCP -Verbindung - Interprozess-Kommunikationsbibliothek über TCP-Sockets
• Viewer - das ausführbare Hauptmodul des Programms
• zds-route-loader - Plug-In zum Laden von Routen im ZDSimulator-Format

Bei der Gestaltung des VTPS stellte sich die Frage, ob ein eigenständiges Streckenformat entwickelt oder das vorhandene Streckenformat sowie vorgefertigte Strecken der Inlandsbahnen für den vorhandenen Eisenbahnsimulator verwendet werden sollen. Glücklicherweise stellte sich heraus, dass es sich bei der Lösung um das geschlossene proprietäre Produkt ZDSimulator handelt , das die Besonderheit aufweist, dass es auf inländische Fahrzeuge und die Besonderheiten des Eisenbahnnetzes zugeschnitten ist. Trotz des Lobes der Autoren des Projekts weist es viele erhebliche Nachteile auf, hat aber gleichzeitig ein einfaches und klares Format öffentlich zugänglicher Routen. In der ersten Phase war es eine Sünde, die Gelegenheit nicht zu nutzen, obwohl der grafische Teil des Simulators auf der offenen DGLEngine-Engine basiert. Das Problem ist, dass diese Engine zwar entwickelt wird (der aktuelle Status des Projekts ist hier zu sehen ), die aktuelle zweite Version jedoch nicht mit der Version 1.1 kompatibel ist, auf der ZDSimulator basiert. 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. Erben Sie interagierende Klassen von QObject
2. Organisieren Sie eine Signalverarbeitungsschleife
3. Erstellen Sie eine Instanz der Klasse QApplication (oder QCoreApplication), die während des Anwendungsvorgangs im Speicher vorhanden ist

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; } 

Danach können von QObject und seinen Ableitungen geerbte Klassen Signale austauschen, bis der Impuls verloren geht.

All dies erlaubte zwei Monate, um den ersten funktionierenden Prototyp von HTPS zu erstellen. Um zu demonstrieren, was am Ende passiert ist, schlage ich den folgenden Abschnitt von experimentellen Reisen auf realen Routen vor. Ich entschuldige mich im Voraus für die Qualität der Aufnahmen - sie haben keine intelligente Technologie erhalten

Schlussfolgerung und Schlussfolgerungen

Die wichtigste Schlussfolgerung, zumindest für unser Team, war, dass die Wahl der Technologie für die Umsetzung des Projekts keine "graue Kugel" enthielt. Aggressiv vermarktete Game-Engines eignen sich nicht immer zur Lösung bestimmter Aufgaben, einschließlich der Visualisierung der Ergebnisse der Modellierung technischer Systeme. Und wenn sie geeignet sind, sind sie hinsichtlich des Aufwands für die Entwicklung und Wartung des Projekts nicht optimal.

Es ist eine Schande, dass eine sehr gute und vor allem kostenlose OSG-Grafik-Engine in unserem Land keine Community hat. Um dieses Problem zu beheben, schreibe ich hier eine Reihe von Artikeln über die Ressource (dort habe ich alle Links zu mehr oder weniger angemessenen Informationsquellen gesammelt, auch in russischer Sprache). Darüber hinaus kann ich als Dokumentation, die die Grundprinzipien von OSG beschreibt, auch diesen Blog anbieten. Ich hoffe, dass jemand diese Informationen nützlich findet.

In Bezug auf HTSC wird die Arbeit in dieser Richtung fortgesetzt. Es gibt noch viele wichtige Aufgaben, die in naher Zukunft gelöst werden müssen.

Danke für die Aufmerksamkeit!

(c) Zentrum für die Entwicklung von Innovationskompetenzen