1年ほど前に、私たちの大学が開発したES1 Lastochka電車の教育研究所（ULK）について話した出版物が出版されました。 次に、これがこのトピックに関する最後の出版物ではないことを約束しました。特に、このようなシミュレータの3次元視覚化の作成の問題について話し、それらを解決する主なアプローチの概要を説明すると脅しました。



昨年、私たちは次のリリースに満足しました-昨年8月に開催されたSapsan高速電気鉄道EVS2のULKです。 この電車の教育と実験室自体は別の話に値しますが、この出版物の文脈では、痛みについて話します-3次元可視化の適切なサブシステムを作成する問題、私たちのチームが約2年間さまざまな側面からアプローチしました。 Peregrine Falconシミュレーターのリリースは、この分野での開発の開発ベクトルを決定したため、特に重要です。

1. ULK EVS2 "Sapsan"について簡単に説明します

私は、私たちの大学で開発された鉄道車両の教育用および実験用の複合施設が機関車旅団の準備を目的としていないことを再度強調します（うらやましい頻度で行います）。 前の記事の解説者の一人が正しく指摘したように 、私たちのULKはシミュレータではなく、列車の動きの物理学の有能な実装と、その動きと停止を保証する車両サブシステムの動作のシミュレーションに主な重点を置いているシミュレータです。 Sapsanシミュレーターは例外ではなく、次のタスクが解決されます。

• 縦方向の力と軌道プロファイルを考慮して、列車の機械部分の動的モデルが実装されました
• 電車の主要なサブシステムの動作の詳細なコンピューターモデルが構築されました：電力電気回路、トラクション電気駆動、空気圧および電空ブレーキ
• さまざまなレベルでの電車制御システムの動作の基本的なアルゴリズムが再現されています。

さらに、訓練および実験施設には、主制御および情報表示設備を備えた電車のキャビンのフルサイズのモックアップが含まれます。 Swallowsシミュレーターとは異なり、このキャビンは私たちが独自に作成したものではなく、2015年にトレーニングシミュレーターの製造に携わる国内の有名なオフィスの1つから購入しました。 したがって、シミュレーターの開発プロセスは、ソフトウェアの作成に焦点を合わせました。





このようなシミュレータシミュレータ用のソフトウェアの開発は非常に広範な質問であり、将来（もしあれば）これらの問題に対する読者の関心を満足させるように（できる限り）試みますが、今は記事のメイントピックである列車の移動プロセスの3次元視覚化に戻りましょう。

2.過去の背景と技術

最後の記事へのコメントでは、率直に言って、私をとても楽しませた質問が尋ねられました。 はい、確かに、今日まだ使用されている多くのシミュレーターでは、このアプローチがまだ使用されています。ビデオは鉄道の実際のセクションで撮影され、移動の速度に比例した速度でシミュレーター上をスクロールします。 これが行われたのは、そのようなシミュレータが作成された当時、3次元グラフィックスの品質が望まれていなかったためであり、これは商用Unixの過酷なグラフィックステーションにも当てはまり、PCの問題はなかったからです。 したがって、コンピューターゲームのメーカー、たとえばこのメーカーでも、このアプローチを使用することをためらいませんでした。



これは、今日では意味がありません。理由は次のとおりです。

1. 低い列車速度での不十分なフレームレートは、画像更新の望ましい滑らかさを提供しません。 大切な25 fpsは、運転席からビデオが撮影された速度でのみ得られます。 そして、この致命的な欠陥は、高速カメラ（毎秒120フレームで撮影されたビデオの重量はどれくらいですか？同じことです...）によっても、中間フレームのプログラム生成によっても、決して克服することはできません。 後者はOpenCVテクノロジーを使用して行われましたが、通常の結果にはなりませんでした。 この質問はあらゆる側面から繰り返し研究され、その結果、そのようなシステムを作成するためのリソースのコストは、3Dグラフィックスに基づいた同様のシステムの開発をはるかに上回ると結論付けられました
2. ビデオをスムーズに後方にスクロールすることの難しさ。 そして、彼らが克服されることを考慮しても、プラットフォームに沿って走っている犬はどこで走りますか、私たちは逆に行くべきだと思いますか？
3. すべての「対話性」の欠如。 信号機の変化、にぎわいの動き、対向車と通過列車の動きをどうするか？

したがって、今日のソフトウェアまたはハードウェアの観点からは障害がないため、すべての最新のシミュレーターおよびシミュレーターは対話型3Dグラフィックを使用して作成されます。



ハードウェアの観点からすべてが非常に明確な場合-フロントガラスの代わりにインストールされたモニターは、通常のビデオカード（トップエンドのものでもない）でPCに接続されます。ソフトウェアの観点から、タスクを実現するためのテクノロジーを選択するという問題が生じます。

