JP2007220090A - Ｐｌｍデータベース内のオブジェクトを表示する処理および本処理を実装した装置 - Google Patents

Abstract

【課題】複数の部品を備えたＣＡＤ製品の効率的な表示を可能にする。
【解決手段】モデル化されたオブジェクトを含むＰＬＭデータベースとグラフィカル・ユーザ・インターフェースとを提供するステップと、レンダリングされることになるオブジェクト（２１−２４）のビュー上に視点を特定するステップと、視点に従ってビューをレンダリングするステップとを備え、前記レンダリングするステップがビュー内の複数の位置を決定するステップと、データベースを検索して、その中のモデル化されたオブジェクトを決定された位置に従って特定するステップと、ビューをレンダリングするために、特定されたモデル化されたオブジェクトをグラフィカル・ユーザ・インターフェース内に付加的に表示するステップと備える。
【選択図】図４

Description

本発明は、コンピュータに実装した方法とシステムとの分野に関し、さらに詳しくは、モデル化されたオブジェクトを描写するデータのデータベースを含む、製品ライフサイクル管理ソリューションに関する。

例えば商標ＣＡＴＩＡの下でＤＡＳＳＡＵＬＴ ＳＹＳＴＥＭＥＳによって提供される、部品あるいは部品のアセンブリを設計するために、多くのシステムおよびソリューションが市場で提供されている。これらのいわゆるコンピュータ支援設計（ＣＡＤ）システムにより、ユーザは、オブジェクトまたはオブジェクトのアセンブリの複雑な３次元（３Ｄ）モデルを構築し、操作し、表示させることが可能になる。ＣＡＤシステムは、辺または線、ある場合には面を用いて、モデル化されたオブジェクトの描写を提供する。線または辺は、さまざまなやり方で、例えば、非一様有理Ｂスプライン（ＮＵＲＢＳ）で、描写されてもよい。これらのＣＡＤシステムは、部品あるいは部品のアセンブリを、モデル化されたオブジェクトとして管理し、これは本質的に構造(geometry)の仕様(specification)である。具体的には、ＣＡＤファイルは仕様を有しており、そこから構造が生成され、構造から描写が生成される。仕様、構造、および描写は、１または複数のＣＡＤファイル内に格納されてもよい。ＣＡＤシステムは、モデル化されたオブジェクトを設計者に描写するためのグラフィックツールを含むが、これらのツールは複雑なオブジェクトの表示専用であり、ＣＡＤシステム内のあるオブジェクトを描写するファイルの典型的なサイズは、部品についてはメガバイトの範囲にあり、そしてアセンブリは数千もの部品を備えていることもある。ＣＡＤシステムはオブジェクトのモデルを管理するが、それらは電子ファイル内に格納される。

また、商標ＣＡＴＩＡ、ＥＮＯＶＩＡ、ＤＥＬＭＩＡの下でＤＡＳＳＡＵＬＴ ＳＹＳＴＥＭＥＳによって提供される一連の製品のような、製品ライフサイクル管理（ＰＬＭ）ソリューションも存在し、これらのソリューションは、製品設計の知識を体系化する技術ハブと、製造技術の知識を管理する製造ハブと、技術ハブと製造ハブの事業統合と連携を可能にする事業ハブとを提供するものである。全体として、これらのシステムが、製品と処理とリソースとをつなぐオープンなオブジェクトモデルを提供し、最適化された製品定義、製造の準備、生産およびサービスを提供する動的でナレッジ・ベースの製品創造と意思決定支援が可能になる。

このようなＰＬＭソリューションは、製品のリレーショナル・データベースを備えている。データベースは通常、迅速な検索および取り出しのために体系化されたデータの集合（典型的には、データおよびデータ間の関係）として定義される。データベースは、多様なデータ処理操作に関連して、データの格納、取り出し、修正、削除を容易にするよう構成されている。データベースは一般に、レコードに分割され得るファイルまたはファイルの組で構成され、各レコードは１つ以上のフィールドで構成される。フィールドは、データ格納の基本単位である。ユーザはまずクエリを通じてデータベース情報を取り出す。使用中のデータベース管理システムの規則に従って、特定のデータの集合について取り出して報告を作成するために、キーワードとソート・コマンドを使用して、ユーザは多くのレコード内のフィールドを迅速に取り出し、再構成し、グループ化し、選択することができる。

ＰＬＭソリューションを使用する際、基本的にユーザに必要なのは、１千個のオブジェクト／部品で出来ている複雑な製品を視覚化することであり、これは、場合によっては異なるいろいろなビューあるいは異なる視点（バーチャルカメラ）による。ユーザは、表示されているモデル化された製品を見ながら、視点を大きく修正してもよい。ユーザはまた、編集（すなわち、場合によってはそれを修正する）等のために所与の部品を選択することを望むことがある。

この問題の標準的な解決法は、モデルの３次元グラフィック描写および前記オブジェクトについてのすべての情報、例えば構造や制約等だけでなく他のオブジェクトへのハイパーリンクをも含む、前記オブジェクトのアセンブリに対応するモデル全体を、クライアントコンピュータのメモリの中にロードすることである。従って、個々の部品の選択が可能である。しかし、ＰＬＭ／ＣＡＤの分野において、重大な問題は、ビジュアル化データの全体量が大きすぎてメモリ内に入らない、あるいは少なくとも、大きすぎて迅速な表示ができないことである。従って、ＣＡＤ製品を描写するファイルの典型的な大きさ（航空機のような製品は数百万の部品を含むことがよくあり、数ギガオクテットのメモリに相当する）が原因で、前記製品のビューのレンダリング時間は、極端に長い。

従って、複数の部品を備えたＣＡＤ製品の効率的な表示を可能にするような解決法が必要である。できれば、その解決法は、入出力（Ｉ／Ｏ）とメモリ消費とを減らした状態で、膨大な量の３ＤＰＬＭデータ内のナビゲーションを可能にするべきである。

