CADビジュアライゼーション：別の3Dエンジンを作成した理由とその仕組み

1995年以来、C3D Labsチームは、コンピューター支援設計（CAD）システムを作成するための重要な技術コンポーネントであるジオメトリコアを作成しています。 2年前、私たちは独自の視覚化モジュールC3D Visionをリリースしました。 なぜ別の3Dエンジンが必要なのですか？







CAD開発者向けのレンダリングには、常に特定の困難が伴います。 既製の商用ビジュアライザーまたはオープンソースビジュアライザーを使用する場合、それらのほとんどはもともとゲーム業界向けに作成されたものであり、CAD / CAM / CAEアプリケーションのエンジニアリングの仕様を満たしていません。



ゲームエンジンは、テクスチャ、スプライト、アニメーションで動作します。 また、エンジニアリングアプリケーションには主にジオメトリツールが必要です。

• ロケーター-カーソルの画面座標を現在の幾何学的オブジェクトに変換します
• snap-幾何学的オブジェクトの正確な座標を計算します
• マニピュレータタグ-構築するモデルと対話的に対話できます。

ゲームエンジンにはないCADに重要な3つのツールを挙げましたが、さらに多くのツールがあります。



すべての開発者が独自のエンジンを作成できるわけではありません。 高価で長く、メイン製品から注意をそらすもの。 そのため、特殊なCADエンジンに対する自然な要求がありました。 世界には、たとえば、Hoops、Redwayがありますが、それらは非常に高価であり、さらに、すでに開発されたジオメトリックコアとの統合が必要です。 なぜなら、最高のビジュアライザーは、使用される数学コア全体で機能するビジュアライザーだからです。



2016年までは、独自のエンジンはありませんでした。 開発者にカーネルを提供しました

幾何学的モデリング（CADの「頭脳」）、幾何学的制約ソルバーおよびデータ交換モジュール。 また、視覚化に関する質問が定期的に寄せられました。 顧客は、エンジンをカーネルで取得することを望み、サードパーティコンポーネントの統合には関与しませんでした。 そのため、特にその時点ではCADを作成するためのコンポーネントの完全なセットを提供している会社はなかったため、独自のエンジンを作成するという決定が生まれました。 そして今、私たちは、カーネル、ソルバー、コンバーター、およびビジュアライザーの4つのコンポーネントすべてを開発する唯一の存在です。 同時に、当社の3Dエンジンは、他の開発者からのコンポーネントを備えたスタンドアロンモジュールとしても使用できます。

なぜOpenGLではありませんか？

実際、OpenGL仕様は多くのCADシステムの視覚化に使用されていますが、重大な欠点があります。 すべての機能について、シーンを記述するための構造APIはありません。また、インターフェイスは3次元レンダリングの基本的なツールのみを提供します。 これにより、開発者が補助コードを使用せずにOpenGL APIを使用することが非常に難しくなります。通常、補助コードは独自に実装され、多くの時間とリソースが必要です。 開発者に視覚化シーンの構造記述の特定の手段を提供し、シーンとのインタラクティブな相互作用に必要なツールのセットも備えた、より高いレベルのツールを提案しました。



OpenGL標準はウィンドウシステムに接続されておらず、オープンシステムで広く普及していることを考慮しました。 OpenGL仕様では、GLX拡張機能を使用しています。GLX拡張機能は、X Window Systemのカーネルプロトコルに属し、OpenGLとX Windowの相互作用を可能にします。 この拡張機能は、Xサーバーをバイパスして直接レンダリングを編成するため、分散X環境で動作する効率的なアプリケーションを実装できます。 これらの機能はすべて、ビジュアライザーで使用されます。

C3D Visionでのデータの視覚化

C3D Visionは、最小限の労力で本格的なグラフィカルアプリケーションを構築する機能的な「ブリック」のセットです。 私たちのビジュアライザーはアーキテクチャをスケーリングする能力を持っているので、開発者はオブジェクトの独自のクラスを作成し、既存のオブジェクトからそれらを継承することができます。 必要に応じて、シーン内のオブジェクトのレンダリングまでクラスを定義できます。



C3D Visionに基づいて作成されたグラフィックアプリケーションは、シーンの幾何学的表現、つまり、アクティブウィンドウに描画されるセグメント、サーフェス、エッジ、およびその他のオブジェクトで動作します。 ユーザーとグラフィックスアプリケーションの直接的な対話には、シーン表示の特定の表現があります。 表現が階層構造を持たず、オブジェクトの単純な線形配列で表現されていると仮定すると、これにより、非表示オブジェクトの切り取りやシーンオブジェクトの検索などの効果的な方法を使用することが難しくなります。