3.グラフィックエンジンとゲームエンジン、またはOpenSceneGraphが選ばれた理由

誤解される可能性がありますが、事前にコメントを予想していますが、これは完全に論理的な質問をします。既存のテクノロジーを分析するときに、UnityやUnreal Engine 4などのマストドンで選択が止まらなかったのはなぜですか？ この質問に答えます。さらに、答えを正当化します。



簡単に説明すると、UnityもUnreal Engineも、解決するタスクの要件を満たしていません。 より詳細な回答は、まず、問題の要件のリストを提供します。 3次元視覚化のサブシステムで私たちがコンパイルしたTKには、次の規定が（重要度の降順で）含まれています。

1. 視覚化サブシステムのソフトウェア開発プロセスと、そのためのリソースを作成するプロセスの独立性。 この場合のリソースには、3次元モデル、テクスチャ、いわゆるルートが含まれます。 ルートは、ビデオサブシステムが鉄道の目的のセクションを表示し、それに沿った列車の動きのシミュレーションを提供できるようにする構成オブジェクトとリソースの組み合わせとして理解されます。 これには、ビデオサブシステムのソフトウェア部分を再組み立てせずにルートを変更する可能性も含まれます。
2. 長さ無制限のルートを作成します。 ハードウェアリソースが限られているため、原則として無制限の長さは達成できないことを予約します。 この要件は、ルートの長さが少なくとも1つの「肩」内、つまり方向転換点間の道路のセクション内にある必要があることを理解する必要があり、これはさまざまな要因に応じて、100キロメートル以上と推定される十分に長い距離です。 この要件により、プログラムリソースの動的なロード/アンロードを適切なメモリ消費で十分にスムーズに行う必要があります。 そして、エンジンには「箱から出してすぐに」そのような機能が含まれていることが望ましい
3. 使用済み技術スタックとの便利な統合。 従来、客観的な理由から、再びULK PSソフトウェアの開発のために、私たちのチームはQtCreator IDEとしてQtフレームワークを使用し、バージョン管理システムとしてGitを使用します。 システムプラットフォームULK PSとして、Linuxカーネルに基づくOSが使用されます

UnityとUEの何が問題になっていますか？ 他のエンジンが完全に異なる形式のリソースをインポートできるという事実は何ですか。 ただし、プロジェクトをアセンブルする場合、それらは内部バイナリ形式に不可逆的に変換されるため、プロジェクトを再アセンブルせずにリソースを追加および変更することはできません。 エンジンエディターは鉄道の場所を作成するのに最適な場所ではないため、Unityで利用可能なプレハブやアセットバンドルなどの技術では問題を解決できません。そのため、エディターの拡張が必要になり、「エンジン内のエンジン」を記述する必要が生じます。 さらに、Unityエディターを使用しないと、プレハブとバンドルの作成は不可能です。これは、実践が示しているように、特に純粋なモデラーやレベルデザイナーにとってはあまり便利ではありません。 UEについては、プロジェクトの構築プロセスを、使用するリソースの追加/変更プロセスからプロジェクトを分離する方法について、2年以上にわたってこのリソースや他のリソースについて非常に多くの質問をしましたが、ドキュメントまたは「 「ゲーム開発者を熱心に。 私が見逃した何かに合理的につまずいた場合、私は非常にうれしいです（皮肉なし）。



2番目の要件については、UnityとUEの両方が動的にロードされた場所を作成する機能を提供しているように見えますが、質問には答えがありません。 唯一の方法があります-「エンジン内のエンジン」を記述し、「生の」（3Dエディターから以前に指定されたエクスポート形式のいずれかで）ジオメトリとテクスチャを読み込み、必要なすべての効果をそれらに適用し、サードパーティで説明されたデータに基づいて空間に配置します、エンジン形式とは関係なく、エンジンを解釈するために開発および指導する必要があります。



上記に関連して、問題が発生します-この問題を解決するには、ゲームエンジン上に強力なソフトウェアレイヤーを記述する必要がありますが、その機能のほとんどは検討中の問題では単に必要ではないのに、なぜゲームエンジンが必要なのでしょうか？



グラフィックエンジンで十分でしょうか？ 私はこの問題を前のチームに尋ねました。前のチームは議論中の問題に取り組み、Unityに依存していました（そして、少し後に自然にマージされました）。 それに応じて、彼は「あなたは何を提案しますか？」という反問を受け取りました。そして、上記のテキストの精神で、彼は敵の皮肉な笑顔を受けました。