一実施形態において、本発明は従って、ＰＬＭデータベースのオブジェクトを表示する処理を提供するものであって、
−モデル化されたオブジェクトを含むＰＬＭデータベースとグラフィカル・ユーザ・インターフェースとを提供するステップと、
−レンダリングされるべきオブジェクトのビュー上の視点を特定するステップと、
−その視点に従って前記ビューをレンダリングするステップと
を備えており、
前記レンダリングするステップは、
−ビューの中で複数の位置を決定するステップと、
−データベースを検索して、その中のモデル化されたオブジェクトを決定された位置に従って特定するステップと、
−前記ビューをレンダリングするように特定されたモデル化されたオブジェクトを、グラフィカル・ユーザ・インターフェース内に付加的に表示するステップと
を備えることを特徴としている処理。

別の実施形態において、本発明の処理は下記の特徴のうち１つ以上を備えていてもよい。

−本発明による処理がさらに、視点を特定するステップの前に、ユーザによる視点の動的な定義を受け取るステップを備えており、視点のユーザ定義に従って、複数の位置を決定するステップが動的に実行されることを特徴とすること、
−位置は、ビューの中で定義されたグリッドから決定されること、
−複数の位置を決定するステップが、時間と共に前記グリッドを詳細化するステップを備えていること、
−ＰＬＭデータベースがさらに、モデル化されたオブジェクトの表示コンポーネントを備え、レンダリングのステップがさらに、特定されたモデル化されたオブジェクトの表示コンポーネントをストリーミングするステップを備えたことを特徴とし、かつ、レンダリングのステップにおいて、付加的に表示するステップが表示コンポーネントを付加的に表示するステップを備えたことを特徴とすること、
−モデル化されたオブジェクトを特定するステップと付加的に表示するステップとが、時間を基準に交互に実行されること、
−レンダリングするステップがさらに、モデル化されたオブジェクトを特定するステップで特定されたオブジェクトの順位(ranking)を確立するステップを備え、そして、モデル化されたオブジェクトを付加的に表示するステップが前記順位に従って実行されること、
−本発明による処理がさらに、データベースを検索してモデル化されたオブジェクトを特定するステップと並行して、視点に従って前記ビュー内で可視であるモデル化されたオブジェクトのリストをデータベースの中で特定するステップを備え、付加的に表示するステップは、決定された位置に従って特定されたモデル化されたオブジェクトを表示するステップと、モデル化されたオブジェクトの表示をリストに従って完了するステップとを備えていること、
−データベースを検索してモデル化されたオブジェクトを特定するステップがさらに、視点と定義された位置のうちの少なくとも１つを通る線を演算するステップを備えていること、
−検索して特定するステップはさらに、演算された線と交差する、モデル化されたそれぞれのオブジェクトの１つ以上の境界ボリューム(volume)を特定するステップを備えていること、
−本発明による処理はさらに、交差する境界ボリュームに対応するオブジェクトのうちで、視点に最も近いオブジェクトを特定するステップを備えていること、
−本発明による処理はさらに、データベースを検索するステップの前に、モデル化されたそれぞれのオブジェクトの境界ボリュームを演算し、ＰＬＭデータベースの中に格納するステップを備えていること、
−境界ボリュームを演算して格納するステップにおいて、モデル化されたオブジェクトのうちマルチ・インスタンス化されたオブジェクトについて、境界ボリュームが１つだけ格納される、
−１つ以上の交差する境界ボリュームを特定するステップが、データベース内に格納されたそれぞれのオブジェクト間の関係に基づいて再帰的に行われること、
−本発明による処理はさらに、データベースを検索するステップの前に、それぞれの境界ボリュームの再分割された境界ボリュームを演算してＰＬＭデータベースの中に格納するステップを備えていること、
−本発明による処理はさらに、演算された線と交差する１つ以上の再分割された境界ボリュームを特定するステップを備えていること、
−モデル化されたオブジェクトを表示するステップは、前記モデル化されたオブジェクトの３次元描写を表示するステップを備え、前記描写は前記オブジェクトを編集するのにユーザによって選択可能であること。

本発明はさらに、モデル化されたオブジェクトを含むＰＬＭデータベース内のオブジェクトを選択するための装置を提供し、その装置は本発明による処理のステップを実施する手段を備えている。

本発明は、モデル化されたオブジェクトを含むＰＬＭデータベース内のオブジェクトを選択するための、コンピュータ可読媒体上に格納された、コンピュータプログラムに関し、本発明による処理のステップをコンピュータに行わせるコードを備えている。

限定を目的としない例として、添付の図面を参照しながら、本発明を実装するシステムをこれから説明する。

本発明は、ＰＬＭデータベースのオブジェクトを表示する処理を対象としている。モデル化されたオブジェクトとグラフィカル・ユーザ・インターフェースを含むＰＬＭデータベースが提供される。レンダリングされることになるオブジェクトのビュー上の視点が特定される。その後、視点に従ってビューはレンダリングされる。レンダリングのステップは、ビューの中で複数の位置を決定するステップを備えており、それらの位置は例えばグリッドに従って得られる。次に、データベースが検索され、モデル化されたオブジェクトが前記位置に従って特定される。一方、特定されたモデル化されたオブジェクトは、ビュー、できれば３次元のビューをレンダリングするため、グラフィカル・ユーザ・インターフェースにおいて付加的に表示される。

特定されたオブジェクトをすべて一時に表示するステップの代わりに、付加的に表示するステップによって、漸進的、従って、より反応性の良い表示が可能になるり、オブジェクトを大雑把にまたは部分的に表示でき、それらの描写がクライアントのメモリ内に部分的にロードされることもできる。

その上、オブジェクトはビュー内の決定された位置に従って特定されるので、画面の表面上で目立てば目立つほど、最初に決定されることになる可能性が高くなる。従って、最も目立つオブジェクトが最初に表示され、（画面上で見ると）より小さいオブジェクトは遅れて表示される。従って、表示はユーザにより関連するように現れる。加えて有利なことに、完全に隠れているオブジェクトは発見されないので、メモリ内にロードされる必要がない。さらにもっと効率的な表示のために、オブジェクトを特定するステップと付加的な表示とは、場合によっては組み合わせることができる。

提案した解決法によって、ビューの迅速な表示が可能になる。しかし、「個々の」モデル化されたオブジェクトが表示されるので、ビュー内に一度表示されたこのようなオブジェクトを個々に選択することが可能であり、必要ならば、セッション（設計、ナビゲーション、閲覧など）内のそれらの関連データと共に、選択したオブジェクトをロードすることも、例えばマウスをシングルクリックするだけで可能となる。