階層構造でシーンビューを使用すると、いくつかの利点があります。 この場合、シーンオブジェクトの機能は非常に似ており、より高いレベルのグループに結合される個別のグループに区別できます。 同様に、階層的な原則を適用すると、必然的に、よく知られているグラフィック標準PHIGS（プログラマーの階層型インタラクティブグラフィックシステム）につながります。





C3D Visionの一般化されたシーン表現スキーム（写真はクリック可能）



3Dエンジンの開発に適用されたのは階層的な原理であったため、その中のシーンの説明は、オブジェクトとして端末ノードまたはノードのグループを持つグラフの形式で提示されます。 このシーンセグメントの表現ではグラフのノードとして機能するため、「シーンセグメンテーション」の定義を導入しました。 親を持たないセグメントは、ルートセグメントと呼ばれます（英語-ルートから）。 セグメントは、材料、形状などのプロパティでグループ化できます。 さらに、一連のセグメント、特にテンプレートグループの作成が可能で、その有効期間はユーザーが決定します。 特定のセグメントなどを編集するために事前に作成された一連のマニピュレータにすることができます。



シーングラフはコンテナに属します。コンテナには、グラフの操作に必要な多くの機能と描画チャネルがあります。 しかし、おそらく、C3D Visionの最も重要な特性の1つは、ユーザーがこのような多くのコンテナを作成するのに決して制限がないことです。 重要な基準のリスト全体で異なる複数の独立したグラフを形成できます。

このアプローチにより、ビジュアライザーの作業に高い柔軟性が保証され、レンダリングパフォーマンスを最大にするために微調整することが可能になります。



シーンセグメンテーションの使用は、コンポーネントに分割されたオブジェクトを操作する便利さだけでなく、次のような他のタスクを実装する必要があるためにも発生します。

• セグメントパラメータの変更-オブジェクトの移動と回転、可視性の切り替えと確認、マテリアルと光源の設定など
• 便利な方法でモデルツリーを再構築する-セグメントの作成と削除、またはグラフの他のセグメントとの結合
• 各セグメントに必要なアクションでシーングラフを走査する
• OpenGLを使用してシーン全体をレンダリングします。

シーンのセグメンテーション

開発者が特定のテンプレートに従ってオブジェクトを操作し、必要に応じて独自のタイプのオブジェクトを作成できるようにするために、有向非周期グラフの形式でシーンのセグメンテーションを実装しました。 このようなグラフの編成により、シーンの論理表現を作成して、より効率的なレンダリングを実現できます。





有向非巡回グラフの形式でのシーンの表現（写真はクリック可能）



グラフのセグメントには、ジオメトリデータまたは後続の描画用のこのデータへのリンクを含めることができますが、参照ジオメトリを使用すると、RAMとビデオメモリを大幅に節約できます。 グラフの中間セグメントでは、サブセグメントをグループ化し、それらに対して特定のアクションを実行できます。 グラフの各セグメントには独自の変換マトリックスがあり、すべての着信サブセグメントに影響します。 このマトリックスを変更することにより、空間内のジオメトリの位置を変更できます：回転、シフトなどを実行します。



シーングラフの各セグメントには独自の座標系があり、セグメントマトリックスは、サブセグメントの座標系で指定されたポリゴンモデルを、問題のセグメントの独自の座標系に変換します。 現在のセグメントからシーングラフのルートセグメントへのすべてのマトリックスの積は、現在のセグメントのローカル座標系からワールド座標系への変換マトリックスを形成するため、この場合、グローバル座標系はルートセグメントに関連付けられます。 シーンのセグメンテーションの例として、タレットとリフティングローターを備えた掘削機の3Dモデルを示します。





スイベルタワーとリフトツールを備えたバケットホイールショベルのモデル：1-追跡プラットフォーム。 2-旋回ギア; 3-回転式プラットフォーム。 4-カウンターウェイト; 5-タワー; 6-キャビン; 7-回転式作業体



掘削機モデルに基づいて、シーングラフを再現します。 大きなメカニズム1-3-4-5のみを使用します。つまり、キーフラグメントによってシーンをセグメント化します。