皮肉なしで行う場合、提示されたタスクは典型的な視覚化タスクです。物理学と物理学に基づくオーディオサブシステムの両方がサーバー側で実装されるため、グラフィックスを操作するためのフレームワークのみが必要です。 私のチームと私はこの事実を理解するようになり、以前の開発者の慣性によって、最初にUEを介してUnityに向かって移動し、オープン鉄道シミュレーターの1つからグラフィックサブシステムを固定しようとしました（OpenBVEは、結果的に一時的な松葉杖になりました）



OpenSceneGraphは、C ++開発に特化した、最も開発された（オープンで無料の）グラフィックエンジンです。 技術的な3次元視覚化のために、海外で正確に広く使用されています。 このエンジンは、 FlightGearが最も有名などの種類のシミュレータにもspareしまれていませんでした。 かつて、このエンジンに基づく鉄道シミュレータがありました- インドラ 、しかし、そこから、上のリンクから鈍いスクリーンショットだけがありました、そして、それ以上の運命は私に知られていませんでした。



手元のタスクのコンテキストでは、OSGグラフィックエンジンには次の利点があります。

• クロスプラットフォーム。GNU/ Linuxエコシステムでの適用を可能にします
• 開発言語はC ++ / STLであり、確立された開発の技術プロセスに簡単かつ自然に統合できます。
• 開発されたプラグインシステムにより、3次元のジオメトリとテクスチャ-最も広範なリソースフォーマットが「そのまま」サポートされました。 リソースマネージャーを非標準形式に設定するための独自のプラグインを作成するためのシンプルで直感的なインターフェイス（これについては以下で説明します）。
• スマートポインターの独自モデルに基づくメモリ管理システム（開発の最初にC ++標準にスマートポインターエンジンがなかったため、歴史的にスマートポインターの独自形式が使用されてきました）。
• 柔軟なモジュール式アーキテクチャ。
• オブジェクトを動的にロードし、クリッピングピラミッド内にあるオブジェクトのみのロードとレンダリングを提供するシーンオブジェクトマネージャー（osg :: PagedLODクラスにより）
• Qtフレームワークと統合する機能。 Q ++が提供する便利な「シグナル-スロット」モデルのおかげで、C ++開発が大幅に簡素化および高速化され、複雑なソフトウェアのトレーニングにこのフレームワークが広く使用されています。 したがって、特にTCPソケットに基づくプロセス間通信のライブラリに関して、さまざまなプロジェクトで再利用される重要なコードベースを蓄積しました。 ビデオサブシステムプロジェクトでQtの機能を使用することは論理的な決定のようです。
• 解決するタスクに十分な画質。

OSG機能を徹底的に「調査」し、このエンジンを使用して問題を解決するためのアプローチを見つけるには、約6か月の集中的な研究が必要でした。 結果として生まれたものは別の議論に値します。

4.アーキテクチャから実用プロトタイプまで

車両訓練シミュレータ（HTSC）のビデオサブシステムは、video3d-clientと呼ばれるクライアントアプリケーションであり、次の機能を実行します。

• シミュレーターのサーバー部分への接続要求、サーバーでの承認、それに続くロードされたルートの識別子の定期的な要求、そして列車の現在位置。 接続がサーバー側から切断されると、システムは再接続のためにスタンバイモードに切り替わります。
• 選択したルートをダウンロードし、レンダリングされたシーンのコンテンツの動的管理を整理します。
• ルート上の列車の現在位置に従って実際にシーンをレンダリングする

このプロジェクトがオープンソースだったわけではありませんが、フル機能のテクノロジーデモのコードはこちらにあります 。 プロジェクトは、次のモジュールで構成されています。

• filesystem-ファイルシステムを操作するためのライブラリ。構成ファイルとアプリケーションリソースへのパスを生成します。
• library-ダイナミックライブラリローダーのクロスプラットフォーム実装。 一般に、Qt（戦闘の準備ができているQLibraryモジュールがある）との統合の可能性がまだ曖昧だったときに書かれた松葉杖
• osgdb_dmd -DGLEngineエンジンバージョン1.1に固有の形式のモデルをロードするためのプラグイン。 それが必要だったものについては、もう少し低めに説明します
• ルートローダーは、ルートローダーへの抽象的なインターフェースを提供するライブラリです。 任意の形式のルートをロードすることが可能です
• tcp-connection -TCPソケットを介したプロセス間通信ライブラリ
• viewer-プログラムのメインの実行可能モジュール
• zds-route-loader -ZDSimulator形式のルートをロードするためのプラグイン