決定された位置によるオブジェクトの特定に関して、例えばＰＬＭデータベースに格納された境界ボリュームが利用される。これは、ビューの１つだけの特定の位置が考慮されること（それは、データベース内でいわゆる「ピック・クエリ」を実行するということ）を特徴とする一例を介して、図２乃至４を参照しながら説明する。本発明による全体的な処理は、ビュー内で決定される複数の位置に依存するが、それについては図５ａ乃至ｈを参照しながら、より詳しく例証する。

図１を参照して、ユーザ制御のポインタ、例えばマウスを備えたグラフィカル・ユーザ・インターフェースが提供されている。

グラフィカル・ユーザ・インターフェース（またはＧＵＩ）１０は、標準的なメニューバー１１、１２と同様に、下部ツールバー１４およびサイドツールバー１５を有する、典型的なＣＡＤ／ＣＡＭ／ＣＡＥのようなインターフェースであってもよい。そのようなメニューバーとツールバーは、当分野では知られているとおり、ユーザが選択可能なアイコンの組を含み、各アイコンは１つ以上の作用または機能と関連している。

これらのアイコンの一部は、ＧＵＩ１０に表示されたモデル化されたオブジェクト３０を編集および／または作業するのに適応されたソフトウェアツールと関連している。当該ソフトウェアツールは、ワークベンチとしてグループ化されてもよい。別の言い方をすると、各ワークベンチは、ソフトウェアツールの異なるサブセットを備えている。特に、これらのうちの１つは、モデル化されたオブジェクト３０の形体を編集するのに適した、編集ワークベンチである。操作において設計者は、例えばオブジェクト３０の一部を事前に選択し、その後、適切なアイコンを選択することによって操作（例えば、大きさや何らかの属性などを変更する）を初期化してもよい。例えば、典型的なＣＡＤ操作は、スクリーン上に表示された３Ｄモデル化されたオブジェクトの穴抜きや折り曲げのモデリングである。

ＧＵＩは、例えば、表示されたオブジェクト３０に関するデータ２５を表示してもよい。図１の例では、データ２５は、「機能ツリー」として表示されており、それらの３Ｄ描写３０は、ブレーキ・キャリパとディスクとを有するブレーキ・アセンブリに関するものである。ＧＵＩはさらに、例えばオブジェクトの３Ｄ方向付けを用意にするため、編集された製品の操作のシミュレーションをトリガするために、各種のグラフィックツール１３、４０を示してもよいし、表示された製品３０の各種の属性をレンダリングしてもよい。

実施形態の一例として、本発明の処理が、ユーザコンピュータと製品データ管理（ＰＤＭ）システムを備えたコンピュータネットワークに実装される。ユーザコンピュータはＰＤＭシステムを通して通信していて、ユーザコンピュータによって、階層的に相互に関連している可能性のある膨大な文書と関係とデータとの管理が可能となる。ＰＤＭシステムは、例えば、ネットワークのバックボーンに位置していてもよい。このようなＰＤＭシステムが、モデル化されたオブジェクトに関するデータを有するデータベースを利用し、これは設計者によって編集されることがよくある。従って、複数のユーザが協働して、別のオブジェクト（例えば、部品、製品、または部品のアセンブリ）について作業してもよい。

また、ＧＵＩ１０および関連するＣＡＤ／ＣＡＭ／ＣＡＥアプリケーションは、既存のＣＡＤ／ＣＡＭ／ＣＡＥインターフェースとは対照的に、ユーザ要求によって、またはバックグラウンドタスクとしてのいずれかによってＰＬＭデータベースにアクセスできるように設計されてもよい。従って操作において、データベースへのアクセスを望むユーザは、最初のＣＡＤウィンドウからＰＤＭウィンドウに移動し（例えば、最初のウィンドウを最小化して、第２のウィンドウを最大化することによって）、その後、ＣＡＤウィンドウに戻る必要はない。そのようなウィンドウ切り替え操作は設計者によって頻繁に行われるが、それらは時間の浪費で、ＣＡＤ／ＣＡＭ／ＣＡＥの分野では特に不適切である。

ＧＵＩ１０は、ネットワークの１台のユーザコンピュータ上で実行されており、ディスプレイとメモリとを有している。例えば、図１に表示されていて参照番号１０で特定されているものと同様のＧＵＩは、ネットワークの他のユーザのコンピュータ上で実行されてもよい。これらのコンピュータは、同様のローカルなＣＡＤ／ＣＡＭ／ＣＡＥアプリケーションから、さらにはもっと一般的に、共通の環境にから、さらなる利益を得てもよい。

次に図２を参照して、処理は、ビルドタイム（ステップ１００）とランタイム（ステップ１３０から１６０まで）とに大きく分かれる。ビルドタイムは、境界ボリュームの演算と、場合によってはオブジェクトのインデックスの作成とに特化した事前処理ステップ１００を特に含んでもよい。

「境界ボリューム」、すなわち、境界ボックスによって、例えば、カル(culling)または交差のテストのための、オブジェクトを取り囲む何らかの数学的に単純な表面を意味している。典型的な境界ボリュームは、例えば、立方体、円筒、あるいは球である。下記において、境界ボックスが利用される。

表示されることになるそれぞれのオブジェクトの境界ボックスは、演算され、続いてＰＬＭデータベース内に格納される。そのような境界ボックスは、それらの対応するオブジェクトとの関係と共に格納される。前記ボックスを演算するのに、オブジェクトの幾何学的定義を使用することができる。使用される定義は、完全な定義または前記オブジェクトのテセレーション描写の定義のような単純化された定義であってもよい。

より速い演算時間を提供するテセレーション描写の定義を使用するのが望ましい。

製品をオブジェクトの階層、例えばツリーとして考えると、例えば最初に、ツリーの終端ノードに関連する最初に演算されるボックスである。その後、構造の定義と終端ボックスとがすでに生成されているために、製品構造の定義を使用してアセンブリのボックスを演算する（ステップ１００）。