バケットホイールショベルのシーンのセグメンテーション（写真はクリック可能）



追跡されたプラットフォームセグメントはルートセグメントから継承され、ディスプレイスメントマトリックスが含まれていることがわかります。 移動の変換中、このマトリックスの変更はすべてのサブセグメントに影響を与えるため、掘削機は移動中に移動します。 したがって、ターンテーブルのマトリックスに沿った変換は、サブセグメントを含むグループ全体を回転させます。 シーングラフ全体のサブグラフを形成するセグメントのグループは、多数の着信オブジェクトで構成される個別のオブジェクトと見なすことができます。 たとえば、座席のある車は分割できないオブジェクトとして表すことができますが、実際には多くの幾何学的オブジェクトで構成されています。



このアプローチを使用すると、シーン内のオブジェクトの位置を管理するための多くの便利なタスクを解決できます。 1つの中間セグメントのマトリックスを変換して、すべての着信セグメント、したがってすべてのジオメトリのシーンの位置を一度に変更するだけで十分です。 車の移動の問題が解決されると、座席、ハンドル、ペダル、乗客のいる運転手などのすべてのコンテンツも、他のローカルタスクを実行するために障害物を整理することなく移動します。 セグメントに対するアクションは、主にそのサブセグメントに適用されることを強調する必要があります。



参照ジオメトリについて説明します。 通常、シーングラフには多数のサブグラフが含まれ、それらは子サブグラフを形成するいくつかの子孫です。 最後に、後者は独自のジオメトリを持つ場合があります。 多くの既存のモデルを考慮すると、それらのほとんどがジオメトリに違いがないことが明らかになります。 同じ自動車には同じ形状とサイズの4つの車輪があるため、そのようなジオメトリを1つのコピーに格納し、個々のマトリックスを使用して車輪の位置の違いを判断するのが合理的です。 C3D Visionでは、ジオメトリ参照をシーングラフの特定のセグメントに割り当てる機能を実装しました。







参照ジオメトリを使用したシーンのセグメンテーション（写真はクリック可能）



シーングラフの最も重要なプロパティの1つは、各セグメントの表示状態を保存することです。 この場合、テクスチャ、シェーダー、マテリアルなどの他のセグメントプロパティでレンダリングする前にOpenGLを準備することについて話します。 多くのセグメントプロパティの割り当ては、サブセグメント、つまりサブグラフ全体にまで及びます。



シーンのセグメンテーションを使用すると、シーン全体のグラフに関連するいくつかのグローバルな問題を解決できます。 まず、レンダリングの最適化です。 描画する必要があるオブジェクトが多いほど、シーンの変化を計算してモニターに表示するのに必要なコンピューター時間が長くなります。



長期間にわたって、多数のオブジェクトが画面領域の外側または他のオブジェクトの内側に配置されます。 したがって、そのようなオブジェクトの計算は無視され、それらを非表示にし、画面への出力から単純に削除することができます。 これは、オブジェクトが仮想カメラのスコープ内に収まらない場合、レンダリングのためにビデオアダプタに送信する必要がないため、シーンのレンダリングパフォーマンスにプラスの影響を与えます。



シーングラフを使用すると、このようなオブジェクトを簡単に見つけることができます。 これを行うには、各セグメントで境界のある長方形または球が計算されます。 次に、すべての子サブグラフとセグメントがそれに追加され、シーンを描画する直前に、シーンセグメントの境界球体といわゆる可視性のピラミッドとの交差が計算されます。 その結果、シーングラフのすべての表示セグメントのソート済みリストが作成されます。 マイナーシーンエレメントをカットするためのこのメカニズムは、Frustum Culling最適化モードの典型です。

シーンセグメンテーションの基本機能によってユーザーに提供される利点を評価するために、次のことに注意してください。

