Il y a un peu moins d'un an, une publication a été publiée dans laquelle nous parlions du complexe de formation et de laboratoire (ULK) du train électrique ES1 Lastochka développé par notre université. Ensuite, j'ai promis que ce ne serait pas la dernière publication sur ce sujet, en particulier, j'ai menacé de parler des problèmes de création de visualisation tridimensionnelle pour de tels simulateurs et de décrire les principales approches pour les résoudre.

L'année dernière, nous avons été satisfaits de notre prochaine version - l'ULK du train électrique à grande vitesse Sapsan EVS2, qui a eu lieu en août de l'année dernière. Le complexe éducatif et de laboratoire de ce train électrique lui-même mérite une histoire distincte, mais dans le contexte de cette publication, nous parlerons de la plaie - le problème de la création d'un sous-système adéquat de visualisation en trois dimensions, solution à laquelle notre équipe a approché de différents côtés pendant environ deux ans. La sortie du simulateur Sapsan est significative (entre autres) et a déterminé le vecteur de développement de nos développements dans ce domaine.

1. En bref sur ULK EVS2 «Sapsan»

Je tiens à souligner une fois de plus (ce que je fais avec une fréquence enviable) que les complexes pédagogiques et de laboratoire du matériel roulant développés dans notre université ne sont pas destinés à la préparation des brigades de locomotives. Comme l'a noté à juste titre l' un des commentateurs de l' article précédent, nos ULK ne sont pas des simulateurs, mais des simulateurs, où l'accent est mis sur la mise en œuvre compétente de la physique du mouvement des trains et la simulation du fonctionnement des sous-systèmes du matériel roulant qui assurent son mouvement et son arrêt. Le simulateur Sapsan ne fait pas exception, sur lequel les tâches suivantes sont résolues:

• Un modèle dynamique de la partie mécanique du train a été mis en place en tenant compte des efforts longitudinaux et du profil de voie
• Un modèle informatique détaillé du fonctionnement des principaux sous-systèmes du train électrique a été construit: circuit électrique de puissance, entraînement électrique de traction, freins pneumatiques et électropneumatiques
• Les algorithmes de base du fonctionnement du système de contrôle des trains électriques à différents niveaux sont reproduits.

De plus, le complexe de formation et de laboratoire comprend un modèle grandeur nature de la cabine du train électrique avec les principales commandes et les moyens d'affichage des informations. Contrairement au simulateur Swallows, cette cabine n'a pas été fabriquée par nous-mêmes, mais a été achetée en 2015 dans un bureau du pays qui produit des simulateurs de formation. Par conséquent, le processus de développement du simulateur s'est concentré sur la création de logiciels.


Le développement de logiciels pour un tel simulateur de simulateur est une question très large, et j'essaierai (au mieux de mes capacités) de satisfaire l'intérêt des lecteurs pour ces questions à l'avenir (le cas échéant), mais pour l'instant, revenons au sujet principal de l'article - la visualisation en trois dimensions du processus de mouvement du train.

2. Contexte et technologie du passé

Dans les commentaires du dernier article , une question a été posée , ce qui m'a franchement beaucoup amusé. Oui, en effet, dans de nombreux simulateurs encore utilisés aujourd'hui, cette approche est toujours utilisée: la vidéo est filmée sur une section réelle du chemin de fer, puis elle défile sur le simulateur à une vitesse proportionnelle à la vitesse de déplacement. Cela n'a été fait que parce que dans ces temps lointains où de tels simulateurs étaient créés, la qualité des graphiques en trois dimensions laissait beaucoup à désirer, et cela s'appliquait également aux stations graphiques difficiles sur Unix commerciaux, et il n'était pas question d'un PC. Par conséquent, même les fabricants de jeux informatiques, par exemple celui-ci , n'ont pas hésité à utiliser cette approche.

Cela n'a plus de sens aujourd'hui, car:

1. Le taux de trame insuffisant à basse vitesse de train ne fournit pas la douceur souhaitée de rafraîchissement de l'image. Nous n'aurons les 25 fps précieux qu'à la vitesse à laquelle la vidéo a été tournée depuis la cabine du conducteur. Et cette faille fatale ne peut en aucun cas être surmontée - ni en filmant avec une caméra à haute vitesse (combien pèsera la vidéo tournée à 120 images par seconde? C'est la même chose ...), ni par la génération programmée d'images intermédiaires. Ce dernier a été entrepris par nous en utilisant la technologie OpenCV, mais n'a pas conduit à des résultats normaux. Cette question a été étudiée à plusieurs reprises de tous les côtés et en conséquence, il a été conclu que le coût des ressources pour la création d'un tel système est beaucoup plus élevé que le développement d'un système similaire, mais basé sur des graphiques 3D
2. Difficultés à faire défiler la vidéo en douceur. Et même en tenant compte du fait qu'ils seront surmontés, alors où vont courir les chiens qui courent sur la plate-forme, pensons-nous que nous devrions aller en sens inverse?
3. L'absence de toute «interactivité». Que faire avec un changement de feu de circulation, avec le mouvement des aiguillages, le mouvement des trains venant en sens inverse et passant?

Par conséquent, tous les simulateurs et simulateurs modernes sont créés à l'aide de graphiques 3D interactifs, car il n'y a aujourd'hui aucun obstacle d'un point de vue logiciel ou matériel.

Si tout est très clair du point de vue matériel - le moniteur installé à la place du pare-brise est connecté à un PC avec une carte vidéo normale (pas même la carte haut de gamme), alors du point de vue logiciel, la question se pose de choisir la technologie pour la mise en œuvre de la tâche.

3. Le moteur graphique par rapport au moteur de jeu ou pourquoi OpenSceneGraph a été choisi

Je peux me tromper, mais j'anticipe des commentaires à l'avance, qui poseront une question tout à fait logique, pourquoi, lors de l'analyse des technologies existantes, notre choix ne s'est pas arrêté à des mastodontes comme Unity ou Unreal Engine 4? Je répondrai à cette question, d'ailleurs, je justifierai ma réponse.

En bref - ni Unity ni Unreal Engine ne satisfont aux exigences de la tâche à résoudre. Une réponse plus détaillée fournit, tout d'abord, une liste des exigences en question. Les savoirs traditionnels, compilés par nous sur le sous-système de visualisation tridimensionnelle, comprennent (par ordre décroissant d'importance) les dispositions suivantes:

1. Indépendance du processus de développement logiciel du sous-système de visualisation et du processus de création de ressources pour celui-ci. Les ressources, dans ce cas, incluent les modèles tridimensionnels, les textures, ainsi que les soi-disant routes . Un itinéraire est compris comme une combinaison d'objets de configuration et de ressources qui permettent au sous-système vidéo d'afficher la section souhaitée du chemin de fer et de simuler le mouvement du train le long de celui-ci. Cela inclut également la possibilité de modifier l'itinéraire sans reconstruire la partie logicielle du sous-système vidéo
2. Créez des itinéraires de longueur illimitée. Je ferai une réservation selon laquelle une longueur illimitée est en principe inaccessible en raison des ressources matérielles limitées. Cette exigence doit être comprise que la longueur de l'itinéraire doit être au moins à l'intérieur d'un «accotement», c'est-à-dire une section de la route entre les points de retournement, et cela, en fonction de divers facteurs, est une distance suffisamment grande, estimée à plus de cent kilomètres. Cette exigence impose la nécessité de fournir un chargement / déchargement dynamique des ressources du programme avec une fluidité suffisante avec une consommation de mémoire raisonnable. Et il est souhaitable que le moteur contienne une telle fonctionnalité "prête à l'emploi"
3. Intégration pratique avec la pile technologique utilisée. Traditionnellement, pour des raisons objectives, pour notre développement, le logiciel ULK PS utilise le langage C ++ avec le cadre Qt comme IDE QtCreator et Git comme système de contrôle de version. En tant que plate-forme système ULK PS, un système d'exploitation basé sur le noyau Linux est utilisé