さらに、再分割されたボックスが演算され、それぞれの親である境界ボックスと一緒にデータベース内に格納される。親の境界ボックスは、この場合、オクトリの親ノードであり、すなわち、各親ノードが８個の子コードを有し、それらが一緒になって親ノードの空間のボリュームをパーティションで区切る、ツリーデータ構造である。従って、ツリーの各ノードは、立方形ボリューム、例えば再分割された境界ボリュームを表している。所望の解像度によって、（親、子、孫など）いくつかの再分割が考えられる。

さらに、オブジェクトの組のうちのマルチ・インスタンス化されたオブジェクトについて、できれば境界ボックスが１つだけ格納されることが望ましい。すなわち、境界ボックスは、参照目的に限って演算される。この場合、同じ参照先のインスタンスは、位置マトリックス（またはそれへのリンク）と一緒に格納される可能性が高い。従って、作業における単純な直交システムの変更で、マルチ・インスタンス化されたオブジェクトのいずれに対しても、ボックスがすばやく結び付けられる。

オブジェクトの特定に関して、処理は、ビュー内で複数の位置を決定するステップを備えている。前記位置は、あとで詳述するように、例えばビュー内で定義されたグリッドで決定されてもよい。以下で、本発明の処理について、ビュー内で決定された１つの位置を使用して、まず説明する。

まず、ステップ１３０において、ビュー内で位置、すなわち、画面の中の特定のｘとｙの位置が決定される。そのステップ１３０を実行するため、何らかの既知の便利な方法が使用されてよい。

次に、ステップ１４０−１６０において、システムは、決定された位置に従ってデータベースを検索し、ユーザに対して１つのオブジェクトを特定するステップへ進む。そのようなステップについて、図２の処理の一部の特定の本発明の実施形態に従って、ここから詳細に説明する。

第１に、ステップ１４０において、ビューの視点と、画面内の決定された(ｘ,ｙ)の位置とを通る線または幾何学的な同等物が演算される。ここで、視点は、３Ｄのコンテキストにおいて、描写に使用されるパースペクティブの選択に依存する。当技術分野で知られているような消失点またはカメラ位置の点でもよく、それ以外のどのようなパースペクティブでもよい。

次に、ステップ１５０において、演算された線と交差する、オブジェクトの組のそれぞれのオブジェクトの１つ以上の境界ボックスが特定される。この目的で、交差が存在するのか否かを判断するために複数の既知の技術が使用されてもよい。例えば、視点と画面上で最初に決定された位置とを利用して、線が境界ボックスと交差するか否かを決定してもよい。

強引な方法では、アルゴリズムは例えば、どのボックスが前記演算された線と交差するのか判断するために、参照ビューの各子インスタンスに対応する境界ボックスをすべてスキャンしてもよい。このステップは、参照ビューの座標系において実行される。

しかし、上記のスキャンするステップは、オブジェクトの数が増加するにつれて急速に困難になる。例えば、現代の航空機のＣＡＤ／ＣＡＭモデリングは、最大３百万ボックスを格納する必要がある場合がある。従って、交差の調査アルゴリズムを加速する方が有利であることが分かる。

この点で、例えば、いわゆるＲ−ツリー技法、すなわち、空間が階層的に入れ子になった、オーバラップする可能性もあるボックスに分割されることを特徴とする空間アクセス法を使用してもよい。そのような技法は、各種の可能な基準に従ったもっとバランスのとれたツリーにつながり、より効率的なスキャンにつながる。

次に、いったん参照ビューの子インスタンスとの交差が見つかると、前記交差した子インスタンスの座標系において当初の線が再演算され、それ以上交差が見つからなくなるまで、新たなスキャンがその子インスタンス内部で実行される。

交差調査アルゴリズムは、このように再帰的であり（ステップ１５０−１６０）、すなわち、ｎ次の交差した親ボックスのうち最後に交差した子を検索し、以下のように行う。

いったん、交差する境界ボックスが検知されると、一実施形態の処理は、交差した境界ボックス内のより小さい再分割レベルで動作する。例えば、図３ａに示すように８個の立方体のボックスに分割されたボリュームであるオクトリを考えてもよい。

オクトリ３１０がモデルの要素をまったく有していないか、またはモデルの要素で完全に満たされている場合を除き、オクトリ３００自体は、例えば図３ｂ（分りやすくするため、２次元で描写されている）に示すように、さらに再分割される。モデルの要素を含む各オクトリ３００は、さらに再分割される。

従って、オクトリ３００は、演算された線との何らかの交差を検知するために、ボクセル３２０として知られる（たとえば、そのサイズはユーザによる定義入力に依存することがある）、最小の分割されないボリュームまでスキャンされる。この処理は、その後停止し、特定されたボクセル内（またはそれに近い）ビュー内のオブジェクトが選択される。

いったんオブジェクトが選択されると、対応するボクセルの視点への距離が格納される。その後、処理は、同じステップ（境界ボックス、オクトリ、ボクセル）に従って、他の境界ボックス（ステップ１５０−１６０）を再帰的にテストし、線に沿った視点に最も近いであろうオブジェクトを見つけて選択する。処理を最適化するために、もしもある境界ボックスが演算された線（新たな座標系において）と交差しないならば、この境界ボックスは廃棄される。同様に、もしもある境界ボックスが線と交差するが、一方でその境界ボックスと視点との距離が以前に格納された距離より大きいならば、前記境界ボックスはそれ以上テストされない。

いったんすべての境界ボックスがテストされ、データベースの中でオブジェクトが特定されると、前記オブジェクトの描写がデータベースからロードされ、表示されてもよい。前記描写は、単純化された描写、または例えば、正確なテセレートされた描写あるいはＮＵＲＢＳ描写のような正確な描写であってもよい。ローディングおよび続く表示インターフェースについては、後でさらに説明する。

前記選択されたオブジェクトは例えば、実属性（色、テクスチャ、材料）を使用して表示されてもよい。さらに、他の取り出された情報、例えば名前、所有者、または何らかのその他の属性が、特定された部分の近くまたは機能ツリー（図１を参照）の中に表示されてもよい。