• ユーザーフォームのプレゼンテーションは特定のテンプレートに縮小されます。これにより、ユーザーが独自のフォームを簡単に作成できるようになります。低レベルのプレゼンテーションの使用が不要になるためです。
• グラフの概念を使用して、ユーザーはシーンのセグメントをレイヤーの形で作成し、その後の構成を行うことができます。 実際、シーングラフはレイヤーのセットであり、各レイヤーは非表示、半透明、またはブロック（読み取り専用）に設定できます。 レイヤーとグループはシーンセグメントによって表されるため、レイヤーとグループの間で構造表現に内部的な違いはないことに注意してください
• モデルのオブジェクト（車の座席）間の論理的な接続は、モデル（車）の拡張として表されますが、シーンのセグメンテーションは、さまざまなオブジェクトの空間的な関係も記述することができます
• 大規模なアプリケーションでは、モデルを設計するときに、計算の最適化に経済的な使用が不可欠であるため、RAMとビデオメモリの使用に対する要求が高まります。 これらの目的のために、C3D Visionは参照ジオメトリを使用してシーンを操作するメカニズムを実装しました
• 階層的なアプローチをシーングラフの構築に適用すると、たとえば、効率的なクリッピングやシーンオブジェクトの衝突の迅速な検出など、BVHジオメトリの空間分割など、グローバルな問題を解決する可能性が広がります。

舞台照明

C3D Visionでの光の実装は、オブジェクトを可視化するため、実際の光源と同じ役割を果たします。 モデルのどの部分がシーンの平面への投影に関与するかを決定するのは、コンピューター画面であろうと携帯電話ディスプレイであろうと、光源です。 いくつかの光源自体がある場合があり、対応するC3D Visionオブジェクトはさまざまな照明効果を模倣できます。 すべてのオブジェクトは、実際の光源の動作に基づいてモデル化されます。 重要な機能-シーンには、仮想シーンのオブジェクトが見えるように少なくとも1つの光源が必要です。



現在、C3D Visionはいくつかのタイプの光源を実装しています。

• ポイントライト -光源が特定の場所を占有し、この位置から光を放射する間、近光源に似たステージ照明を実装します（SetPosition関数）。 ステージ上のオブジェクトも、光源に対する位置と距離に応じて点灯します。 距離に応じて光源の減衰の強さを決定する減衰パラメータを設定できるだけでなく、光源の減衰の定数または線形/二次補間の値も設定できます。
• 方向ライト -リモート光源に似たステージ照明を実装します。 光源の方向は、近接光源の場合のように、SetPosition関数を使用して特定の場所を指定せずに決定されます。
• スポットライト -場所と方向を持ち、ポイントライトソースに似たステージ照明を実装します。 この場合、ライトは円錐形の領域に投影され（SetSpotCutoffAngle関数）、その値はラジアンで設定されます。

仮想カメラ

ほとんどの人は、画像を仮想カメラのファインダーに映る空間として認識します。 しかし、この種のカメラのOpenGL実装には存在しません。 したがって、視聴者に対するシーンの動きまたは回転の錯覚を形成するには、そのような実装を作成する必要があります。



C3D Visionのカメラを使用すると、ほぼすべての画像を取得できます。 カメラは、世界をキャプチャして観察者に表示するデバイスです。 提示されたカメラ機能を操作することで、固有の設定とアクション、特に軌道または原点を基準としたシーン全体の回転、パン、ズーム、ビュー軸の周りの回転などを設定できます。



ビジュアライザーには、カメラの位置を制御するためのツールが多数あります。 これらのツールはすべて、ライブラリクラスProcessから継承されます。Processは、マウスとキーボードからイベントを受け取り、これらのデバイスを操作する際のユーザーアクションをカメラで直接アクションとして解釈します。 既製のツールの実装に加えて、開発者には、カメラの制御に必要な独自のソフトウェアツールをProcessクラスに基づいて作成する機会が与えられます。

C3D Visionは他に何ができますか？

C3D Visionの重要な機能は、プログラムコードをスケーリングし、ユーザー独自のオブジェクトとインタラクティブプロセスを作成して、ソースライブラリのツール機能を拡張する機能です。 ビジュアライザーは、ジオメトリックコアC3Dモデラーに基づいています。 つまり、プロジェクトで一連のC3D Toolkitコンポーネントの数学的部分を使用すると、C3D Visionオブジェクトとの結合が直接サポートされ、開発者自身のアプリケーションの開発が大幅に促進されます。



シェーダーのサポート、シーンオブジェクトの選択、LODテクノロジーを使用したディテールの詳細、半透明オブジェクトのサポート、ピクセルカリングについては考慮しませんでした。このすべての視覚化モジュールは、その方法も知っています。

現在、2番目のバージョンに取り組んでいます。 コンピューター支援設計システム向けの新しいツールと機能を紹介します。



興味のある開発者は、C3D Visionをテストできます。 このモジュールは、当社のWebサイトでのリクエストに応じて、3か月間無料で提供されます。



Eduard Maksimenko、博士、C3D Vision、開発部長