HTPSを設計するとき、路線形式を独自に開発するか、既存の路線形式を使用するか、既存の鉄道シミュレータ用に国内鉄道の既成路線を使用するかという疑問が生じました。 幸いなことに、決定が出されました-クローズドプロプライエタリ製品ZDSimulatorは 、国内の鉄道車両と鉄道網の仕様に合わせて調整されているという特徴を持っています。 プロジェクトの作者の称賛にもかかわらず、多くの重大な欠点がありますが、同時にパブリックドメインにあるルートのシンプルで明確な形式があります。 シミュレータのグラフィック部分がオープンDGLEngineエンジンに基づいているという事実にもかかわらず、最初の段階では、機会をつかまないことは罪でした。 問題は、このエンジンは開発中ですが（プロジェクトの現在の状態はこちらで確認できます ）、現在の2番目のバージョンはZDSimulatorのベースであるバージョン1.1と互換性がないということです。 バージョン1.1のソースコードは失われ、それらにつながるリンクは長い間消えていきました。



Webアーカイブを徹底的に検索することで、 GtihubにDGLEngine v1.1を投稿することにより、紛失したものを見つけて保存することができました。 このエンジンは、独自の特定の形式の3Dモデルを使用します。 エンジンのソースがあれば、OSGに対応するプラグインを作成することは難しくありませんでした。



したがって、HTPSを作成するタスクは、OSGエンジンでソフトウェアパーツを作成することになりました。 将来的には、独自のルート形式を開発する予定です。現在の形式では、メインルートに沿った移動のみが可能で、多くの複雑なルートを再作成できない多くの欠点があります。



HTPSの主要なクラスの階層を次の図に示します









ルートローダーのクラスローダーは次のようになります









他のルート形式のローダーは、RouteLoaderクラスを継承するクラスを含むプラグインとして作成できます。 VTPSの開始時に、ルートのあるディレクトリへのパスが転送され、ルートの形式が決定され、対応するプラグインが動的にロードされ、残りのダーティな作業が実行されます。



基本的に重要なニュアンスは、OSGエンジンとQtの統合です。 このような統合が存在し、 osgQtと呼ばれます 。 このライブラリは、次の2つの理由でこのプロジェクトでは使用されませんでした。

1. Qtが提供するウィンドウコントロールは不要です。 OSGには独自にかなり開発されたGUIウィンドウ管理システムがあり、osgQtは主にOSGビューアーをQtベースのGUIに統合することを目的としているため、GUIを別のGUIの上にフェンスすることは意味がありません
2. osgQtにはバグがあります。OpenGLコンテキストの誤った操作は、OSGとQGLWidgetに分割できない場合があり、シーンがQtウィジェットではなくどこにでも表示されるためです。 さらに、一部のシステムではこのバグが発生しないため、理由を見つけることはまだできていません。

「信号スロット」の概念を使用して、Qtを使用し、設計のデファクトスタンダードであるtcp接続ネットワークサブシステムとの相互作用を確保するために、Qtとの統合が必要であるという理解がありました。 OSGメッセージングシステムに依存して、TCPクライアント（およびクロスプラットフォーム）を書き直したくはありませんでした。 あるオブジェクトから別のオブジェクトのスロットをトリガーする信号を送信する場合、次の3つの条件を満たす必要があるという事実に基づいて、エレガントなソリューションが見つかりました。

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とその派生クラスから継承されたクラスは、パルスが失われるまで信号を交換できます。



上記のすべてで、HTPSの最初の実用プロトタイプを作成するのに2か月かかりました。 最後に何が起こったのかを示すために、実際のルートでの実験旅行から次のセクションを提案します。 撮影の質について事前に謝罪します-彼らはスマートな技術を手に入れませんでした

結論と結論

少なくとも私たちのチームにとっての主な結論は、プロジェクトを実装するための技術の選択に「灰色の弾丸」はなかったということでした。 積極的に販売されているゲームエンジンは、技術システムのモデリング結果の視覚化など、特定のタスクの解決に必ずしも適しているとは限りません。 そして、それらが適切であれば、プロジェクトの開発と保守に費やされた努力の観点からは最適ではありません。



非常に優れた、そして最も重要な無料のグラフィックエンジンOSGが実際に私たちの国にコミュニティを持っていないことは残念です。 この問題を解決するために、リソースに関する一連の記事をここに書き込みます （ロシア語を含む、多かれ少なかれ適切な情報源へのすべてのリンクを収集しました）。 さらに、OSGの基本原則を説明するドキュメントとして、 このブログを提供することもできます。 誰かがこの情報が役立つことを願っています。



HTSCに関しては、この方向の作業が継続されます。 近い将来解決すべき重要なタスクがまだたくさんあります。



ご清聴ありがとうございました！



（c）革新的能力開発センター