上記アルゴリズムの一実施形態について、図１にあるのと同じグラフィカル・ユーザ・インターフェースに表示されることになるモデル化されたオブジェクトを示しながら、図４を参照して、これから説明する。境界ボックスは、見やすくするための指針とすることだけを目的として、図４では点線で描かれていることに留意されたい。

ここでＧＵＩ１０は、図１を参照してすでに説明したのと同様のメニューバーとツールバーを有している。ＧＵＩ１０には、レンダリングされることになるオブジェクト２１−２４のビューが表されている。しかし、処理の冒頭では、どのオブジェクトも実際にまだ表示されてはいないことに留意されたい。前記ビューは、ボード２１、前（ｆ）と後ろ（ｒ）の台車２２ｆと２２ｒとで構成されるスケートボード２１を示している。台車は、それぞれの軸２３ｆと２３ｒと、そして、左（ｌ）と右（ｒ）の車輪２４ｌｆ、２４ｒｆ、２４ｌｒ、２４ｒｒ（「ｌｆ」は左前、「ｒｆ」は右前のこと、以下同様）を備えている。それぞれの境界ボックス（ｂ）は、同様の参照記号、２１ｂ、２２ｆｂ、２２ｒｂ、２３ｆｂ、２３ｒｂ、２４ｌｆｂ、２４ｒｆｂ、２４ｌｒｂ、２４ｒｒｂで描かれている。特に、一部のボックスは、終端ノード、例えば車輪、軸、およびボードに対応しており、他方で他のボックスは部品の一部のアセンブリ（例えば台車）に対応している。前記ボックスは、上述のとおり、できればビルドタイム処理の間に、製品構造の定義に従って演算される。

操作において、グリッドは定義され、特に参照ポイント３２を含み、その位置はグリッドの定義から決定される。前記ポイント３２は、この例では、好運にも、スケートボードの左前車輪２４ｌｆに対応する位置に画面の中で位置している。

その後、方法に従って、データベース内のクエリがトリガされる。視点とポインタ３２の位置とを通過する線が上述のように演算される。その後、スケートボードを形成する組２０の子インスタンスがすべてスキャンされる。この例では、（前の台車２２ｆに対応する）ボックス２２ｆｂとの交差が発見されるため、ルーチンは続行され、ボックス２２ｆのシステム座標に切り替わる。交差されなかったボックスは廃棄される。

次に、「で構成される」という関係により、前記線がボックス２３ｆｂ、２４ｒｆｂ、および２４ｌｆｂのいずれかと交差するか否かがテストされる。ボックス２３ｆｂおよび２４ｌｆｂ、すなわち前軸に対応する、例えば参照「軸」のインスタンス、左車輪に対応する、例えば参照「車輪」のインスタンスとの交差が見つけられる。交差するインスタンスを構成するインスタンスがそれ以上発見されないため、その後、階層型の降下は止まる。次に、ルーチンは、それぞれの距離を視点と比較し、正確性の基準が満たされることを条件として、表示されることになる部品として最後に車輪２４ｌｆを戻す。本発明に従って、システムはその後、前記部品の描写と、場合によっては選択された部品に関連する一部またはすべてのデータとをデータベースから取り出す。

データベース内に格納された製品構造の定義が原因で、クエリの結果は、発生すなわちインスタンス・パスであることに留意されたい。この観点で、前の例では、クエリの結果は単に左前の車輪２４ｌｆなのではなく、むしろ参照「台車」の「前の台車」インスタンス内の、参照「車輪」の「左車輪」インスタンスなのである。

一実施形態において、特定された部分のさらなる選択（例えば、クリックするだけで）によって、編集ウィンドウが開き、選択された部分が、すぐに編集できる状態でその中にレンダリングされていることに留意されたい。

別の実施形態では、すでに開いている編集ウィンドウ内に選択された部分を追加するために「ａｄｄ（追加）」コマンドを実行するステップ、あるいは、選択された部分をビューイング・セッションのようなものに追加するステップを考えてもよい。

従って、図２に関して説明した処理は、事前選択による方法だとみなすことができ、オブジェクトの最終的な選択は、特定されたオブジェクトを指すポインタの起動の上で、初めて実行される。

図４の例は、理解する上で、明らかに非常に単純である。しかし、図２のフローチャートに戻って参照すると、複数の境界ボックスが見つかる場合、明確に区別するため、追加のスキームが実装されてもよいかもしれない。特に、もし複数のボクセルが線と交差することが分ったならば、視点に最も近いボクセルが、選択等されることになるボクセルとして特定されるであろう。

従って、この処理によって、例えば、場合によっては編集される準備のできた部品などのオブジェクトをデータベースから読み出すことが可能になる。必要なのは、ポイントの位置と部品との間の対応のみであり、従って部品は迅速に取り出されてもよい。結果として、部品は表示用にロードされてもよい。そのようなやり方はさらに高い拡張が可能であるので、手軽な装置（パソコン）上での３Ｄナビゲーションにおける３Ｄデータへのアクセスが可能になる。

ある実施形態において、視点が変更されるたびにデータベース内で新規のクエリがトリガされる。

処理の基礎を成すステップについて、ビュー内で決定される単一の位置に関して上記で説明してきた。ここで、複数の位置が使用されることを特徴とする、ランタイムで発生するステップを図示する図５ａ−ｈを参照しながら説明する。

上述のとおり、処理はビルドタイムとランタイムとに分かれてもよい。図４を参照して、典型的には、処理の効率性のため、ビルドタイムの間に製品のインデックスが構築され（そしてオブジェクト間の関係を形成し）、境界ボックスが格納される。より高速な３Ｄ検索を可能にするため、一部のＰＬＭデータの複製が用いられてもよい。前複製は、できれば格納されたＰＬＭモデルと同一構造であることが望ましい。

一つの変形において、ランタイムにフィルタ処理が実行できるように、データベース内に格納された製品構成毎に１つのインデックスを生成する必要はないことに留意されたい。

図５ａ−ｈは、ランタイムをより詳しく図示している。