Quel est le problème avec Unity et UE? Quel est le fait que d'autres moteurs sont capables d'importer des ressources de formats complètement différents. Cependant, lors de l'assemblage du projet, ils sont irréversiblement convertis au format binaire interne, ce qui rend impossible l'ajout et la modification des ressources sans réassemblage du projet. Des technologies telles que les préfabriqués et les ensembles d'actifs disponibles dans Unity ne résolvent pas le problème, car l'éditeur de moteur n'est pas le meilleur endroit pour créer des emplacements ferroviaires, ce qui nécessite l'extension de l'éditeur, ce qui conduit à la nécessité d'écrire un «moteur à l'intérieur du moteur». De plus, la création de préfabriqués et de bundles est impossible sans l'utilisation de l'éditeur Unity, et cela, comme la pratique l'a montré, n'est pas très pratique, en particulier pour les modélisateurs purs et les concepteurs de niveaux. En ce qui concerne l'UE, j'ai posé beaucoup de questions à ce sujet et à d'autres ressources sur deux ans sur la façon de séparer le processus de construction d'un projet du processus d'ajout / de modification des ressources qu'il utilise, et je n'ai pas obtenu de réponse adéquate ni dans la documentation ni dans « invétérés "développeurs de jeux. Je serais très heureux (sans sarcasme) si je suis raisonnablement tombé sur quelque chose qui m'a manqué.

En ce qui concerne la deuxième exigence, Unity et UE semblent offrir la possibilité de créer des emplacements chargés dynamiquement, mais la question reste sans réponse, comment ces emplacements peuvent-ils être créés indépendamment de l'éditeur et sans reconstruire le projet? Il n'y a qu'une seule issue: écrire un «moteur à l'intérieur du moteur», qui chargera la géométrie et les textures «brutes» (dans l'un des formats d'exportation précédemment définis à partir des éditeurs 3D), leur appliquera tous les effets nécessaires et les positionnera dans l'espace en fonction des données décrites par un tiers indépendamment du format du moteur, qui doit encore être développé et appris à interpréter le moteur.

En relation avec ce qui précède, la question se pose - si pour résoudre ce problème, il est nécessaire d'écrire une couche logicielle puissante sur le moteur de jeu, dont la plupart des fonctionnalités ne sont tout simplement pas nécessaires dans le problème considéré, alors pourquoi avons-nous besoin d'un moteur de jeu?

Peut-être que le moteur graphique est suffisant? J'ai posé cette question à l'équipe précédente, qui a abordé le problème en discussion, en s'appuyant sur Unity (et a naturellement fusionné un peu plus tard). En réponse, il a reçu une contre-question: "Que proposez-vous?", Répondant à laquelle, dans l'esprit du texte ci-dessus, il a reçu un sourire sarcastique de l'adversaire.

Si vous ne faites pas de sarcasme, la tâche présentée est une tâche de visualisation typique - elle ne nécessite qu'un cadre pour travailler avec les graphiques, car la physique et le sous-système audio basé sur la physique sont implémentés côté serveur. Mon équipe et moi en sommes venus à comprendre ce fait, se déplaçant par l'inertie des développeurs précédents, d'abord vers Unity, via UE et essayant de fixer le sous-système graphique de l'un des simulateurs ferroviaires ouverts (OpenBVE, qui s'est d'ailleurs avéré, mais il est devenu une béquille temporaire)

OpenSceneGraph est de loin le moteur graphique le plus développé (ouvert et gratuit) axé sur le développement C ++. Il est largement utilisé à l'étranger précisément pour la visualisation technique en trois dimensions. Ce moteur n'a été épargné par aucun type de simulateur, dont le plus célèbre est FlightGear . Il y avait une fois un simulateur de chemin de fer basé sur ce moteur - Indra , qui, cependant, n'a laissé que des captures d'écran ennuyeuses du lien ci-dessus et son sort ultérieur ne m'est pas connu.

Dans le cadre de la tâche à accomplir, le moteur graphique OSG présente les qualités positives suivantes:

• Cross-platform, qui permet de l'appliquer dans l'écosystème GNU / Linux
• Le langage de développement est C ++ / STL, ce qui permet de l'intégrer facilement et naturellement dans le processus technologique de développement établi;
• La plus large gamme de formats de ressources est prise en charge «prête à l'emploi» - géométrie et textures 3D grâce au système de plug-in développé. Une interface simple et intuitive pour écrire vos propres plug-ins pour configurer le gestionnaire de ressources pour les formats non standard, que nous avons utilisé (j'écrirai à ce sujet ci-dessous);
• Un système de gestion de mémoire basé sur un modèle propriétaire de pointeurs intelligents (un format propriétaire de pointeurs intelligents a été utilisé historiquement, car il n'y avait pas de moteur de pointeur intelligent dans la norme C ++ au début du développement);
• Architecture modulaire flexible;
• Le gestionnaire d'objets de scène qui charge dynamiquement des objets, fournit le chargement et le rendu uniquement des objets qui se trouvent dans la pyramide de découpage (en raison de la classe osg :: PagedLOD)
• Capacité à s'intégrer au framework Qt. Grâce au modèle pratique «signaux - slots» fourni par Qt, qui simplifie et accélère considérablement le développement C ++, nous utilisons largement ce cadre pour développer des logiciels de formation complexes. En conséquence, nous avons accumulé une base de code importante réutilisée dans différents projets, notamment en ce qui concerne la bibliothèque de communication interprocessus basée sur des sockets TCP. L'utilisation des capacités de Qt dans le projet de sous-système vidéo semble être une décision logique;
• Qualité d'image suffisante pour la tâche à résoudre.

Il a fallu environ six mois d'étude intensive des capacités de l'OSG afin de «sonder le sol» en profondeur et de trouver des approches pour résoudre le problème avec ce moteur. Ce qui en est né mérite une discussion séparée.

4. De l'architecture au prototype fonctionnel

Le sous-système vidéo des simulateurs de formation sur le matériel roulant (HTSC) est une application cliente, couramment appelée video3d-client, et remplit les fonctions suivantes:

• Une demande de connexion à la partie serveur du simulateur, autorisation sur le serveur, suivie d'une demande périodique de l'identifiant de l'itinéraire chargé, puis de la position actuelle du train. Si la connexion est déconnectée du côté serveur, le système passe en mode veille pour se reconnecter;
• Téléchargement de l'itinéraire sélectionné, organisation de la gestion dynamique du contenu de la scène rendue;
• Rendre réellement la scène en fonction de la position actuelle du train sur l'itinéraire

Non pas que ce projet soit open source, mais le code d'une démo technologique complète peut être trouvé ici . Le projet comprend les modules suivants:

• système de fichiers - une bibliothèque pour travailler avec le système de fichiers, fournit la génération de chemins d'accès aux fichiers de configuration et aux ressources d'application
• bibliothèque - une implémentation multiplateforme du chargeur de bibliothèque dynamique. En général, une béquille écrite à un moment où les possibilités d'intégration avec Qt (où il y a un module QLibrary prêt pour la bataille) était encore vague
• osgdb_dmd - un plugin pour charger des modèles d'un format spécifique au moteur DGLEngine version 1.1. Pour ce qu'il fallait, j'expliquerai un peu plus bas
• route-loader est une bibliothèque qui fournit une interface abstraite au chargeur de route. Il est possible de charger des itinéraires au format arbitraire
• tcp-connection - bibliothèque de communication interprocessus sur les sockets TCP
• viewer - le module exécutable principal du programme
• zds-route-loader - plug-in pour charger des routes au format ZDSimulator

Lors de la conception du VTPS, la question s'est posée de savoir s'il fallait développer un format d'itinéraire indépendamment ou utiliser le format d'itinéraire existant, ainsi que des itinéraires prêts à l'emploi pour les chemins de fer nationaux pour le simulateur ferroviaire existant. Heureusement, la décision est venue - un produit propriétaire fermé ZDSimulatorpossédant la particularité d'être affûté pour le matériel roulant domestique et les spécificités du réseau ferroviaire. Malgré les éloges des auteurs du projet, il présente de nombreux inconvénients importants, mais il a un format simple et clair d'itinéraires accessibles au public. Au premier stade, c'était un péché de ne pas profiter de l'occasion, malgré le fait que la partie graphique du simulateur soit basée sur le moteur DGLEngine ouvert. Le problème est que ce moteur, bien qu'il soit en développement (l'état actuel du projet peut être vu ici ), mais sa deuxième version actuelle est incompatible avec la version 1.1, sur laquelle ZDSimulator est basé. Les codes sources de la version 1.1 sont perdus, les liens menant à eux se sont estompés depuis longtemps.

Une recherche approfondie dans les archives web a permis de retrouver les perdus et de les sauvegarder en postant DGLEngine v1.1sur gtihub. Ce moteur utilise son propre format spécifique de modèles 3D. Ayant la source du moteur, il était facile d'écrire le plug-in approprié pour OSG.

Ainsi, la tâche de création de HTPS a été réduite à l'écriture de la partie logicielle sur le moteur OSG. À l'avenir, il est prévu de développer son propre format de route, car le format actuel ne prévoit que la circulation le long des routes principales et présente un certain nombre d'inconvénients qui ne vous permettent pas de recréer un certain nombre de routes complexes.

La hiérarchie des principales classes de HTPS est présentée dans le diagramme suivant


La hiérarchie des classes du chargeur d'itinéraire ressemble à ceci:


Le chargeur de tout autre format de route peut être écrit comme un plugin contenant une classe qui hérite de la classe RouteLoader. Au début de VTPS, le chemin vers le répertoire avec la route lui est transféré, le format de la route est déterminé et le plug-in correspondant est chargé dynamiquement, qui effectue ensuite le reste du sale boulot.

Une nuance fondamentalement importante était l'intégration du moteur OSG et de Qt. Une telle intégration existe et est appelée osgQt . Cette bibliothèque n'a pas été utilisée dans ce projet pour deux raisons:

1. Pas besoin de commandes de fenêtres fournies par Qt. OSG a son propre système de gestion de fenêtre GUI assez développé et il n'est pas logique de clôturer l'interface graphique sur une autre interface graphique, car osgQt est principalement destiné à intégrer la visionneuse OSG dans l'interface graphique basée sur Qt
2. osgQt est soumis à un bug - opération incorrecte avec le contexte OpenGL, qui dans certains cas ne peut pas être divisé entre OSG et QGLWidget, en raison de laquelle la scène est affichée n'importe où, mais pas sur le widget Qt. De plus, il n'a pas encore été possible de trouver les raisons, car sur certains systèmes, ce bug ne se manifeste pas.

Il était entendu qu'une intégration avec Qt est nécessaire en termes d'utilisation du concept de «fentes de signal» pour assurer l'interaction avec le sous-système de réseau de connexion TCP qui utilise Qt et est la norme de facto dans nos conceptions. Je ne voulais vraiment pas compter sur le système de messagerie OSG et réécrire le client TCP (et même multiplateforme). Une solution élégante a été trouvée, basée sur le fait que si nous voulons qu'un objet envoie un signal qui déclenche un slot pour un autre objet, nous devons remplir trois conditions:

1. Hériter des classes interactives de QObject
2. Organiser une boucle de traitement du signal
3. Créez une instance de la classe QApplication (ou QCoreApplication) qui existe en mémoire pendant le fonctionnement de l'application

Dans ce cas, en aucun cas vous ne devez appeler QApplication :: exec (), qui démarre le cycle normal de traitement du signal, il suffit d'organiser un cycle dans lequel il est facile de traiter les signaux en appelant QApplication :: processEvents (). OSG a un tel cycle (le cycle dans lequel le rendu est effectué) et il est possible de créer un gestionnaire d'événements dans lequel l'événement osgGA :: GUIEventAdapter :: FRAME généré par le moteur lors du rendu de l'image suivante est traité. Ainsi, toute l'intégration a été réduite au code

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

après quoi, les classes héritées de QObject et de ses dérivés peuvent échanger des signaux jusqu'à ce que l'impulsion soit perdue.

Tout ce qui précède a permis pendant deux mois de créer le premier prototype fonctionnel de HTPS. Pour démontrer ce qui s'est finalement produit, je propose la section suivante de voyages expérimentaux sur des itinéraires réels. Je m'excuse à l'avance pour la qualité de la prise de vue - ils n'ont pas mis la main sur la technologie intelligente

Conclusion et conclusions

La principale conclusion, au moins pour notre équipe, était qu'il n'y avait pas de «balle grise» dans le choix de la technologie pour la mise en œuvre du projet. Les moteurs de jeux commercialisés de manière agressive ne sont pas toujours adaptés à la résolution de tâches spécifiques, notamment la visualisation des résultats de la modélisation de systèmes techniques. Et si elles conviennent, elles ne sont pas optimales en termes d'efforts consacrés au développement et à la maintenance du projet.

C'est dommage qu'un très bon moteur graphique OSG, et surtout gratuit, n'ait en fait pas de communauté dans notre pays. Afin de résoudre ce problème, j'écris ici une série d'articles sur la ressource (là j'ai rassemblé tous les liens vers des sources d'informations plus ou moins adéquates, y compris en russe). De plus, en tant que documentation décrivant les principes de base d'OSG, je peux également proposer ce blog . J'espère que quelqu'un trouvera ces informations utiles.

En ce qui concerne le HTSC, les travaux dans ce sens se poursuivent. Il reste encore beaucoup de tâches importantes à résoudre dans un avenir proche.

Merci de votre attention!

c) Centre pour le développement des compétences en innovation