図５ａを参照し。以降の説明のために、レンダリングすることになるオブジェクトのビュー１１０が描かれている。このオブジェクトはまだ表示されていない。ＧＵＩの詳細は、明確にするため省略する。オブジェクトの組および諸オブジェクトは図４に関して説明した組２０およびオブジェクト２１−２４に対応している。このオブジェクトはさらに、それぞれの境界ボックスと共に描かれている。参照についても、明確にするため省略する。図５ａはステップＳ２００を図示し、そこにはレンダリングされることになるビュー上の視点が特定されている。視点はユーザによって動的に定義されうる（すなわち、リアルタイムで修正される）。バーチャルカメラは、従って、可能となる。

次に、ステップ２１０において、図５ｂを参照して、複数の位置３２ａ−iがビュー内で決定される。上述のように、前記位置はグリッドから決定でき、グリッド自体もビュー内で定義される。従って、グリッドを使用するときに、この処理を以後、グリッドスキャン処理と呼ぶ。さらに、位置を決定するステップは、場合によると視点の動的な定義に従って動的に実行できる。

現行の視点から、眼と例えばグリッドに対応する画面ピクセルの組との間の線のリストが演算される。前記線はその後、上述のステップに従って処理される。当業者の用語を使用して、ピック・クエリのループがこのようにして実行される。

図５ｂで可視であるグリッドから、データベースを検索することによって、一部のポイントの位置が対応する境界ボックスと出会う際にボード（図４の参照２１）に付属していると結論付けることが可能になる。これらはポイント３２ａ、３２ｄ、３２ｅ、３２ｈ、３２ｉである（従って合計５個となる）。別のポイント３２ｂは、左前車輪に付属するし（図４の参照２３ｌｆを参照のこと）。従って、最初のスキャンが完了すると、関連する部品が特定されて、それらのリストが例えばデータベースにリンクされているＰＬＭサーバから戻される。

図５ｃ−ｄを参照して、次に表示ルーチンが開始される。モデル化されたオブジェクトは付加的に表示され、それによってビューの迅速な表示が可能となる。さらに、上述のように、オブジェクトが大きければ大きいほど、それがグリッドのポイントと出会う可能性が高い。従って、もっとも目立つオブジェクトが最初に表示される。この例では、当然ボードが特定され、続いて表示される。

しかし、前左車輪も特定され、現行の視点では実際にはそれがもっとも目立つオブジェクトである。従って、グリッドスキャン処理は、場合によると、例えば、
−ボード：５カウント
−左前車輪：１カウント、
というように、特定されたオブジェクトの順位を確立するステップによって向上することがある。

末端の葉の部分に関する統計値だけが使用される。しかし、一つの変形において、場合によると親ノードに関する統計値が考慮されてもよく、例えば、前左車輪は前台車の子であり、前台車にもカウントを１つ与えてもよい。

従って、できれば、前記オブジェクトを表示する順序は、もっとも目立つオブジェクト、例えばボードが実際に最初に表示されることを確実にするように、上記の順位に従って演算されるのが好ましい。

一実施形態において、ＰＬＭデータベースはさらに、モデル化されたオブジェクトの表示コンポーネントを格納する。レンダリングするステップは、従って、特定されたモデル化されたオブジェクトのストリーミング表示コンポーネントを備えていてもよい。従って、表示コンポーネントは、付加的に表示されることになろう（Ｓ２２０−Ｓ２３０）。ストリーミングコンポーネントは、バックグラウンドで実行できる。

前記表示コンポーネントは、図５ｃ乃至５ｄに図示されたように、同じ部品の異なるコンポーネント（異なる面のように）で構成されてもよい。図５ｃにおいて、ボードの上面２１ｕｆが最初に表示される。図５ｄにおいて、側面２１ｓｆが続いて表示される。

できれば問題のコンポーネントは、例えばボクセル、それから低解像度の三角形、最後に正確な三角形となるように、サブコンポーネントが次第に正確になるシーケンスとして付加的にロードされることがのぞましい。これによって、Ｉ／Ｏ利用を減らすことができる。

一つの変形において、オブジェクトを付加的に表示するステップとオブジェクトコンポーネントを付加的にストリーミング／表示するステップとが組み合わされ、レンダリング時間を向上させる。例えば、所与の数のオブジェクトが第１のスキャンの間に特定される。オブジェクトを表示するステップは、ボクセル、次に三角形を表示することによって始まる。第２のスキャンの間、他のオブジェクトが特定され、その間にバックグラウンドにおいては前のコンポーネントをストリーミングすることが続く。

さらに、現行の視点によっては、何らかの適応型ローディングを使用してもよい。さらに、カル技法（視点カル、閉鎖カル、ピクセルカル、等々）を利用してもよい。さらに、視点が変わるときには、ピークのメモリ使用を制現するために、追加のローディングあるいはアンロードを実行することができる。

図５ｅ乃至ｆでは、左前車輪２４ｌｆが、例えばコンポーネントの付加的なストリーミングに従って現在表示されている（この例では、左前車輪２４ｌｆの外側、そしてその後側面コンポーネントが順次表示される）。

図５ｇ乃至ｈでは、複数の位置を決定するステップが、場合によっては時間と共に初期のグリッドを絞り込むステップ（Ｓ２５０−Ｓ２６０）を備えていてもよい。従って、新規のグリッドが演算され、新規の線クエリが実行され（従って新規スキャン）、そして、新規のカウント統計値が戻され、その結果、（例えば、スケートの後右車輪２４ｒｒのような）以前にアンロードされた部品が表示される。

加えて、画面エリアのローカルな統計値によって、可変のグリッド解像度が使用されてもよい。これは、画面スキャンの収束の向上に役立つことができる。

またできれば、モデル化されたオブジェクト（例えばスキャン／線クエリ）を特定するステップと付加的に表示するステップ（例えば３Ｄ表示）は、時間的に交互に実行されることが望ましい。例えば、線は３００ｍｓの間に（グリッドの絞込みも含めて）演算され、累積結果が送り返される。時間の基準は、場合によっては視点の変化の「速度」に応じた拡張性があってもよい。これによって、現行の視点と部品の特定とを一致させることが可能になる。

グリッドの解像度は、従って、連続して絞り込まれてもよい。従って、複数回の画面スキャンが実行され、テストされたピクセルのグリッドが構築され、それが時間と共に絞り込まれる。第１のスキャンは、もっとも目立つオブジェクトをすばやく発見する。

テストされるピクセルの数は、一般にグリッドの解像度の二乗の割合で増加する。従って、上述の処理によって迅速な表示が可能となる反面、収束は結果的に遅くなる。さらに、画面上で最終的なグリッド解像度よりも小さい一部のオブジェクトは戻されないこともありうる。

これは図６に図示されており、各種の方法で得得される表示の完了を時間の関数として比較する。示されるように、上述のグリッドスキャン処理（実線）は、一部のより小さい部品を廃棄することがあり（有限の解像度を使う場合に一層である）、グリッドスキャンの最後に、すべての部品が表示されるわけではない。対照的に、当技術分野で知られた処理（点線および破線）は、ゆっくりしたスタートを示す傾向にあるが、最終的には完了リストの取り出しが可能となる。

従って、図６を参照して、上記のグリッドスキャンは、表示を開始するのに時間がよりかかるが最終にはオブジェクトの完全リストを戻す１つ以上の他のクエリと並行して実行されてもよく、必要ならば、ビューの中の可視オブジェクトだけに限定されてもよい。

特に、上記の処理は、データベース内でモデル化されたオブジェクトの（並行処理）リストを特定する（並行処理）ステップを含んでもよい。いったん特定されると、オブジェクトの視覚化データはロードされ、都合よく格納され、表示を待つことができる。

さらに、付加的な表示は、従って、２つの補完的な表示サブステップに分かれているであろう。第１のサブステップにおいて、処理は、決定された位置に従って、すなわち、上述のグリッドスキャン処理に従って、特定されたモデル化されたオブジェクトを表示する。第２のサブステップにおいて、モデル化されたオブジェクトの表示は、戻された並行処理リストに従って完了される。従って、収束を向上させた状態で可視のオブジェクトをすべて最終的に表示することが可能である。第２のサブステップに関連する処理が完了するとき、第１のサブステップに関連する処理は、並行処理リストが完了されるので、停止できることに留意されたい。

第２のサブステップは例えば、（すでに呼び出されているように、）画面スキャンの収束を向上させるために、画面エリアのローカルな統計値に依存して、単純にグリッド解像度を使用するステップで構成されてもよい。

第２のサブステップはまた、「視点クエリ」（例えばすべての可視オブジェクトが、閉鎖付きのまたは閉鎖付きで、並行処理リスト内で特定される）または「すべてを展開する」タイプのクエリ（すべてのオブジェクトの強引なリストが戻される）で構成されてもよい。このような方法によって、例えば、すべての画面ピクセルをテストしなくても、表示の完了が可能となってもよい。

視点クエリに関して、（隠されている場合であっても）視点におけるオブジェクトのすべてのリストを演算する任意の既知の方法が予期できる。リストは、場合によると、可視オブジェクトだけに限定されてもよい。これによって、最小限の入出力（Ｉ／Ｏ）とメモリ利用で、表示の完了が可能となる。

図６で分かるように、既知の方法（点／破線）は、グリッドスキャン処理と比較してよりゆっくりとしたスタートを有する。しかし、ある通過点において、既知の方法のうちの一つに切り替えることによって、収束率を向上させ、必要ならば、表示を完了させることが可能となる。

本発明は、図面を参照しながら上記で説明した好適な実施形態に限定されない。特に、ＧＵＩ内のビューをレンダリングするとき、複合的な描写が考えられてもよい。前記ビューは、例えば、オブジェクトの特定の組に関して部分的に非結合であってもよい。これは特に部品のアセンブリに適用でき、これによってより高速なローディングが可能となる。対照的に、他のオブジェクトはそれぞれの属性と共にビュー内にロードでき、これによってこれを直接選択できるようになる。これは、ビルドタイムにおける製品の特定のインデックス化が必要となるであろう。例えば、一部のオブジェクトの描写は、データベースへのハイパーリンクの組を備えていてもよい。従って、ハイパーリンクに対応する適切な範囲をクリックすることによって、それぞれの部品を直接選択することが可能となる。

ＣＡＤに似たグラフィカル・ユーザ・インターフェースの例示的な表示である。 本発明の処理の基礎をなすステップを反映したフローチャートを示す。 本発明の一実施形態による処理の中で使用されるオクトリである。 本発明の一実施形態による処理の中で使用されるオクトリである。 本発明の一実施形態によって特定することができる、図１のグラフィカル・ユーザ・インターフェースに表示されるオブジェクトの組のビューを示す。 本発明の一実施形態による、ＰＬＭデータベースのオブジェクトを表示する処理のステップを反映する一連のビューである。 本発明の一実施形態による、ＰＬＭデータベースのオブジェクトを表示する処理のステップを反映する一連によるビューである。 本発明の一実施形態による、ＰＬＭデータベースのオブジェクトを表示する処理のステップを反映する一連によるビューである。 本発明の一実施形態による、ＰＬＭデータベースのオブジェクトを表示する処理のステップを反映する一連のビューである。 本発明の一実施形態による、ＰＬＭデータベースのオブジェクトを表示する処理のステップを反映する一連のビューである。 本発明の一実施形態による、ＰＬＭデータベースのオブジェクトを表示する処理のステップを反映する一連のビューである。 本発明の一実施形態による、ＰＬＭデータベースのオブジェクトを表示する処理のステップを反映する一連のビューである。 本発明の一実施形態による、ＰＬＭデータベースのオブジェクトを表示する処理のステップを反映する一連のビューである。 本発明の一実施形態による処理で平行して実施されうる各種の方法で取得された表示の完了についての比較である。

符号の説明

２１ スケートボード
２２ｆ、２２ｒ 台車
２３ｆ、２３ｒ 軸
２４ｌｆ、２４ｒｆ、２４ｌｒ、２４ｒｒ 車輪
２５ 機能ツリー
４０ コンパス
３００ オクトリ
３２０ ボクセル
５００ ボリューム

Claims (19)

1. ＰＬＭデータベースのオブジェクトを表示するための処理方法であって、
   −モデル化されたオブジェクトを含むＰＬＭデータベースとグラフィカル・ユーザ・インターフェースを提供するステップ（１００）と、
   −レンダリングされることになるオブジェクト（２１−２４）のビュー（１１０）上に視点を特定するステップ（Ｓ２００）と、
   −前記視点に従って前記ビューをレンダリングするステップ（Ｓ２１０−２７０）と
   を備えており、
   前記レンダリングするステップが、
   −前記ビューの中で複数の位置（３２ａ−ｉ）を決定するステップ（Ｓ２１０）と、
   −前記データベースを検索して、その中のモデル化されたオブジェクト（２１−２４）を前記決定された位置に従って特定するステップと、
   −前記ビュー（１１０）をレンダリングするために、特定された前記モデル化されたオブジェクト（２１−２４）を前記グラフィカル・ユーザ・インターフェース内に付加的に表示するステップ（Ｓ２２０−Ｓ２７０）と
   備えたことを特徴とする処理方法。
2. 前記視点を特定する前記ステップの前に、
   −ユーザによる前記視点の動的な定義を受け取るステップであって、
   前記視点の前記ユーザ定義に従って、前記複数の位置を決定する前記ステップが動的に実行されるステップ
   をさらに備えたことを特徴とする請求項１に記載の処理方法。
3. 前記位置が、前記ビューの中で定義されたグリッド（３２ａ−ｉ）から決定されることを特徴とする請求項１または２に記載の処理方法。
4. 前記複数の位置を決定する前記ステップが、時間と共に前記グリッドを絞り込むステップ（Ｓ２５０−Ｓ２６０）を備えたことを特徴とする請求項３に記載の処理方法。
5. −前記ＰＬＭデータベースがさらに、前記モデル化されたオブジェクト（２１−２４）の表示コンポーネント（２１ｕｆ、２１ｓｆ）を備え、
   前記レンダリングするステップがさらに、
   −特定された前記モデル化されたオブジェクトの表示コンポーネントをストリーミングするステップ（Ｓ２２０−Ｓ２３０、Ｓ２４０−Ｓ２５０）を備え、
   前記レンダリングのステップにおいて、前記付加的に表示するステップが、
   −前記表示コンポーネント（２１ｕｆ、２１ｓｆ）を付加的に表示するステップ（Ｓ２２０−Ｓ２３０）
   を備えたことを特徴とする請求項１乃至４のいずれかに記載の処理方法。
6. モデル化されたオブジェクトを特定する前記ステップと付加的に表示する前記ステップとは、時間的に交互に実行されることを特徴とする請求項１乃至５のいずれかに記載の処理方法。
7. レンダリングする前記ステップが、
   −モデル化されたオブジェクトを特定する前記ステップで特定されたオブジェクト（２１−２４）の順位を確立するステップをさらに備え、
   −前記モデル化されたオブジェクトを付加的に表示する前記ステップが前記順位に従って実行されることを特徴とする請求項１乃至６のいずれかに記載の処理方法。
8. 前記データベースを検索してモデル化されたオブジェクトを特定する前記ステップと並行して、
   −前記視点に従って前記ビュー内で可視であるモデル化されたオブジェクト（２１−２４）のリストを前記データベース内で特定するステップ
   をさらに備え、
   付加的に表示する前記ステップが
   −前記決定された位置に従って特定された前記モデル化されたオブジェクトを表示するステップと、
   −前記モデル化されたオブジェクトの前記表示をリストに従って完了するステップと
   を備えたことを特徴とする請求項１乃至７のいずれか１項に記載の処理方法。
9. 前記データベースを検索してモデル化されたオブジェクトを特定する前記ステップが、
   −前記視点と定義された前記位置（３２ａ−ｉ）のうちの少なくとも１つとを通る線を演算するステップ
   をさらに備えたことを特徴とする請求項１乃至８のいずれか１項に記載の処理方法。
10. 検索して特定する前記ステップが、
    −前記演算された線と交差する、モデル化されたそれぞれのオブジェクト（２１、２２、２３、２４）の１以上の境界ボリューム（２１ｂ、２２ｂ、２３ｂ、２４ｂ）を特定するステップ
    をさらに備えたことを特徴とする請求項９に記載の処理方法。
11. −交差する境界ボリュームに対応する前記オブジェクトのうちで、前記視点に最も近い前記オブジェクトを特定するステップ
    をさらに備えたことを特徴とする請求項１０に記載の処理方法。
12. 前記データベースを検索する前記ステップの前に、
    −モデル化されたそれぞれオブジェクトの境界ボリュームを演算して前記ＰＬＭデータベースの中に格納するステップ
    をさらに備えたことを特徴とする請求項１０または１１に記載の処理方法。
13. 境界ボリュームを演算して格納する前記ステップにおいて、前記モデル化されたオブジェクトのうちマルチ・インスタンス化されたオブジェクトについて、境界ボリュームが１つだけ格納されることを特徴とする請求項１２に記載の処理方法。
14. １つ以上の交差する境界ボリュームを特定する前記ステップが、それぞれのオブジェクト間の前記データベース内に格納された関係に基づいて、再帰的に実行されることを特徴とする請求項１０乃至１３のいずれか１項に記載の処理方法。
15. 前記データベースを検索する前記ステップの前に、
    −それぞれの境界ボリュームのうちの再分割された境界ボリュームを演算して前記ＰＬＭデータベースの中に格納するステップ
    をさらに備えたことを特徴とする請求項１０乃至１４のいずれか１項に記載の処理方法。
16. −前記演算された線と交差する１つ以上の再分割された境界ボリュームを特定するステップ
    をさらに備えたことを特徴とする請求項１５に記載の処理方法。
17. 前記モデル化されたオブジェクトを表示する前記ステップは、前記モデル化されたオブジェクトの３次元描写を表示するステップを備え、前記描写は前記オブジェクトを編集するためにユーザによって選択可能であることを特徴とする請求項１乃至１６のいずれか１項に記載の処理方法。
18. モデル化されたオブジェクトを含むＰＬＭデータベース内の１つのオブジェクトを選択する装置であって、請求項1乃至１７のいずれかの処理方法のステップを実施するための手段を備えている装置。
19. モデル化されたオブジェクトを含むＰＬＭデータベース内のオブジェクトを選択するために、コンピュータ可読媒体上に格納された、コンピュータプログラムであって、コンピュータが、請求項1乃至１７のいずれか1項に記載の処理方法のステップを行えるようにするコードを備えたコンピュータプログラム。

Images