コンフィギュレータの処理及びシステム
【課題】２次元画像において複数のオプション、付属品、色などを用いて構成される製品の複数のマルチアングル画像を生成し、見る及び相互作用するために特別なソフトウェア又はハードウェアを要求しないコンフィギュレータ。
【解決手段】コンフィギュレータは、製品がどのように組み立てられるかに関するレイヤ論理を自動的に生成する。本発明は、リンク及び論理を複数のレイヤの生成フェーズに移動し、それによって、簡単なプログラムによって利用されて、視覚的なインタフェースのために複数のレイヤを組み立てることができる構成論理ファイルをレンダリングにおいて自動的に生成する。複数の２次元画像が複数の３次元モデルから階層化方法を用いて生成される。階層化方法は、それぞれの組み合わせのために完全な製品の画像をレンダリングする必要性を防止する。最適化は、必要な組み合わせの数を減少させる。画像及び論理は、手動の関与なしに更新される。
【解決手段】コンフィギュレータは、製品がどのように組み立てられるかに関するレイヤ論理を自動的に生成する。本発明は、リンク及び論理を複数のレイヤの生成フェーズに移動し、それによって、簡単なプログラムによって利用されて、視覚的なインタフェースのために複数のレイヤを組み立てることができる構成論理ファイルをレンダリングにおいて自動的に生成する。複数の２次元画像が複数の３次元モデルから階層化方法を用いて生成される。階層化方法は、それぞれの組み合わせのために完全な製品の画像をレンダリングする必要性を防止する。最適化は、必要な組み合わせの数を減少させる。画像及び論理は、手動の関与なしに更新される。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、製品、及び製品の複数の構成要素及び付属品を自動的に構成することができるコンフィギュレータに関する。さらに具体的には、コンフィギュレータ及び処理は、より大きな処理の一部として、製品のビューを示すために複数の２次元画像（２ｄ画像）を階層化すること及び使用することを含む。
【背景技術】
【０００２】
コンフィギュレータは、複数の独特な製品要求を必要なドキュメント及び情報に自動的に変換して、要求された製品の複数の構成を表示する。ウェブベースの及びコンピュータベースの製品コンフィギュレータソフトウェアアプリケーションは、ユーザの及び／又は製造業者の要求を満たすオプションの製品構成、価格決定、注文、及び販売を自動化する能力をユーザに提供する。具体的には、ウェブベースの製品コンフィギュレータは、製造業者の顧客の独特な要求を満たすように高度に構成可能な又は定期的にカスタマイズされる自動車などの製品を製造する製造会社のために設計されてもよい。製品のセットアップは、複数のビューにおいてさまざまな機能、及びオプションとともに表示される。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
製品コンフィギュレータをウェブ上で実行することは困難である可能性があるが、これらは製品を販売するときに非常に効果的である可能性がある。課題は、依然として高品質な画像を提供し、できるだけ多くの聴衆に届ける一方で、できるだけ多くの角度から（しばしば数十万種類の可能な構成が存在する。）それぞれの製品構成がどのように見えるかをユーザに見せることを含む。従来は、２ｄ画像ベースのコンフィギュレータ、及びリアルタイムの３次元（３ｄ）ベースのコンフィギュレータの中から選択しなければならなかった。
【０００４】
技術的には、製品コンフィギュレータは、正確な複数の製品画像を生成する３ｄ技術を用いて複数の画像を生成する。いくつかの視点からのビューを示す複数の製品画像は、異なる複数の構成及びビューにおいて、製品を簡単に見る能力をユーザに与えることによって生成されてもよい。典型的に、画像は、製品の正確な複製を示すべき多数の構成可能な置換を有する製品を持つ製造業者によって使用される。リアルタイムの３ｄレンダリングは、本明細書で開示される多くの表示機能を異なる方法で実行することができるが、コンフィギュレータの到達可能な聴衆を制限する特別なソフトウェア、及びハードウェアを要求することもある。
【０００５】
３次元（３ｄ）コンフィギュレータはしばしば、任意の及びすべての視点からの製品、及びさらに可能なすべての構成を表示する能力を提供するが、画像の品質は、ユーザのハードウェアの制限のために制限される可能性がある。さらに、３ｄコンフィギュレータは、ほとんどの場合、ユーザに３ｄビューイングソフトウェアをダウンロードしてインストールするように要求し、これはセキュリティ上の危険、時間的な妨害、又はユーザ及びユーザのコンピュータに対する技術的な障壁をもたらす可能性がある。また、コンフィギュレータの３ｄ性能はしばしば、特化したグラフィックスのハードウェアに依存する。リアルタイムの対話式のコンピュータグラフィックスの場合では、ユーザは通常、コンピュータのスクリーン上に表示されるものを制御している。典型的に、ユーザは、入力デバイスを使用して、フィードバックをシステムに提供し、ビデオゲームなどの３ｄリアルタイムはしばしば、グラフィックス処理ユニットなどの特別なソフトウェア又はハードウェアを要求する。これらの理由で、リアルタイム３ｄコンフィギュレータはしばしば、到達可能な聴衆が少なく、これが多くの会社がこれらを回避する製品構成を探す理由である。
【０００６】
２ｄコンフィギュレータは、複数の高品質な画像（写真、又は高品質なコンピュータで生成された画像（ＣＧＩ））を用いて製品を見せるが、コスト及び複雑性に起因して、視点の数、及びしばしば構成の数によって厳しく制限される。画像が写真の場合、すべてのパーツ及び色の物理的なバリエーションを入手することは、しばしば実現不可能であるので、複数の製品のすべての構成を示すことは極めて困難である。コンピュータで生成された資産は、それぞれに対して複数の独特な画像を用いて、すべての可能な構成を生成することができるが、それぞれの及びあらゆる個別の構成のために膨大な数の画像を生成する。しかしながら、２ｄコンフィギュレータは、しばしば基本的なウェブブラウザの能力以外は使用しないので、非常に大きい潜在的なビューア基盤を有する。
【０００７】
２．５ｄコンフィギュレータは、もう１つのオプションになる。これらのコンフィギュレータは、２ｄ画像のフレームスタックを用いて車両の周りの単一の３ｄカメラの動き（camera movement）をシミュレートすることによって、２ｄと３ｄとの間の妥協を作ろうと試みる。このアプローチは、従来の２ｄコンフィギュレータよりも高品質な画像、及びより多くの視点を可能にする。しかしながら、多くの構成を見せることは、２．５ｄでは非常に困難になる。単一の画像がそれぞれの視点で利用される場合、画像の異なるバージョンが、すべての色及び構成の可能性のために、及びそれぞれのフレームのために生成されなければならない。これは、資産の数を非常に多くするので、簡単な製品以外では実用的な技術ではない。
【０００８】
従来のコンフィギュレータにおいてすべての構成を見せる試みは、それぞれの構成のために独特な画像を生成することを含むであろう。これは、生成される必要のある非実用的な数のフレームをもたらす。本実施例では車両である製品の構成データが与えられ、カメラの動き（camera move）において２４フレーム、１０種類の塗装色がある。
【０００９】
【表１】
【００１０】
（排他情報を考慮することなく）組み合わせの数を計算すると以下のようになる。
【００１１】
構成（着色前）＝２×７×３×３×２×２×３
構成（着色前）＝１，５１２
構成（着色後）＝１，５１２×１０
構成（着色後）＝１５，１２０
フレーム（着色後）＝１５，１２０×２４
フレーム（着色後）＝３６２，８８０
【００１２】
（すべてのパーツにわたって単一の塗装色を仮定すると）１５，１２０種類の車両の可能な独特な構成が存在する。それぞれの構成は、フレームスタック（フリップブック（flip book）と同様に連続して再生されたときに、３ｄカメラの動きを再現する画像の集合。）になる。これは、２４フレームのコンフィギュレータについては、生成されるべきフレームの総数が３６２，８８０個であることを意味する。着色されるそれぞれのパーツが独自の色を有すること（すなわち、緑色のベース車両及び赤色のスポイラーなど）を可能にすると、数はより多くなる。
【００１３】
構成（着色後）＝（２×１０）×７×（３×１０）×３×（２×１０）×２×３
構成（着色後）＝１，５１２，０００
フレーム（着色後）＝１，５１２，０００×２４
フレーム（着色後）＝３６，２８８，０００
【００１４】
これらのオプションのどちらも、そのような数のフレームを生成すること、及びその量を取り扱うことができるウェブサーバを配置することの両方の点から、非実用的である。さらに、追加のパーツ、特に着色されるパーツを追加することは、フレームの数を大幅に増加させる。２．５ｄコンフィギュレータでの従来の試みは、一般に、見せるために選択する構成の数を厳しく制限すること、フレームの数を減少させること、又はそれらの両方によってこの問題を解決して、製品コンフィギュレータの実行を簡略化する。
【００１５】
図１は、製品構成の簡易化した概念を示す。製品はそのパーツの全体である。この例では、単一の製品構成は、Ａ−Ｂ−Ｃ−Ｄと呼ばれる。エレメントＡ及びＢは、常に要求されかつ置き換えられないベースの製品として考えられる。エレメントＣ及びＤは、Ｃ又はＤの任意の変更と置き換えられるオプションである。Ｃ１乃至Ｃｎ及びＤ１乃至Ｄｎは、Ａ及びＢに影響することなく交換されることが可能である。さらに、製造業者は、Ｃｎ及びＤｎの組み合わせをパッケージとして定めてもよい。Ａ及びＢと組み合わせられたこのパッケージは、製造業者が特別な製品及び価格として提供するパッケージ１を有する特定の製品ＡＢとして定められてもよい。さらに、追加のＡＢの組み合わせが存在してもよいが、我々はベースモデルＡＢの１つの問題を考察する。Ｃｎ及びＤｎに加えて、Ａｎ及びＢｎが存在してもよい。
【００１６】
次に、“製品”は、単一の構成においてともに選ばれるいくつかの構成要素として広く定められる。オプションの又は独特な構成要素の数が増加するにつれて、可能な組み合わせは桁違いに増加する。例えば、自動車のような消費者製品は、内装及び外装のために数百種類のオプションを有する可能性がある。色、ホイール、タイヤ、車体パネル、及び付属品のようなオプションは、数百万種類の可能な組み合わせと同等であると見なすことができる。
【００１７】
特別なソフトウェア及び３ｄコンフィギュレータの複雑性なしに、すべての構成において複数の製品を表示する簡易化した処理に対する必要性が存在する。２．５ｄコンフィギュレータの改善が本明細書で開示される。
【課題を解決するための手段】
【００１８】
２ｄで示された複数のオプション、付属品、色などを用いて構成される製品の複数のマルチアングル画像を生成するコンフィギュレータが開示され、コンフィギュレータは、見る及びコンフィギュレータと相互作用するために特別なソフトウェア又はハードウェアを要求しない。コンフィギュレータは、製品がどのように複数の２ｄアートレイヤ（art layer）の関係を管理するためにコンフィギュレータエンジンで使用されるように組み立てられるかに関するレイヤ論理を自動的に生成する。本質的に、複数の２ｄ画像が、複数の製品のさまざまな構成をサポートする論理に基づいて任意の組み合わせに組み立てられる複数の３ｄモデルから階層化方法で生成される。例えば、図１に基づいて、論理は構成をＡＢＣ２１Ｄ１５として定義する。論理は、どのレイヤがその構成のために使用されるか、及びどの順序で複数のレイヤを組み立てるかを定める。３ｄリアルタイムは、複数の３ｄモデルからリアルタイムに論理に基づいて、単一の“組み立てられた”２ｄ画像を生成することができる。リアルタイムであらゆる組み合わせのために完成した完全な複数の製品のレンダリングされた画像を生成することは、一般的な複数のファクタ及び複数のオプションを定めて、事後に組み立てることによって最適化された階層化方法のアプローチを用いるよりも、顕著により多くの製品画像を要求するであろう。最適化は、構成された製品の複数のマルチアングル画像のために要求されるフレームの数を減少させる。
【００１９】
本開示は、それぞれのために別個の複数の画像を要求することなく、すべての可能な構成を生成することに関係した問題を解決する２．５ｄコンフィギュレータへのアプローチを提供する。このコンフィギュレータは、非常に高い画像品質、製品の周りの十分なカメラの動き、十分及び完全な複数の構成、及び制限されたソフトウェア及びハードウェアの制約を持った可能な限り幅広い聴衆を有する。技術は、従属的なマスキングと最適化されたレイヤ順序の上位の追跡との組み合わせを含む。現在開示されたサンプルの構成とともにこの技術を利用すると、８０個のフレームスタックが、１，５１２，０００種類の異なる構成を生成するために使用される。
【００２０】
階層化方法を用いて、製品コンフィギュレータは、多数の組み合わせの画像を生成することができる。コンピュータで生成された画像（ＣＧＩ）の使用は、任意の消費者製品のためのあらゆる可能な組み合わせの印刷、相互作用、又は放送のための複数の２ｄ画像を生成するために用いられる３ｄモデルの構築を可能にする。２ｄ空間のためのすべての可能な組み合わせを構成するために、画像階層化方法があらゆる単一の可能な組み合わせのための完全な製品画像をレンダリングする必要がないようにするために用いられる。この処理は、製品の小区分が画像によって表現されるように要求することのみによって、あらゆる組み合わせの生成において効率性を著しく改善する。最も一般的なファクタは、１つのレイヤ上にレンダリングされる一方、変化しやすい複数のファクタは、別々の複数のレイヤ上にレンダリングされる。
【００２１】
すべてのフレームがレンダリングされると、それらのフレームは、さまざまな方法によって製品の正確な表現に組み立てられる。これは、典型的に、どのように部品が組み合わされるかに関連した論理を考慮するプログラムによって達成される。この論理は、レンダリングされるフレームの数が、数個から数十万個に増加するにつれて、ますます重要になる。例えば、すべての構成のための製品の単一のビューを生成することを可能にすることは、数百個のフレームを必要とするであろうし、一方、同じ製品及びオプションの３６０度のビューは、すべての構成を表現するために数千個のフレームを必要とするかもしれない。
【００２２】
これらの製品の組み合わせがどのように構成されるかに関連した論理は、典型的に、組み立てガイドを介して、又は製品に関する人間の知識に基づいて、製造業者によって提供される。さらに、いくつかの構成要素は、論理をさらに定義する独特なパッケージに組み合わされる。
【００２３】
これらの画像の複数の構成は、典型的に、複数のレイヤへのローカルインタフェースを介し、スタンドアロンコンピュータ又はインターネットを経由し、ウェブブラウザ又はアプリケーションを介してユーザに提供される。特別なソフトウェア又はハードウェアは必要ない。システムは、好ましくは、データ、論理、及びユーザインタフェースを切り離すために、モデルビューコントローラ（ＭＶＣ）パターンを用いて設計される。理想的には、システムは、さまざまなサイズの複数のファイル、及びウェブ、印刷、及びキオスクなどの多数のアプリケーションに対して、プラグアンドプレイのように柔軟である。システムは、すべての構成のためのモーションメディア（motion media）をサポートするであろう。
【００２４】
コンフィギュレータは、コードにおいて実質的な変更なしに、複数の新しい製品をサポートすることができる。ほとんどの場合、構成の更新は、ユーザがすべての画像を再生成することを必要とせず、さまざまな面が再使用されることから、製造業者は、最初の及び後続のセットアップ及びレンダリングに再度目的を持たせることによって、製品の寿命を通して利益を得るであろう。これは、コスト及び複雑性を減少させる。
【００２５】
単なる非限定的な例として与えられる添付の図面とともに考慮されるコンフィギュレータの以下の説明を参照することによって、本開示の上述した機能及び別の機能、及びそれらの機能を得る方法がより明らかになり、本開示自身が最も理解されるであろう。
【図面の簡単な説明】
【００２６】
【図１】Ａ−Ｂ−Ｃ−Ｄと呼ばれる製品構成の概念を示す。
【図２】コンフィギュレータの処理のフローチャートを示す。
【図３】箱、球、及び角錐である空間内の３つのオブジェクトの例、及びビューに依存してどのオブジェクトが別のオブジェクトを塞ぐかを決定する例を示す。
【図４】角錐、球、及び箱の順序である３つのオブジェクトの例を示す。
【図５】箱、球、及び角錐の順序である図３の例を示すビュー２、及び角錐、球、及び箱の順序である図４の例を示すビュー１としてカメラアングルを示す。
【図６】カメラのロケーションから３ｄオブジェクトまでの距離に基づいたＺ方向の深さを示す。
【図７】円柱がフォークの後ろでありかつ前である相互的な閉塞の例を示す。
【発明を実施するための形態】
【００２７】
本明細書で提示される例示は、いかなる方法によっても本開示の範囲を制限すると解釈されるべきではない本開示の実施形態を説明する。現在認識されている本開示を実行する最良の形態を例示する例示的な実施形態の以下の詳細な説明を考慮することにより、本開示の追加の機能が当業者に明らかとなるであろう。
【００２８】
本開示は、異なる形式の実施形態に影響されやすいことがあるが、本明細書で詳細に説明される図面は、本説明が、本開示の原理の例示であるとみなされるべきであり、かつ網羅的であること、又は本開示を以下の説明で説明される又は図面で示される構造の詳細及び構成要素の配置に限定することを意図しないという了解の下で、実施形態を示す。
【００２９】
図２は、以下で詳述されるコンフィギュレータの処理のフローチャートを示す。３ｄアプリケーションでは３ｄ製品が構築され、データがコンフィギュレータ用に製品の構成要素のために収集され、まとめられる。次に、コンフィギュレータエディタは、製品構成を生成し、３ｄファイルにリンクする。３ｄアプリケーションは複数のＺ方向の深さパス（pass）をレンダリングし、閉塞プロセッサは複数のＺ方向の深さフレームを処理する。コンフィギュレータエディタは、相互的な閉塞情報をインポートし、最適なレイヤ順序を決定する。３ｄアプリケーションは、レンダリングがディスクに書き込まれる時点で、複数の最終的なフレーム及び構成ファイルをレンダリングする。その後、コンフィギュレータエディタは、合成スクリプトを生成する。合成ソフトウェアは、複数のフレームを仕上げて、かつ任意の必要な色の変更を実行する。コンフィギュレータエディタはオプションとして、複数のフレームを切り取る、複数のフレームの名前を変える、及び複数のフレームを変換することができる。例としての２．５ビューアは、ユーザの入力ごとに要求に応じて複数のレイヤを組み立てることができる。
【００３０】
印刷又はグラフィカルユーザインタフェースのいずれかを用いて、製品の２ｄ画像を表示するために、製品を構成する処理をプログラミングすることの単純化が開示される。これは、画像の複数のレイヤが生成される時点で製品の構成論理を生成する解決策を用いて達成され、それによって、論理を複数のレイヤと自動的にリンクする。
【００３１】
膨大な数のフレームを生成すること、又はそれらを取り扱う適切なウェブサーバを有することは、必要とされるフレームスタックの数を減少させる構成要素の分離、及びレイヤの順序付けを用いる一方、独特な色でそれぞれの塗装されたパーツを有する能力を含むすべての構成を生成する能力をさらに維持する新しい２．５ｄコンフィギュレータを用いて対処される。複数の別々のフレームスタックとして構成のそれぞれの構成要素をレンダリングすることによって、それぞれの構成のために独特な画像を必要とすることなく、個別の部品が一緒に合成されて、異なる複数の製品構成を生成する。
【００３２】
２ｄにおける構成要素の分離．
２．５ｄコンフィギュレータにおいて階層化作業を実行する第１のステップは、単一の２ｄビューに関する問題を解決することである。最初は、解決策が、構成のそれぞれの構成要素の複数の画像をレンダリングして、その後、それらを正しい順序で互いの上にレンダリングする（すなわち、スポイラーのレイヤがトリムレベルベースの上に置かれる）ように簡単であると見えるかもしれない。このような解決策は、３ｄオブジェクトを扱うときに、最も簡単な場合にのみ動作する。
【００３３】
例えば、自動車製品の３／４正面斜視図から製品を見ると、フロントホイール／タイヤの一部がフロントフェンダによって隠される。ホイールウェル（wheel well）がホイール／タイヤを“マスキング”しているといえる。さらに、ホイール／タイヤはまた、フロントフェンダの後部の一部を隠し、又はマスクする。２つのオブジェクトの別々の複数の画像を階層化する試みは、どのような順序でも正しい結果を生成しないであろう。フェンダの上にホイール／タイヤの複数の画像を挿入すること、及びその逆のどちらも動作しない。
【００３４】
図３及び図４は、空間内の３つのオブジェクト（箱、球、及び角錐）の例、及びビューに依存してどのオブジェクトが別のオブジェクトを塞ぐかを決定する例を示す。図５では、ビュー２のカメラアングルは、箱、球、及び角錐の順序である図３の例を示し、一方ビュー１は、角錐、球、及び箱の順序である図４の例を示す。
【００３５】
これらの場合では、簡単な階層化は、３ｄにおける複数のオブジェクトの相互作用のために動作しない。複数のオブジェクトが一緒にレンダリングされるとき、任意の与えられたピクセルで、カメラの視点からどのオブジェクトが別のオブジェクトの上にあると考えられるべきかを決定するために、３ｄ深さ情報又はＺ方向の深さが用いられる。これらのオブジェクトを別々にレンダリングすることによって、深さにおける相互作用が失われ、回復されない。
【００３６】
図６は、どのように３ｄシーンの与えられたカメラのビューのためのＺ方向の深さが決定されるかを示す。与えられたオブジェクトが出現する２ｄレンダリングされた画像のそれぞれのピクセルについて、カメラのワールド空間（world space）からのオブジェクトの距離を表す深さの値を計算する。カメラ座標系では、この深さの値はＺ軸に沿った距離であるので、深さの値はＺ方向の深さと呼ばれる。図は、単一のピクセルのためのそれぞれのオブジェクトに関連したＺ方向の深さの値を示す。この例では、ピクセルが箱の上に投影されている場合、深さの値は０．２である。ピクセルが球の上に投影されている場合、Ｚ方向の深さの値は０．５である。最後に、ピクセルが角錐の上に投影されている場合、深さの値は０．７である。カメラにより近いオブジェクトとピクセルとの交点は、カメラからより離れた交点より低い値を有する。あらゆるピクセルに対してそれぞれのオブジェクトのＺ方向の深さの値を求めることは、任意の与えられたピクセルにおいて、オブジェクトがカメラに関してどのように空間的に関係しているかを発見することを可能にする。
【００３７】
本問題に対する現在開示される解決策は、マスキングを用いて複数のオブジェクトを一緒に、複数回レンダリングすることである。ホイール／タイヤのために利用されるパスの間、フェンダは、最終的な出力におけるマスクオブジェクトとしてのみ考慮される。これは、フェンダがどのようなピクセルも最終的な画像に与えないことを意味する。その代わりに、フェンダは、フェンダがホイール／タイヤの上にあると考えられる場所において、ホイール／タイヤの画像を“切り取る”のみである。フェンダのためのパスは、正確に反対のことによって得られる。ホイール／タイヤが、フェンダのマスクになる。これは、どちらか一方の順序で互いの上に重ねられるホイール／タイヤ及びフェンダのレンダリングを生成する効果を有し、依然として正しい結果を生成する。
【００３８】
これは、２つのオブジェクト間の簡単な相互作用に対してよく動作するが、多数のオブジェクトが含まれるときには、より複雑になる。例えば、上記で用いた車両構成の例では、３つの異なる地面効果、及び２つのベーストリムレベル（ベーストリムレベルは、上記で議論した実際のホイールウェルの形状を含む）が存在する。このような例では、これらの構成要素が、与えられたホイール／タイヤのマスキングに影響する。これは、与えられたホイール／タイヤが、以下に示すそれぞれのマスクの組み合わせのために複数回レンダリングされるべきであることを意味する。
【００３９】
ベーストリム１及び地面効果１によってマスクされたホイールＸ（ｗｈＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ１＿ｇｅ１）
ベーストリム２及び地面効果１によってマスクされたホイールＸ（ｗｈＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ２＿ｇｅ１）
ベーストリム１及び地面効果２によってマスクされたホイールＸ（ｗｈＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ１＿ｇｅ２）
ベーストリム２及び地面効果２によってマスクされたホイールＸ（ｗｈＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ２＿ｇｅ２）
ベーストリム１及び地面効果３によってマスクされたホイールＸ（ｗｈＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ１＿ｇｅ３）
ベーストリム２及び地面効果３によってマスクされたホイールＸ（ｗｈＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ２＿ｇｅ３）
【００４０】
同様に、地面効果がレンダリングされるときは、地面効果はベーストリム及びホイールによってマスクされるべきである。
【００４１】
ベーストリム１及びホイール１によってマスクされた地面効果Ｘ（ｇｅＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ１＿ｗｈ１）
ベーストリム２及びホイール１によってマスクされた地面効果Ｘ（ｇｅＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ２＿ｗｈ１）
・・・
ベーストリム１及びホイール１によってマスクされた地面効果Ｘ（ｇｅＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ１＿ｗｈ７）
ベーストリム２及びホイール１によってマスクされた地面効果Ｘ（ｇｅＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ２＿ｗｈ７）
【００４２】
排気管の先端などの別の機能を追加すると、これはさらに複雑になる。
【００４３】
地面効果、ベーストリム、及びホイール／タイヤによって表示された関係の型は、“相互的な閉塞（two-way occlusion）”と呼ばれる。相互的な閉塞は、あるピクセルにおいて構成要素Ａが構成要素Ｂの上にあると考えられ、一方、同一の画像の別のピクセルにおいて、構成要素Ｂが構成要素Ａの上にあることがわかったときに発生する。図７は、円柱がこの視点からは同時にフォークの後ろでありかつ前である相互的な閉塞の例を示す。このような場合、構成要素Ａのカテゴリは、Ｂのカテゴリと相互的な閉塞にあるといわれる。それは、相互的に塞がれるとしてマークされる又は識別される親のカテゴリのために、単一の構成要素の間の相互的な閉塞の単一のインスタンスを取るのみである。
【００４４】
上述したような簡単な構成では、２つの閉塞は、オペレータが簡単に、さまざまな構成要素を有するビューを見て、どの構成要素が別の構成要素を塞いでいるかについての知識に基づく推測を作成することによって決定される。プログラムでこの情報を決定することも可能であり、これはより複雑な場合に有用であり、以下のように対処されるであろう。上記の構成例のための相互的な閉塞の情報の例を示す。
【００４５】
【表２】
【００４６】
相互的な閉塞のすべての場合のためのマスキングを用いて、この２ｄビューのためのすべての構成を生成するために必要なレンダリングの数は、以下のように計算される。
【００４７】
ｂｔのレンダリング＝８４０＝２×７×３×２×１０（色）
ｗｈのレンダリング＝８４＝７×２×３×２
ｇｅのレンダリング＝３６０＝３×２×３×２×１０（色）
ｅｔのレンダリング＝８４＝２×２×７×３
ｓｐのレンダリング＝４０＝２×２×１０（色）
ｓｒのレンダリング＝４＝２×２
ａｎのレンダリング＝４＝２×２
−−−−−−−−−−−−−−−−−−−−−−−−−−
合計のレンダリング（着色後）＝１，８９６
【００４８】
これは、あらゆる組み合わせが実行される場合に必要な１５，１２０回のレンダリングからの（ほとんど１桁の）大幅な減少である。しかしながら、この処理は、すべてのパーツについて別々の色を有する能力をサポートし、すべての色の組み合わせを実行するためにとられるであろう１，５１２，０００回のレンダリングと比較されるべきものである。
【００４９】
最適化．
すべての構成を生成するために必要な合計のフレームスタックを大幅に減少させるために用いられる４つの最適化が存在する。
【００５０】
最適化１：組み合わせレンダリング．
第１の最適化は、異なる色の複数の構成要素を組み合わせる必要がないという仮定のもとでのみ用いられる。いくつかの場合では、これは合理的な仮定であり、別の場合では合理的ではない。相互的な閉塞によって接続されたすべてのカテゴリのレンダリングをグループ分けし、それらを一緒にレンダリングすることによって、大幅な節約が得られる。上述の例では、ｂｔ，ｗｈ，ｇｅ，及びｅｔのレンダリングがすべて、単一の画像で一緒に実行される。これを実行することによって、１００８回のレンダリングがスキップされる。
【００５１】
最適化＃１のみの使用
ｂｔ，ｗｈ，ｇｅ，ｅｔのレンダリング＝８４０＝２×７×３×２×１０（色）
ｓｐのレンダリング＝４０＝２×２×１０（色）
ｓｒのレンダリング＝４＝２×２
ａｎのレンダリング＝４＝２×２
−−−−−−−−−−−−−−−−−−−−−−−−−−
合計のレンダリング（着色後）＝８８８
【００５２】
この最適化で用いられた単一色の仮定のために、この最適化は以降の例では使用されないであろう。
【００５３】
最適化２：独特なマスクのみの使用．
第２の最適化は、独特なマスクのみを考慮することである。自動車のホイール／タイヤの組み合わせは、本方法が大幅な量のレンダリングを節約することができる主要な例である。車両のホイール／タイヤは一般に、ホイールサイズ（１６インチ，１７インチ，１８インチなど）とタイヤ全体の直径との組のみである。この観察についての重要なことは、同じサイズのタイヤの輪郭は一致するということである。これは、マスキングの目的では、これらは同一であると考えられることを意味する。これが適用できるもう１つの場合は、構成要素が２つの異なる仕上げを有するが、同じ形状であるときである。例えば、フロントグリルが、アルミニウム及び光沢のあるクロムであってもよい。それが提供する形状、及びしたがってマスクは同一であるので、グリルの１つのみ又はホイール／タイヤの場合、それぞれのタイヤサイズについて１つのみを考慮することによって、相互的な閉塞における任意のオブジェクトが、それ自身を効果的にレンダリングする。この最適化をサンプルの車両構成に適用することによって、以下のレンダリングの数が得られる（ホイール／タイヤのマスキングが、３つのサイズのために７から３に変化する）。
【００５４】
最適化＃２のみの使用
ｂｔのレンダリング＝３６０＝２×３×３×２×１０（色）
ｗｈのレンダリング＝８４＝７×２×３×２
ｇｅのレンダリング＝３６０＝３×２×３×２×１０（色）
ｅｔのレンダリング＝３６＝２×２×３×３
ｓｐのレンダリング＝４０＝２×２×１０（色）
ｓｒのレンダリング＝４＝２×２
ａｎのレンダリング＝４＝２×２
−−−−−−−−−−−−−−−−−−−−−−−−−−
合計のレンダリング（着色後）＝８８８
【００５５】
これは、顕著な違いをもたらし、レンダリングの数を半分以上削減する。
【００５６】
最適化３：レンダリング後の色の変更．
第３の最適化は、車の塗装の着色を、レンダリング処理の後まで延期することを含む。色の変更は、２ｄレンダリングされた複数の画像上で、合成プログラムによって実行される。複数のフレームの単一のバージョンが、銀色などの一般的な色でレンダリングされる。これらの銀色のレンダリングはその後、車両が構成されるさまざまな色に変更される。この処理は、３ｄコンテンツ生成アプリケーションからそれぞれの色をレンダリングするよりも１桁速い。この速度の節約は、次節で２．５コンフィギュレータが考察されるときに、さらに組み合わせられる。
【００５７】
最適化＃２及び＃３の使用
ｂｔのレンダリング＝３６＝２×３×３×２
ｗｈのレンダリング＝８４＝７×２×３×２
ｇｅのレンダリング＝３６＝３×２×３×２
ｅｔのレンダリング＝３６＝２×２×３×３
ｓｐのレンダリング＝４＝２×２
ｓｒのレンダリング＝４＝２×２
ａｎのレンダリング＝４＝２×２
−−−−−−−−−−−−−−−−−−−−−−−−−−
合計のレンダリング（着色なし＊）＝２０４
＊色は後処理において後ほど追加される。
【００５８】
上述した技術、及び上記で開示された３つの最適化を用いると、あらゆる可能な構成を生成するほとんどの任意の２ｄコンフィギュレータを実行することが実用的である。しかしながら、複雑な構成のために、これらのコンフィギュレータを２．５ｄに変換することは、まだ非常に困難である。
【００５９】
２．５ｄにおける構成要素の分離．
構成要素の分離は、いくつかの問題を伴って２．５ｄに拡張される。当然、カメラの動きの複数のフレームにわたって２ｄの構成要素の分離のために説明されたように、複数のレイヤを簡単にレンダリングすることは意味をなす。残念ながら、そのような簡単な解決策は動作しない。問題は、相互的な閉塞、及びカメラの動きによって回転させられる複数の構成要素の相互作用に帰着する。例えば、最初のフレームでは、構成要素Ａが完全に構成要素Ｂの上にあると仮定する。その後、３６０度のカメラの動きにおけるより後のフレームでは、構成要素Ｂが今や完全に構成要素Ａの上にある。２ｄにおける相互的な閉塞の上述した例と同様に、このような深さ順序の変更は、相互的な閉塞として考慮される。相互的な閉塞は、複数の単一のフレームについてのみではなく、全体的なカメラの動きにわたってすべてのフレームについてチェックされるべきである。
【００６０】
２．５ｄにおける相互的な閉塞のユーザベースの推測は、すべての可能性についてほとんど不可能である。その代わり、与えられたカメラの動きにわたって相互的な閉塞のすべての場合を検出する特別なアプリケーション（閉塞プロセッサと呼ばれる。）が開示される。アプリケーションが動作するために、アプリケーションは、製品に関するカメラの動きについて、あらゆるフレームのあらゆるピクセルにおけるあらゆる構成要素の深さ情報、及び複数の構成についての基本的な情報にアクセスすることを要求する。深さ情報は、最終的な出力と同じ解像度で２ｄ画像において３２ビットの浮動小数点値として提供される。構成は、ｘｍｌファイルとして渡される。閉塞プロセッサは、両方を受け取り、相互的な閉塞行列を計算し、行列はその後、コンフィギュレータのマスキング処理を駆動するために用いられる。
【００６１】
閉塞プロセッサが、上記で用いられた例のコンフィギュレータ上で実行される場合、プロセッサは、２ｄコンフィギュレータにおいて発見された閉塞に加えて、サンルーフとアンテナとの間の相互的な閉塞が存在することも検出するであろう。以下に２．５ｄコンフィギュレータの相互的な閉塞の表を示す。
【００６２】
【表３】
【００６３】
ｓｒ及びａｎについてのフレームスタック上の相互的な閉塞は、表の右下の角における４つの箱のうちの２つにおいて、太字の“ｙ”として示される。
【００６４】
相互的な閉塞モデルを動作させること、及びそれを計算する方法によって、２ｄコンフィギュレータのために説明されたすべての技術をもとに２．５ｄコンフィギュレータを推測することができる。しかしながら、上述した３つの最適化が組み合わされても、いくつかの製品構成はまだ、非常に複雑であるので、２．５ｄに変換されたときに管理できなくなる。これらの場合を扱うために、最終的な最適化が開発された。
【００６５】
最適化４：レイヤの順序付け．
上述した技術は、任意のＺ方向の順序で組み立てられて、与えられた構成を生成することができるレンダリングを生成する。階層化のみの使用を試みることは、複数の構成要素の深さの相互作用によって失敗した。しかしながら、階層化とマスキングとの組み合わせは、任意の別の技術又は最適化よりも、はるかに多くレンダリングの数を減少させることができる。
【００６６】
基本的なアイデアは、複数の構成要素のカテゴリのために特有の階層化順序を定めることである。この特有のレイヤ順序を用いると、複数の構成要素のカテゴリが、レイヤ順序において下にある複数のカテゴリによってマスキングされることにのみ関係するべきであることから、要求されるマスキングが削減される。異なるレイヤ順序は、異なる結果を生成する。１つ又はグループのレイヤ順序は、最も少数の合計のフレームスタックを生成するであろう。この最適化された順序付けは、総当たり（brute force）技術を用いて簡単に計算される。
【００６７】
レイヤ順序の例１：
２．５ｄコンフィギュレータ
（レイヤ順序における）最適化＃２，＃３，及び＃４の使用：
７）ｓｐフレームスタック＝４＝２×２
６）ｓｒフレームスタック＝８＝２×２×２
５）ａｎフレームスタック＝４＝２×２
４）ｗｈフレームスタック＝８４＝７×２×３×２
３）ｅｔフレームスタック＝１２＝２×２×３
２）ｇｅフレームスタック＝６＝３×２
１）ｂｔフレームスタック＝２＝２
−−−−−−−−−−−−−−−−−−−−−−−−−−
合計のフレームスタック（着色なし）＝１２０
合計のレンダリングされたフレーム（着色なし）＝２８８０＝１２０×２４
【００６８】
レイヤ順序の例２：
２．５ｄコンフィギュレータ
（レイヤ順序における）最適化＃２，＃３，及び＃４の使用：
７）ｓｐフレームスタック＝４＝２×２
６）ｓｒフレームスタック＝８＝２×２×２
５）ａｎフレームスタック＝４＝２×２
４）ｇｅフレームスタック＝３６＝３×２×３×２
３）ｅｔフレームスタック＝１２＝２×２×３
２）ｗｈフレームスタック＝１４＝７×２
１）ｂｔフレームスタック＝２＝２
−−−−−−−−−−−−−−−−−−−−−−−−−−
合計のフレームスタック（着色なし）＝８０
合計のレンダリングされたフレーム（着色なし）＝１９２０＝８０×２４
【００６９】
これらの２つの例は、レイヤの順序付けがどのように合計のレンダリングの数に影響するかを示す。ホイール／タイヤをレイヤ４からレイヤ２に移動させて、地面効果と排気管の先端とを交換することによって、４０個のレンダリングが切り取られる。
【００７０】
要約すると、最後の３つの最適化を適用することによって、合計のレンダリングされるフレームの数は、３６，２８８，０００から１，９２０に削減される（最適化＃１を用いないことによって、我々はそれぞれの構成要素がそれ自身の色で表示される能力に言及し、また、色の変更は複数のフレームをレンダリングすることと比較して非常に速いため、ここでは色の変更は考慮されない。）。これは、処理をはるかに堅牢にし、最も複雑な製品コンフィギュレータのいくつかさえも取り扱うことができるようにする。さらに、複数の構成における順応的な変更（accommodating change）は、総当たり技術を用いる場合よりも、はるかに管理しやすくなる。
【００７１】
処理の概観．
車両の例についてのハイレベルな処理の概観では、すべてのトリムレベル及び可能なパーツにおける車両の複数の第１のデジタルモデルが生成され、まとめられる。その後、車両の製造業者から得られた構成情報は、データをモデルに添付するスクリプトに入力される。データは、カテゴリによって複数の構成要素に分解される。カメラの動きにわたってそれぞれの構成要素のＺ方向の深さのレンダリングが生成され、相互的な閉塞のすべての場合を検出する閉塞プロセッサに与えられる。このデータはその後、スクリプト／モデルのデータに返される。好ましい閉塞プロセッサは、手動の作業を不必要にするが、均一色（flat color）のレンダリングが生成され、最も少数の最終的なフレームスタックを生成する相互的な閉塞を出すために用いられる。その後、すべての車両の構成要素の最終的なレンダリングが、必要に応じて適用される一般的な銀色の車の塗装を用いて実行される。車の塗装を有する複数のフレームスタックは、車両が利用可能なすべての色に色変更される。すべてのフレームはその後、必要に応じて自動的に切り取られ、名前を変えられる。最後に、資産は、ユーザが車両を構成し、カメラの動きを通して車両を回転させることを可能にするアプリケーションに統合される。
【００７２】
処理の詳細．
要約すると、以下でより十分に詳述するように、複数の構成要素を有する製品のためのコンフィギュレータの処理は、
１）３ｄデータを複数の高次のパラメトリック曲面から複数の三角形メッシュにテッセレーションする（tessellating）ステップを含んでもよい、製品及び製品の複数の構成要素のための３ｄデータを収集しかつまとめるステップと、
２）詳細な構成情報を収集してどの構成要素の組み合わせが有効であるかを示すステップと、インタフェースを用いて詳細な構成情報をシーンファイルに入力しかつ記憶するステップと、複数の構成要素を複数の構成要素のカテゴリにまとめるステップと、複数の最終的なフレームスタックをレンダリングするステップと、色の複数のオプションを用いて合成ファイルを生成するステップと、３ｄマスクを複数の構成要素のそれぞれの部品の形状に関連付けるステップとを含んでもよい、製品の構成情報をセットアップするステップと、
３）Ｚ方向の深さの処理を用いて複数の相互的な閉塞を検出するステップと、複数の構成要素の間の複数の相互的な閉塞、及びどのフレームが複数の相互的な閉塞の検出をトリガしたかを詳述する行列を生成するステップと、コンフィギュレータスクリプトから閉塞プロセッサを用いて、閉塞プロセッサが閉塞情報を返し、結果を構成要素構成データベースに統合するステップとを含んでもよい、構成要素の相互的な閉塞を計算するステップと、
４）相互的な閉塞の複数のオプションを変更するステップ、又はレイヤ順序を変更しかつ複数のＺ方向の深さフレームを再処理するステップを含んでもよい、最適なレイヤ順序を決定するステップと、
５）相互作用によって製品の構成を変更することができるユーザのために、複数のフレームスタックをアプリケーションに統合するステップと、
６）ユーザの要求に応じて複数のフレームを動的にロードするステップとを含んでもよい。
【００７３】
構成情報／ＣＡＤデータ収集／データ準備．
コンフィギュレータの処理は、車両、車両のトリムレベル、及びすべてのオプションのパーツ及び付属品などの製品のための３ｄデータを収集すること／生成することから始まる。このデータは、三角形メッシュ、３ｄスキャンデータ、手でモデル化されたデータ、又は任意の別のタイプの３ｄデータにテッセレーションされる（tessellated）ＣＡＤデータであってもよい。車両は、単一の３ｄシーンファイルにデジタル的に組み立てられる。それぞれのトリムレベル、付属品、及びベース車両でさえも、それらをすばやくオフ及びオンすることを可能にする複数のレイヤによってシーンファイルにまとめられる。複数のレイヤのさまざまな状態をトグルすることは、それぞれの車両構成が再生される方法である。詳細な属性情報はまた、木目のパターン及び色のような材料の特質のマッチングに完全に適用される。
【００７４】
車両の構成情報のセットアップ．
モデルデータが収集される一方、詳細な構成情報も収集される。この情報は、トリムレベルのパッケージからオプションの付属品及び依存関係まで、最終的な車両においてどのパーツの組み合わせが有効であるかを示す。この情報は、具体的にはこの目的のために生成されたコンフィギュレータエディタアプリケーションに入力される。パーツは、複数の構成要素のカテゴリ（すなわち、“ホイール／タイヤ”、“地面効果”、“排気管の先端”）にまとめられる。それぞれの構成要素のカテゴリは、２つ又はそれ以上の構成要素（“１７インチの光沢のあるアルミニウムホイール”、“ＬＺＸ地面効果”、“二重のクロムの排気管の先端”）を有する。ユーザは、どの３ｄオブジェクトのレイヤがどの車両の構成要素に対応するかを指示する。すべての依存関係の情報がまた入力されて、この情報はシステムがどの組み合わせが有効で、どの組み合わせが有効でないか（すなわち、“１７インチの光沢のあるアルミニウムホイール”は、“ＬＸ”トリムレベルでは利用不可能である。）を決定することを可能にする。出力ファイルの名前をより読みやすくするために、別名が構成要素のカテゴリに与えられてもよい（“ホイール”が“ｗｈ”になってもよい。）。さらに、それぞれの部品の形状が、それに関連する３ｄデータのマスクを有するべきである。ほとんどの場合、これらのマスクは、形状そのものである。しかしながら、ホイール／タイヤのような特別な場合は、フレームスタックの数を減少させるために活用されてもよい。同じサイズのすべてのホイール／タイヤ（すなわち、１７インチの複数のホイール）は、同一のマスクデータを効果的に共有することができる。これは、ホイール／タイヤによってマスクされる任意のパーツは、すべてのホイール（４−１０種類のホイールが一般的である。）の代わりに、それぞれのホイール／タイヤのサイズ（標準装備として２−３種類のホイール／タイヤのサイズが一般的であるが、アフターマーケットでは、数百種類が利用可能である。）のためのマスクを用いてレンダリングされるだけでよいことを意味する。
【００７５】
複数のＺ方向の深さパスのレンダリング、及び相互的な閉塞の計算．
複数の構成要素が相互的な閉塞を示す場合を決定することが、処理における次のステップである。相互的な閉塞の場合を検出するために、カメラの動きにわたって３２ビットのＺ方向の深さフレームのレンダリングを処理し、かつ複数の構成要素の間で複数の相互的な閉塞が発生するすべての場合、及びどのフレーム又は複数のフレームが検出をトリガしたかを詳述する行列を生成するアプリケーションが開発された。プログラムは、それぞれの構成要素がカメラの動きにおけるそれぞれのフレームのためのレンダリングされた自分自身のＺ方向の深さを有することを必要とする。
【００７６】
コンフィギュレータエディタ及びアプリケーションインタフェースは、ユーザが、相互的な閉塞の処理のために必要とされるすべてのＺ方向の深さレンダリングを生成する、レンダリングのジョブのバッチを投入する（submit）ことを可能にするようにセットアップされる。すべてのレイヤが一度に送信されてもよく、又は個別の複数のレイヤが一度に１つ送信されてもよい。
【００７７】
複数のＺ方向の深さフレームが仕上げられると、閉塞プロセッサは、コンフィギュレータエディタから開始されてもよい。プロセッサは、すべての閉塞情報を返し、結果を構成要素構成データベースに統合する。
【００７８】
Ｚ方向の深さ方法の代替となる方法は、相互的な閉塞行列を手動で決定することである。これを実行する１つの簡単な方法は、低い品質のレンダリングの設定で、均一色でそれぞれの構成要素をレンダリングすることである。これら均一色のレンダリングはその後、手動の相互的な閉塞のテストのために、合成ソフトウェアにインポートされる。複数の構成要素は互いの上に階層化され、複数のフレームスタックは、カメラの動きを通して、どの構成要素が互いに影響するかをテストするために循環される。この手動の方法は、オペレータに責任を課すので好ましくなく、複数のフレームをレンダリングして組み立てる処理は、高度にパイプライン化されているので、誤った閉塞の決定の結果は、気付くためにはしばらく時間がかかる。オペレータが相互的な閉塞行列を誤った場合、これは、コンフィギュレータの処理をレンダリングのステップから再起動させる複数のフレームの再レンダリングを余儀なくさせる。
【００７９】
最適なレイヤ順序の決定．
複数の構成要素のカテゴリのための最適な階層化順序を決定することは、フレームスタックの数を最小に維持するために重要である。それぞれの可能なレイヤ順序についてフレームスタックの数をチェックする総当たり技術を用いて、最適なレイヤ順序をプログラムで決定することができる。レイヤの数が７又は８を越えると、この総当たり方法は長時間かかることがある。オペレータが、どれがよいレイヤ順序かについて知識に基づく推測を実行し、コンフィギュレータエディタにその順序についてのフレームスタックの数を計算させることがより速いこともある。オペレータはその後、元の順序と比較するために、別のレイヤ順序を試み、フレームスタックの数を計算してもよい。通常、製品の３ｄ表現をよく理解しているオペレータは、どのレイヤ順序であるべきかについてよい推測をすることができ、その後、それを絞り込んで、少数の異なるオプションをテストすることができる。オペレータがレイヤ順序についてこのような判断ができないときは、構成が簡単な場合、又は時間が制約されない場合には、総当たり技術が用いられてもよい。総当たりがオプションではない場合、合理的なフレームスタックの数を生成する任意のレイヤ順序が、実行可能なオプションである。本明細書で上述したように、いくつかのレイヤ順序が別のものよりもより多くのフレームスタックを生成する事実以外に、任意の与えられたレイヤ順序が用いられない技術的な理由はない。
【００８０】
均一色のレンダリングは、スキップされてもよいオプションであるが、このバリエーションでは、ユーザは、（コンフィギュレータスクリプトを再び用いて）非常に低い品質のレンダリングの設定で、構成要素自身の均一色でそれぞれの構成要素のレンダリングを開始して、レンダリングの時間を短く維持する。これらの均一色のレンダリングはその後、レイヤ順序のテスト、及び最終的な相互的な閉塞のテストのために、合成ソフトウェアにインポートされる（閉塞プロセッサは正確すぎることもあり、スポイラーの取り付け箇所などのメッシュにおける小さな穴に起因する相互的な閉塞の場合を検出するであろう。このような場合、オペレータは、どのカテゴリが互いに相互的な閉塞状態であるかについて、最終的な指示をするべきである。）。複数のレイヤの順序は、すべての有効なコンフィギュレータの組み合わせを生成するために必要なレンダリングの合計の数に大きな効果を有するので、オペレータはこのステップでは注意すべきである。閉塞プロセッサのバージョンは、小さい針穴のようなものが誤検出（false positives）を生成しないように、割合に基づいて動作するように設計される。さらに、閉塞プロセッサがより正確に相互的な閉塞を決定することができると、プロセッサはまた、最適なレイヤ順序を決定することができるであろう。ユーザが、最適なレイヤスタックの順序を決定すると、この情報は、コンフィギュレータスクリプトに入力し戻される。
【００８１】
複数の最終的なフレームスタックのレンダリング．
入力された構成情報を用いて、コンフィギュレータスクリプトは、適切にマスクされた複数の構成要素のレンダリングを生成することができる。レンダリングは、構成エディタからバッチで又は一度に１つ起動される。
【００８２】
分解シート（breakdown sheet）の命名．
データシートは、シーンファイルで必要とされるものよりもより詳細にコンフィギュレータ内に存在する複数の構成要素のそれぞれを分解するコンフィギュレータエディタから生成される。これは、パーツの実名、マスクｉｄ、構成要素が塗装されているか否か、閉塞の別名、レイヤ順序などのそれぞれの構成要素のための追加の情報を含む。また、塗装色のコード及び名前についての情報が、これに含まれてもよい。製品の製造業者は、最終的な提供品（deliverables）を決定する処理の一部として、分解シートを承認するべきである。
【００８３】
合成ファイルの構築．
塗装された車両の複数の構成要素をさまざまな色に色変更することは、２ｄ合成ソフトウェアにおいて実行される。専門化されたプラグインは、表面法線（surface normal）、反射、屈折などのデータを含む特別なレンダリングエレメントのバッファを用いて車の塗装のシェーダを再生するために利用される。これは、美術担当者がそれぞれのレンダリングエレメントの組み合わせを個別に微調整すること、及び２ｄの間にベース色を変更することを可能にする。一般に、ベースの銀色の車の塗装は、車両がどの色で利用可能であるかに依存して、５種類から１５種類程度の異なる色に変更される。合成スクリプト／ファイルは、生成されたすべてのレンダリングが、スクリプトに自動的に読み込まれ、かつ正しい経路（path）に書き出されるように、構成エディタによって生成される。多数のフレームスタックのためのすべてのリードノード（read node）及びライトノード（write node）をセットアップする処理は、手で実行すると手ごわくかつエラーが発生しやすいタスクであるので、このステップはオートメーションにおいて用いられる。いくつかの場合では、すべてのフレームスタックのために単一の合成ファイルを生成することは意味をなすが、一方、別の場合では、合成ファイルを別々のスクリプトファイルに分解することが意味をなす。
【００８４】
自動切り取りオプション．
ファイルサイズを減少させるために、すべての画像が、最終的なウェブアプリケーションにおいて、それらを簡単に利用可能にする方法で、構成要素のカテゴリによって自動的に切り取られる。自動的な切り取りは、ジョブを投入するための開始アプリケーション（kick-off application）を用いるレンダラ上で実行される。切り取りは、構成ファイルによって直接的に駆動される。
【００８５】
資産の名前変更オプション．
処理におけるより初期のステップによって生成された名前は、最終的なウェブアプリケーションにおいて使用するには適切でないことがあり、特に、パーツの番号、又はいくつかの別の命名規則に基づいて構成情報を提供する外部のデータサービスとの統合を試みるときに適切でないことがある。すべての資産をウェブアプリケーションによって要求される任意のフォーマットに名前を変更することを可能にする堅牢な名前変更処理が統合されている。名前変更のステップは、構成ファイルによって再び駆動される。これは、パーツの名前が、車両の色に基づいて変化する場合（これは、パーツが制限された数の色に塗装される直前である、又は事前に塗装されているときに発生する。）にも順応する。
【００８６】
最終的なウェブアプリケーション．
コンフィギュレータの処理の最後の部分は、ユーザが、マウスの相互作用又は別の入力デバイスを用いて、製品、すなわち車両を“回転させる”ことを可能にするアプリケーションに、複数のフレームスタックを統合することを含む。アプリケーションは、ユーザが製品の構成を変更するというような要求に応じて、レイヤ順序及び相互的な閉塞情報に基づいて、複数のフレームを動的にロードしなければならない。このようなユーザインタフェースは、ユーザの入力ごとに要求に応じて複数のレイヤを組み立てる２．５ｄビューアとなることができる。
【００８７】
論理．
すべてのレイヤがレンダリングされると、それらのレイヤは、さまざまな方法によって製品の正確な表現に組み立てられる。これは、典型的に、どのように部品が組み合わされるかに関連した論理を考慮するプログラムによって達成される。この論理は、レイヤの数又はフレームの数が、数個から数十万個に増加するにつれて、ますます重要になる。
【００８８】
これらの製品の組み合わせがどのように組み立てられるかに関連した論理は、典型的に、組み立てガイドを介して、又は製品に関する人間の知識に基づいて、製造業者によって提供される。さらに、論理をさらに定義する独特なパッケージに組み合わされるいくつかの構成要素が存在してもよい。
【００８９】
製品の構成は、典型的に、複数のレイヤ及び複数のフレームへのローカルインタフェースを介し、スタンドアロンコンピュータ又はインターネットを経由し、ウェブブラウザ又はアプリケーションを介してユーザに提供される。
【００９０】
すべてのレイヤを構成された製品画像に組み立てる能力は、階層化方法によって生成されたさまざまなレイヤに関連する論理を必要とする。複数のレイヤにリンクされた論理の正確さは、レイヤの数が増加するにつれて、ますます重要になる。これは、生産され得ない不正確な構成又は製品を防止する。
【００９１】
レイヤの数が増加するにつれて、組み立て処理を自動化する必要性が、ヒューマンエラーを防止するために必要になる。これは、典型的に、製造業者の組み立てドキュメントを介して、手動で論理にリンクされる複数のレイヤの命名規則を用いて取り扱われる。このリンクが確立されると、組み立てプログラムは、要求された複数のレイヤに、ユーザへ構成を提示するように命じることができる。これまで、論理と複数のフレームの命名とのリンクは、解決するために追加の資源を必要とするエラーを常に生成する手動の人間の介在を必要としていた。さらに、製品の複数のオプションにおける任意の変更、又は製品の設計の変更は、複雑性及び更新のためのコストをさらに追加する構成ファイルが再プログラムされることを要求することがある。
【００９２】
本明細書で概説されたアプローチは、リンクすること及び論理を複数のレイヤの生成フェーズに移動し、それによって、簡単なプログラムによって利用されて、視覚的なインタフェースにおいて複数のレイヤ及び複数のフレームを組み立てることができる構成論理ファイルを自動的に生成する。レンダリングのときに構成ファイルを生成することによって、製品の組み立て論理を複数の画像に手動でリンクする必要性が削除される。それによって、構成処理における手動のステップを削除する。
【００９３】
製造業者の組み立て論理に基づいて製品の複数の３ｄファイルをまとめること、及び本明細書で定義した階層化方法を用いることによって、製品論理が、複数の３ｄファイルが複数の構成の複数の製品画像を生成するためにどのように利用されるかを自動的に決定する一方、最適化処理によって全体の画像を減少させる。複数の画像がレンダリングされるときに、複数の画像がどのように構成された製品の正確な表現に組み立てられるかを決定する構成文書が生成される。構成文書の自動生成は、構成を表示することの全体の処理を簡単化する鍵である。
【００９４】
設計の変更は、製品のライフサイクルを通じて行われるので、更新された画像が新しい構成ファイルとともに生成されて、長期間の効果をさらに高める新しい構成エンジンをサポートする最新の状態に、複数の３ｄファイルが保たれることが望ましい。
【００９５】
本開示は、例示的な実施形態を用いて説明され、その一般的な原理を用いて任意のバリエーション、使用、又は適応を含むことを意図している。当業者は、以下の特許請求の範囲に列挙される本開示の精神及び範囲から逸脱することなく、さまざまな修正及び同等物を工夫することができると想像される。さらに、本開示は、それに付属する当業者の既知の又は通例の慣習であるように、本開示からのこのようなバリエーションを含むことを意図している。
【技術分野】
【０００１】
本開示は、製品、及び製品の複数の構成要素及び付属品を自動的に構成することができるコンフィギュレータに関する。さらに具体的には、コンフィギュレータ及び処理は、より大きな処理の一部として、製品のビューを示すために複数の２次元画像（２ｄ画像）を階層化すること及び使用することを含む。
【背景技術】
【０００２】
コンフィギュレータは、複数の独特な製品要求を必要なドキュメント及び情報に自動的に変換して、要求された製品の複数の構成を表示する。ウェブベースの及びコンピュータベースの製品コンフィギュレータソフトウェアアプリケーションは、ユーザの及び／又は製造業者の要求を満たすオプションの製品構成、価格決定、注文、及び販売を自動化する能力をユーザに提供する。具体的には、ウェブベースの製品コンフィギュレータは、製造業者の顧客の独特な要求を満たすように高度に構成可能な又は定期的にカスタマイズされる自動車などの製品を製造する製造会社のために設計されてもよい。製品のセットアップは、複数のビューにおいてさまざまな機能、及びオプションとともに表示される。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
製品コンフィギュレータをウェブ上で実行することは困難である可能性があるが、これらは製品を販売するときに非常に効果的である可能性がある。課題は、依然として高品質な画像を提供し、できるだけ多くの聴衆に届ける一方で、できるだけ多くの角度から（しばしば数十万種類の可能な構成が存在する。）それぞれの製品構成がどのように見えるかをユーザに見せることを含む。従来は、２ｄ画像ベースのコンフィギュレータ、及びリアルタイムの３次元（３ｄ）ベースのコンフィギュレータの中から選択しなければならなかった。
【０００４】
技術的には、製品コンフィギュレータは、正確な複数の製品画像を生成する３ｄ技術を用いて複数の画像を生成する。いくつかの視点からのビューを示す複数の製品画像は、異なる複数の構成及びビューにおいて、製品を簡単に見る能力をユーザに与えることによって生成されてもよい。典型的に、画像は、製品の正確な複製を示すべき多数の構成可能な置換を有する製品を持つ製造業者によって使用される。リアルタイムの３ｄレンダリングは、本明細書で開示される多くの表示機能を異なる方法で実行することができるが、コンフィギュレータの到達可能な聴衆を制限する特別なソフトウェア、及びハードウェアを要求することもある。
【０００５】
３次元（３ｄ）コンフィギュレータはしばしば、任意の及びすべての視点からの製品、及びさらに可能なすべての構成を表示する能力を提供するが、画像の品質は、ユーザのハードウェアの制限のために制限される可能性がある。さらに、３ｄコンフィギュレータは、ほとんどの場合、ユーザに３ｄビューイングソフトウェアをダウンロードしてインストールするように要求し、これはセキュリティ上の危険、時間的な妨害、又はユーザ及びユーザのコンピュータに対する技術的な障壁をもたらす可能性がある。また、コンフィギュレータの３ｄ性能はしばしば、特化したグラフィックスのハードウェアに依存する。リアルタイムの対話式のコンピュータグラフィックスの場合では、ユーザは通常、コンピュータのスクリーン上に表示されるものを制御している。典型的に、ユーザは、入力デバイスを使用して、フィードバックをシステムに提供し、ビデオゲームなどの３ｄリアルタイムはしばしば、グラフィックス処理ユニットなどの特別なソフトウェア又はハードウェアを要求する。これらの理由で、リアルタイム３ｄコンフィギュレータはしばしば、到達可能な聴衆が少なく、これが多くの会社がこれらを回避する製品構成を探す理由である。
【０００６】
２ｄコンフィギュレータは、複数の高品質な画像（写真、又は高品質なコンピュータで生成された画像（ＣＧＩ））を用いて製品を見せるが、コスト及び複雑性に起因して、視点の数、及びしばしば構成の数によって厳しく制限される。画像が写真の場合、すべてのパーツ及び色の物理的なバリエーションを入手することは、しばしば実現不可能であるので、複数の製品のすべての構成を示すことは極めて困難である。コンピュータで生成された資産は、それぞれに対して複数の独特な画像を用いて、すべての可能な構成を生成することができるが、それぞれの及びあらゆる個別の構成のために膨大な数の画像を生成する。しかしながら、２ｄコンフィギュレータは、しばしば基本的なウェブブラウザの能力以外は使用しないので、非常に大きい潜在的なビューア基盤を有する。
【０００７】
２．５ｄコンフィギュレータは、もう１つのオプションになる。これらのコンフィギュレータは、２ｄ画像のフレームスタックを用いて車両の周りの単一の３ｄカメラの動き（camera movement）をシミュレートすることによって、２ｄと３ｄとの間の妥協を作ろうと試みる。このアプローチは、従来の２ｄコンフィギュレータよりも高品質な画像、及びより多くの視点を可能にする。しかしながら、多くの構成を見せることは、２．５ｄでは非常に困難になる。単一の画像がそれぞれの視点で利用される場合、画像の異なるバージョンが、すべての色及び構成の可能性のために、及びそれぞれのフレームのために生成されなければならない。これは、資産の数を非常に多くするので、簡単な製品以外では実用的な技術ではない。
【０００８】
従来のコンフィギュレータにおいてすべての構成を見せる試みは、それぞれの構成のために独特な画像を生成することを含むであろう。これは、生成される必要のある非実用的な数のフレームをもたらす。本実施例では車両である製品の構成データが与えられ、カメラの動き（camera move）において２４フレーム、１０種類の塗装色がある。
【０００９】
【表１】
【００１０】
（排他情報を考慮することなく）組み合わせの数を計算すると以下のようになる。
【００１１】
構成（着色前）＝２×７×３×３×２×２×３
構成（着色前）＝１，５１２
構成（着色後）＝１，５１２×１０
構成（着色後）＝１５，１２０
フレーム（着色後）＝１５，１２０×２４
フレーム（着色後）＝３６２，８８０
【００１２】
（すべてのパーツにわたって単一の塗装色を仮定すると）１５，１２０種類の車両の可能な独特な構成が存在する。それぞれの構成は、フレームスタック（フリップブック（flip book）と同様に連続して再生されたときに、３ｄカメラの動きを再現する画像の集合。）になる。これは、２４フレームのコンフィギュレータについては、生成されるべきフレームの総数が３６２，８８０個であることを意味する。着色されるそれぞれのパーツが独自の色を有すること（すなわち、緑色のベース車両及び赤色のスポイラーなど）を可能にすると、数はより多くなる。
【００１３】
構成（着色後）＝（２×１０）×７×（３×１０）×３×（２×１０）×２×３
構成（着色後）＝１，５１２，０００
フレーム（着色後）＝１，５１２，０００×２４
フレーム（着色後）＝３６，２８８，０００
【００１４】
これらのオプションのどちらも、そのような数のフレームを生成すること、及びその量を取り扱うことができるウェブサーバを配置することの両方の点から、非実用的である。さらに、追加のパーツ、特に着色されるパーツを追加することは、フレームの数を大幅に増加させる。２．５ｄコンフィギュレータでの従来の試みは、一般に、見せるために選択する構成の数を厳しく制限すること、フレームの数を減少させること、又はそれらの両方によってこの問題を解決して、製品コンフィギュレータの実行を簡略化する。
【００１５】
図１は、製品構成の簡易化した概念を示す。製品はそのパーツの全体である。この例では、単一の製品構成は、Ａ−Ｂ−Ｃ−Ｄと呼ばれる。エレメントＡ及びＢは、常に要求されかつ置き換えられないベースの製品として考えられる。エレメントＣ及びＤは、Ｃ又はＤの任意の変更と置き換えられるオプションである。Ｃ１乃至Ｃｎ及びＤ１乃至Ｄｎは、Ａ及びＢに影響することなく交換されることが可能である。さらに、製造業者は、Ｃｎ及びＤｎの組み合わせをパッケージとして定めてもよい。Ａ及びＢと組み合わせられたこのパッケージは、製造業者が特別な製品及び価格として提供するパッケージ１を有する特定の製品ＡＢとして定められてもよい。さらに、追加のＡＢの組み合わせが存在してもよいが、我々はベースモデルＡＢの１つの問題を考察する。Ｃｎ及びＤｎに加えて、Ａｎ及びＢｎが存在してもよい。
【００１６】
次に、“製品”は、単一の構成においてともに選ばれるいくつかの構成要素として広く定められる。オプションの又は独特な構成要素の数が増加するにつれて、可能な組み合わせは桁違いに増加する。例えば、自動車のような消費者製品は、内装及び外装のために数百種類のオプションを有する可能性がある。色、ホイール、タイヤ、車体パネル、及び付属品のようなオプションは、数百万種類の可能な組み合わせと同等であると見なすことができる。
【００１７】
特別なソフトウェア及び３ｄコンフィギュレータの複雑性なしに、すべての構成において複数の製品を表示する簡易化した処理に対する必要性が存在する。２．５ｄコンフィギュレータの改善が本明細書で開示される。
【課題を解決するための手段】
【００１８】
２ｄで示された複数のオプション、付属品、色などを用いて構成される製品の複数のマルチアングル画像を生成するコンフィギュレータが開示され、コンフィギュレータは、見る及びコンフィギュレータと相互作用するために特別なソフトウェア又はハードウェアを要求しない。コンフィギュレータは、製品がどのように複数の２ｄアートレイヤ（art layer）の関係を管理するためにコンフィギュレータエンジンで使用されるように組み立てられるかに関するレイヤ論理を自動的に生成する。本質的に、複数の２ｄ画像が、複数の製品のさまざまな構成をサポートする論理に基づいて任意の組み合わせに組み立てられる複数の３ｄモデルから階層化方法で生成される。例えば、図１に基づいて、論理は構成をＡＢＣ２１Ｄ１５として定義する。論理は、どのレイヤがその構成のために使用されるか、及びどの順序で複数のレイヤを組み立てるかを定める。３ｄリアルタイムは、複数の３ｄモデルからリアルタイムに論理に基づいて、単一の“組み立てられた”２ｄ画像を生成することができる。リアルタイムであらゆる組み合わせのために完成した完全な複数の製品のレンダリングされた画像を生成することは、一般的な複数のファクタ及び複数のオプションを定めて、事後に組み立てることによって最適化された階層化方法のアプローチを用いるよりも、顕著により多くの製品画像を要求するであろう。最適化は、構成された製品の複数のマルチアングル画像のために要求されるフレームの数を減少させる。
【００１９】
本開示は、それぞれのために別個の複数の画像を要求することなく、すべての可能な構成を生成することに関係した問題を解決する２．５ｄコンフィギュレータへのアプローチを提供する。このコンフィギュレータは、非常に高い画像品質、製品の周りの十分なカメラの動き、十分及び完全な複数の構成、及び制限されたソフトウェア及びハードウェアの制約を持った可能な限り幅広い聴衆を有する。技術は、従属的なマスキングと最適化されたレイヤ順序の上位の追跡との組み合わせを含む。現在開示されたサンプルの構成とともにこの技術を利用すると、８０個のフレームスタックが、１，５１２，０００種類の異なる構成を生成するために使用される。
【００２０】
階層化方法を用いて、製品コンフィギュレータは、多数の組み合わせの画像を生成することができる。コンピュータで生成された画像（ＣＧＩ）の使用は、任意の消費者製品のためのあらゆる可能な組み合わせの印刷、相互作用、又は放送のための複数の２ｄ画像を生成するために用いられる３ｄモデルの構築を可能にする。２ｄ空間のためのすべての可能な組み合わせを構成するために、画像階層化方法があらゆる単一の可能な組み合わせのための完全な製品画像をレンダリングする必要がないようにするために用いられる。この処理は、製品の小区分が画像によって表現されるように要求することのみによって、あらゆる組み合わせの生成において効率性を著しく改善する。最も一般的なファクタは、１つのレイヤ上にレンダリングされる一方、変化しやすい複数のファクタは、別々の複数のレイヤ上にレンダリングされる。
【００２１】
すべてのフレームがレンダリングされると、それらのフレームは、さまざまな方法によって製品の正確な表現に組み立てられる。これは、典型的に、どのように部品が組み合わされるかに関連した論理を考慮するプログラムによって達成される。この論理は、レンダリングされるフレームの数が、数個から数十万個に増加するにつれて、ますます重要になる。例えば、すべての構成のための製品の単一のビューを生成することを可能にすることは、数百個のフレームを必要とするであろうし、一方、同じ製品及びオプションの３６０度のビューは、すべての構成を表現するために数千個のフレームを必要とするかもしれない。
【００２２】
これらの製品の組み合わせがどのように構成されるかに関連した論理は、典型的に、組み立てガイドを介して、又は製品に関する人間の知識に基づいて、製造業者によって提供される。さらに、いくつかの構成要素は、論理をさらに定義する独特なパッケージに組み合わされる。
【００２３】
これらの画像の複数の構成は、典型的に、複数のレイヤへのローカルインタフェースを介し、スタンドアロンコンピュータ又はインターネットを経由し、ウェブブラウザ又はアプリケーションを介してユーザに提供される。特別なソフトウェア又はハードウェアは必要ない。システムは、好ましくは、データ、論理、及びユーザインタフェースを切り離すために、モデルビューコントローラ（ＭＶＣ）パターンを用いて設計される。理想的には、システムは、さまざまなサイズの複数のファイル、及びウェブ、印刷、及びキオスクなどの多数のアプリケーションに対して、プラグアンドプレイのように柔軟である。システムは、すべての構成のためのモーションメディア（motion media）をサポートするであろう。
【００２４】
コンフィギュレータは、コードにおいて実質的な変更なしに、複数の新しい製品をサポートすることができる。ほとんどの場合、構成の更新は、ユーザがすべての画像を再生成することを必要とせず、さまざまな面が再使用されることから、製造業者は、最初の及び後続のセットアップ及びレンダリングに再度目的を持たせることによって、製品の寿命を通して利益を得るであろう。これは、コスト及び複雑性を減少させる。
【００２５】
単なる非限定的な例として与えられる添付の図面とともに考慮されるコンフィギュレータの以下の説明を参照することによって、本開示の上述した機能及び別の機能、及びそれらの機能を得る方法がより明らかになり、本開示自身が最も理解されるであろう。
【図面の簡単な説明】
【００２６】
【図１】Ａ−Ｂ−Ｃ−Ｄと呼ばれる製品構成の概念を示す。
【図２】コンフィギュレータの処理のフローチャートを示す。
【図３】箱、球、及び角錐である空間内の３つのオブジェクトの例、及びビューに依存してどのオブジェクトが別のオブジェクトを塞ぐかを決定する例を示す。
【図４】角錐、球、及び箱の順序である３つのオブジェクトの例を示す。
【図５】箱、球、及び角錐の順序である図３の例を示すビュー２、及び角錐、球、及び箱の順序である図４の例を示すビュー１としてカメラアングルを示す。
【図６】カメラのロケーションから３ｄオブジェクトまでの距離に基づいたＺ方向の深さを示す。
【図７】円柱がフォークの後ろでありかつ前である相互的な閉塞の例を示す。
【発明を実施するための形態】
【００２７】
本明細書で提示される例示は、いかなる方法によっても本開示の範囲を制限すると解釈されるべきではない本開示の実施形態を説明する。現在認識されている本開示を実行する最良の形態を例示する例示的な実施形態の以下の詳細な説明を考慮することにより、本開示の追加の機能が当業者に明らかとなるであろう。
【００２８】
本開示は、異なる形式の実施形態に影響されやすいことがあるが、本明細書で詳細に説明される図面は、本説明が、本開示の原理の例示であるとみなされるべきであり、かつ網羅的であること、又は本開示を以下の説明で説明される又は図面で示される構造の詳細及び構成要素の配置に限定することを意図しないという了解の下で、実施形態を示す。
【００２９】
図２は、以下で詳述されるコンフィギュレータの処理のフローチャートを示す。３ｄアプリケーションでは３ｄ製品が構築され、データがコンフィギュレータ用に製品の構成要素のために収集され、まとめられる。次に、コンフィギュレータエディタは、製品構成を生成し、３ｄファイルにリンクする。３ｄアプリケーションは複数のＺ方向の深さパス（pass）をレンダリングし、閉塞プロセッサは複数のＺ方向の深さフレームを処理する。コンフィギュレータエディタは、相互的な閉塞情報をインポートし、最適なレイヤ順序を決定する。３ｄアプリケーションは、レンダリングがディスクに書き込まれる時点で、複数の最終的なフレーム及び構成ファイルをレンダリングする。その後、コンフィギュレータエディタは、合成スクリプトを生成する。合成ソフトウェアは、複数のフレームを仕上げて、かつ任意の必要な色の変更を実行する。コンフィギュレータエディタはオプションとして、複数のフレームを切り取る、複数のフレームの名前を変える、及び複数のフレームを変換することができる。例としての２．５ビューアは、ユーザの入力ごとに要求に応じて複数のレイヤを組み立てることができる。
【００３０】
印刷又はグラフィカルユーザインタフェースのいずれかを用いて、製品の２ｄ画像を表示するために、製品を構成する処理をプログラミングすることの単純化が開示される。これは、画像の複数のレイヤが生成される時点で製品の構成論理を生成する解決策を用いて達成され、それによって、論理を複数のレイヤと自動的にリンクする。
【００３１】
膨大な数のフレームを生成すること、又はそれらを取り扱う適切なウェブサーバを有することは、必要とされるフレームスタックの数を減少させる構成要素の分離、及びレイヤの順序付けを用いる一方、独特な色でそれぞれの塗装されたパーツを有する能力を含むすべての構成を生成する能力をさらに維持する新しい２．５ｄコンフィギュレータを用いて対処される。複数の別々のフレームスタックとして構成のそれぞれの構成要素をレンダリングすることによって、それぞれの構成のために独特な画像を必要とすることなく、個別の部品が一緒に合成されて、異なる複数の製品構成を生成する。
【００３２】
２ｄにおける構成要素の分離．
２．５ｄコンフィギュレータにおいて階層化作業を実行する第１のステップは、単一の２ｄビューに関する問題を解決することである。最初は、解決策が、構成のそれぞれの構成要素の複数の画像をレンダリングして、その後、それらを正しい順序で互いの上にレンダリングする（すなわち、スポイラーのレイヤがトリムレベルベースの上に置かれる）ように簡単であると見えるかもしれない。このような解決策は、３ｄオブジェクトを扱うときに、最も簡単な場合にのみ動作する。
【００３３】
例えば、自動車製品の３／４正面斜視図から製品を見ると、フロントホイール／タイヤの一部がフロントフェンダによって隠される。ホイールウェル（wheel well）がホイール／タイヤを“マスキング”しているといえる。さらに、ホイール／タイヤはまた、フロントフェンダの後部の一部を隠し、又はマスクする。２つのオブジェクトの別々の複数の画像を階層化する試みは、どのような順序でも正しい結果を生成しないであろう。フェンダの上にホイール／タイヤの複数の画像を挿入すること、及びその逆のどちらも動作しない。
【００３４】
図３及び図４は、空間内の３つのオブジェクト（箱、球、及び角錐）の例、及びビューに依存してどのオブジェクトが別のオブジェクトを塞ぐかを決定する例を示す。図５では、ビュー２のカメラアングルは、箱、球、及び角錐の順序である図３の例を示し、一方ビュー１は、角錐、球、及び箱の順序である図４の例を示す。
【００３５】
これらの場合では、簡単な階層化は、３ｄにおける複数のオブジェクトの相互作用のために動作しない。複数のオブジェクトが一緒にレンダリングされるとき、任意の与えられたピクセルで、カメラの視点からどのオブジェクトが別のオブジェクトの上にあると考えられるべきかを決定するために、３ｄ深さ情報又はＺ方向の深さが用いられる。これらのオブジェクトを別々にレンダリングすることによって、深さにおける相互作用が失われ、回復されない。
【００３６】
図６は、どのように３ｄシーンの与えられたカメラのビューのためのＺ方向の深さが決定されるかを示す。与えられたオブジェクトが出現する２ｄレンダリングされた画像のそれぞれのピクセルについて、カメラのワールド空間（world space）からのオブジェクトの距離を表す深さの値を計算する。カメラ座標系では、この深さの値はＺ軸に沿った距離であるので、深さの値はＺ方向の深さと呼ばれる。図は、単一のピクセルのためのそれぞれのオブジェクトに関連したＺ方向の深さの値を示す。この例では、ピクセルが箱の上に投影されている場合、深さの値は０．２である。ピクセルが球の上に投影されている場合、Ｚ方向の深さの値は０．５である。最後に、ピクセルが角錐の上に投影されている場合、深さの値は０．７である。カメラにより近いオブジェクトとピクセルとの交点は、カメラからより離れた交点より低い値を有する。あらゆるピクセルに対してそれぞれのオブジェクトのＺ方向の深さの値を求めることは、任意の与えられたピクセルにおいて、オブジェクトがカメラに関してどのように空間的に関係しているかを発見することを可能にする。
【００３７】
本問題に対する現在開示される解決策は、マスキングを用いて複数のオブジェクトを一緒に、複数回レンダリングすることである。ホイール／タイヤのために利用されるパスの間、フェンダは、最終的な出力におけるマスクオブジェクトとしてのみ考慮される。これは、フェンダがどのようなピクセルも最終的な画像に与えないことを意味する。その代わりに、フェンダは、フェンダがホイール／タイヤの上にあると考えられる場所において、ホイール／タイヤの画像を“切り取る”のみである。フェンダのためのパスは、正確に反対のことによって得られる。ホイール／タイヤが、フェンダのマスクになる。これは、どちらか一方の順序で互いの上に重ねられるホイール／タイヤ及びフェンダのレンダリングを生成する効果を有し、依然として正しい結果を生成する。
【００３８】
これは、２つのオブジェクト間の簡単な相互作用に対してよく動作するが、多数のオブジェクトが含まれるときには、より複雑になる。例えば、上記で用いた車両構成の例では、３つの異なる地面効果、及び２つのベーストリムレベル（ベーストリムレベルは、上記で議論した実際のホイールウェルの形状を含む）が存在する。このような例では、これらの構成要素が、与えられたホイール／タイヤのマスキングに影響する。これは、与えられたホイール／タイヤが、以下に示すそれぞれのマスクの組み合わせのために複数回レンダリングされるべきであることを意味する。
【００３９】
ベーストリム１及び地面効果１によってマスクされたホイールＸ（ｗｈＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ１＿ｇｅ１）
ベーストリム２及び地面効果１によってマスクされたホイールＸ（ｗｈＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ２＿ｇｅ１）
ベーストリム１及び地面効果２によってマスクされたホイールＸ（ｗｈＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ１＿ｇｅ２）
ベーストリム２及び地面効果２によってマスクされたホイールＸ（ｗｈＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ２＿ｇｅ２）
ベーストリム１及び地面効果３によってマスクされたホイールＸ（ｗｈＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ１＿ｇｅ３）
ベーストリム２及び地面効果３によってマスクされたホイールＸ（ｗｈＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ２＿ｇｅ３）
【００４０】
同様に、地面効果がレンダリングされるときは、地面効果はベーストリム及びホイールによってマスクされるべきである。
【００４１】
ベーストリム１及びホイール１によってマスクされた地面効果Ｘ（ｇｅＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ１＿ｗｈ１）
ベーストリム２及びホイール１によってマスクされた地面効果Ｘ（ｇｅＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ２＿ｗｈ１）
・・・
ベーストリム１及びホイール１によってマスクされた地面効果Ｘ（ｇｅＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ１＿ｗｈ７）
ベーストリム２及びホイール１によってマスクされた地面効果Ｘ（ｇｅＸ＿ｍａｓｋｅｄｂｙ＿ｂｔ２＿ｗｈ７）
【００４２】
排気管の先端などの別の機能を追加すると、これはさらに複雑になる。
【００４３】
地面効果、ベーストリム、及びホイール／タイヤによって表示された関係の型は、“相互的な閉塞（two-way occlusion）”と呼ばれる。相互的な閉塞は、あるピクセルにおいて構成要素Ａが構成要素Ｂの上にあると考えられ、一方、同一の画像の別のピクセルにおいて、構成要素Ｂが構成要素Ａの上にあることがわかったときに発生する。図７は、円柱がこの視点からは同時にフォークの後ろでありかつ前である相互的な閉塞の例を示す。このような場合、構成要素Ａのカテゴリは、Ｂのカテゴリと相互的な閉塞にあるといわれる。それは、相互的に塞がれるとしてマークされる又は識別される親のカテゴリのために、単一の構成要素の間の相互的な閉塞の単一のインスタンスを取るのみである。
【００４４】
上述したような簡単な構成では、２つの閉塞は、オペレータが簡単に、さまざまな構成要素を有するビューを見て、どの構成要素が別の構成要素を塞いでいるかについての知識に基づく推測を作成することによって決定される。プログラムでこの情報を決定することも可能であり、これはより複雑な場合に有用であり、以下のように対処されるであろう。上記の構成例のための相互的な閉塞の情報の例を示す。
【００４５】
【表２】
【００４６】
相互的な閉塞のすべての場合のためのマスキングを用いて、この２ｄビューのためのすべての構成を生成するために必要なレンダリングの数は、以下のように計算される。
【００４７】
ｂｔのレンダリング＝８４０＝２×７×３×２×１０（色）
ｗｈのレンダリング＝８４＝７×２×３×２
ｇｅのレンダリング＝３６０＝３×２×３×２×１０（色）
ｅｔのレンダリング＝８４＝２×２×７×３
ｓｐのレンダリング＝４０＝２×２×１０（色）
ｓｒのレンダリング＝４＝２×２
ａｎのレンダリング＝４＝２×２
−−−−−−−−−−−−−−−−−−−−−−−−−−
合計のレンダリング（着色後）＝１，８９６
【００４８】
これは、あらゆる組み合わせが実行される場合に必要な１５，１２０回のレンダリングからの（ほとんど１桁の）大幅な減少である。しかしながら、この処理は、すべてのパーツについて別々の色を有する能力をサポートし、すべての色の組み合わせを実行するためにとられるであろう１，５１２，０００回のレンダリングと比較されるべきものである。
【００４９】
最適化．
すべての構成を生成するために必要な合計のフレームスタックを大幅に減少させるために用いられる４つの最適化が存在する。
【００５０】
最適化１：組み合わせレンダリング．
第１の最適化は、異なる色の複数の構成要素を組み合わせる必要がないという仮定のもとでのみ用いられる。いくつかの場合では、これは合理的な仮定であり、別の場合では合理的ではない。相互的な閉塞によって接続されたすべてのカテゴリのレンダリングをグループ分けし、それらを一緒にレンダリングすることによって、大幅な節約が得られる。上述の例では、ｂｔ，ｗｈ，ｇｅ，及びｅｔのレンダリングがすべて、単一の画像で一緒に実行される。これを実行することによって、１００８回のレンダリングがスキップされる。
【００５１】
最適化＃１のみの使用
ｂｔ，ｗｈ，ｇｅ，ｅｔのレンダリング＝８４０＝２×７×３×２×１０（色）
ｓｐのレンダリング＝４０＝２×２×１０（色）
ｓｒのレンダリング＝４＝２×２
ａｎのレンダリング＝４＝２×２
−−−−−−−−−−−−−−−−−−−−−−−−−−
合計のレンダリング（着色後）＝８８８
【００５２】
この最適化で用いられた単一色の仮定のために、この最適化は以降の例では使用されないであろう。
【００５３】
最適化２：独特なマスクのみの使用．
第２の最適化は、独特なマスクのみを考慮することである。自動車のホイール／タイヤの組み合わせは、本方法が大幅な量のレンダリングを節約することができる主要な例である。車両のホイール／タイヤは一般に、ホイールサイズ（１６インチ，１７インチ，１８インチなど）とタイヤ全体の直径との組のみである。この観察についての重要なことは、同じサイズのタイヤの輪郭は一致するということである。これは、マスキングの目的では、これらは同一であると考えられることを意味する。これが適用できるもう１つの場合は、構成要素が２つの異なる仕上げを有するが、同じ形状であるときである。例えば、フロントグリルが、アルミニウム及び光沢のあるクロムであってもよい。それが提供する形状、及びしたがってマスクは同一であるので、グリルの１つのみ又はホイール／タイヤの場合、それぞれのタイヤサイズについて１つのみを考慮することによって、相互的な閉塞における任意のオブジェクトが、それ自身を効果的にレンダリングする。この最適化をサンプルの車両構成に適用することによって、以下のレンダリングの数が得られる（ホイール／タイヤのマスキングが、３つのサイズのために７から３に変化する）。
【００５４】
最適化＃２のみの使用
ｂｔのレンダリング＝３６０＝２×３×３×２×１０（色）
ｗｈのレンダリング＝８４＝７×２×３×２
ｇｅのレンダリング＝３６０＝３×２×３×２×１０（色）
ｅｔのレンダリング＝３６＝２×２×３×３
ｓｐのレンダリング＝４０＝２×２×１０（色）
ｓｒのレンダリング＝４＝２×２
ａｎのレンダリング＝４＝２×２
−−−−−−−−−−−−−−−−−−−−−−−−−−
合計のレンダリング（着色後）＝８８８
【００５５】
これは、顕著な違いをもたらし、レンダリングの数を半分以上削減する。
【００５６】
最適化３：レンダリング後の色の変更．
第３の最適化は、車の塗装の着色を、レンダリング処理の後まで延期することを含む。色の変更は、２ｄレンダリングされた複数の画像上で、合成プログラムによって実行される。複数のフレームの単一のバージョンが、銀色などの一般的な色でレンダリングされる。これらの銀色のレンダリングはその後、車両が構成されるさまざまな色に変更される。この処理は、３ｄコンテンツ生成アプリケーションからそれぞれの色をレンダリングするよりも１桁速い。この速度の節約は、次節で２．５コンフィギュレータが考察されるときに、さらに組み合わせられる。
【００５７】
最適化＃２及び＃３の使用
ｂｔのレンダリング＝３６＝２×３×３×２
ｗｈのレンダリング＝８４＝７×２×３×２
ｇｅのレンダリング＝３６＝３×２×３×２
ｅｔのレンダリング＝３６＝２×２×３×３
ｓｐのレンダリング＝４＝２×２
ｓｒのレンダリング＝４＝２×２
ａｎのレンダリング＝４＝２×２
−−−−−−−−−−−−−−−−−−−−−−−−−−
合計のレンダリング（着色なし＊）＝２０４
＊色は後処理において後ほど追加される。
【００５８】
上述した技術、及び上記で開示された３つの最適化を用いると、あらゆる可能な構成を生成するほとんどの任意の２ｄコンフィギュレータを実行することが実用的である。しかしながら、複雑な構成のために、これらのコンフィギュレータを２．５ｄに変換することは、まだ非常に困難である。
【００５９】
２．５ｄにおける構成要素の分離．
構成要素の分離は、いくつかの問題を伴って２．５ｄに拡張される。当然、カメラの動きの複数のフレームにわたって２ｄの構成要素の分離のために説明されたように、複数のレイヤを簡単にレンダリングすることは意味をなす。残念ながら、そのような簡単な解決策は動作しない。問題は、相互的な閉塞、及びカメラの動きによって回転させられる複数の構成要素の相互作用に帰着する。例えば、最初のフレームでは、構成要素Ａが完全に構成要素Ｂの上にあると仮定する。その後、３６０度のカメラの動きにおけるより後のフレームでは、構成要素Ｂが今や完全に構成要素Ａの上にある。２ｄにおける相互的な閉塞の上述した例と同様に、このような深さ順序の変更は、相互的な閉塞として考慮される。相互的な閉塞は、複数の単一のフレームについてのみではなく、全体的なカメラの動きにわたってすべてのフレームについてチェックされるべきである。
【００６０】
２．５ｄにおける相互的な閉塞のユーザベースの推測は、すべての可能性についてほとんど不可能である。その代わり、与えられたカメラの動きにわたって相互的な閉塞のすべての場合を検出する特別なアプリケーション（閉塞プロセッサと呼ばれる。）が開示される。アプリケーションが動作するために、アプリケーションは、製品に関するカメラの動きについて、あらゆるフレームのあらゆるピクセルにおけるあらゆる構成要素の深さ情報、及び複数の構成についての基本的な情報にアクセスすることを要求する。深さ情報は、最終的な出力と同じ解像度で２ｄ画像において３２ビットの浮動小数点値として提供される。構成は、ｘｍｌファイルとして渡される。閉塞プロセッサは、両方を受け取り、相互的な閉塞行列を計算し、行列はその後、コンフィギュレータのマスキング処理を駆動するために用いられる。
【００６１】
閉塞プロセッサが、上記で用いられた例のコンフィギュレータ上で実行される場合、プロセッサは、２ｄコンフィギュレータにおいて発見された閉塞に加えて、サンルーフとアンテナとの間の相互的な閉塞が存在することも検出するであろう。以下に２．５ｄコンフィギュレータの相互的な閉塞の表を示す。
【００６２】
【表３】
【００６３】
ｓｒ及びａｎについてのフレームスタック上の相互的な閉塞は、表の右下の角における４つの箱のうちの２つにおいて、太字の“ｙ”として示される。
【００６４】
相互的な閉塞モデルを動作させること、及びそれを計算する方法によって、２ｄコンフィギュレータのために説明されたすべての技術をもとに２．５ｄコンフィギュレータを推測することができる。しかしながら、上述した３つの最適化が組み合わされても、いくつかの製品構成はまだ、非常に複雑であるので、２．５ｄに変換されたときに管理できなくなる。これらの場合を扱うために、最終的な最適化が開発された。
【００６５】
最適化４：レイヤの順序付け．
上述した技術は、任意のＺ方向の順序で組み立てられて、与えられた構成を生成することができるレンダリングを生成する。階層化のみの使用を試みることは、複数の構成要素の深さの相互作用によって失敗した。しかしながら、階層化とマスキングとの組み合わせは、任意の別の技術又は最適化よりも、はるかに多くレンダリングの数を減少させることができる。
【００６６】
基本的なアイデアは、複数の構成要素のカテゴリのために特有の階層化順序を定めることである。この特有のレイヤ順序を用いると、複数の構成要素のカテゴリが、レイヤ順序において下にある複数のカテゴリによってマスキングされることにのみ関係するべきであることから、要求されるマスキングが削減される。異なるレイヤ順序は、異なる結果を生成する。１つ又はグループのレイヤ順序は、最も少数の合計のフレームスタックを生成するであろう。この最適化された順序付けは、総当たり（brute force）技術を用いて簡単に計算される。
【００６７】
レイヤ順序の例１：
２．５ｄコンフィギュレータ
（レイヤ順序における）最適化＃２，＃３，及び＃４の使用：
７）ｓｐフレームスタック＝４＝２×２
６）ｓｒフレームスタック＝８＝２×２×２
５）ａｎフレームスタック＝４＝２×２
４）ｗｈフレームスタック＝８４＝７×２×３×２
３）ｅｔフレームスタック＝１２＝２×２×３
２）ｇｅフレームスタック＝６＝３×２
１）ｂｔフレームスタック＝２＝２
−−−−−−−−−−−−−−−−−−−−−−−−−−
合計のフレームスタック（着色なし）＝１２０
合計のレンダリングされたフレーム（着色なし）＝２８８０＝１２０×２４
【００６８】
レイヤ順序の例２：
２．５ｄコンフィギュレータ
（レイヤ順序における）最適化＃２，＃３，及び＃４の使用：
７）ｓｐフレームスタック＝４＝２×２
６）ｓｒフレームスタック＝８＝２×２×２
５）ａｎフレームスタック＝４＝２×２
４）ｇｅフレームスタック＝３６＝３×２×３×２
３）ｅｔフレームスタック＝１２＝２×２×３
２）ｗｈフレームスタック＝１４＝７×２
１）ｂｔフレームスタック＝２＝２
−−−−−−−−−−−−−−−−−−−−−−−−−−
合計のフレームスタック（着色なし）＝８０
合計のレンダリングされたフレーム（着色なし）＝１９２０＝８０×２４
【００６９】
これらの２つの例は、レイヤの順序付けがどのように合計のレンダリングの数に影響するかを示す。ホイール／タイヤをレイヤ４からレイヤ２に移動させて、地面効果と排気管の先端とを交換することによって、４０個のレンダリングが切り取られる。
【００７０】
要約すると、最後の３つの最適化を適用することによって、合計のレンダリングされるフレームの数は、３６，２８８，０００から１，９２０に削減される（最適化＃１を用いないことによって、我々はそれぞれの構成要素がそれ自身の色で表示される能力に言及し、また、色の変更は複数のフレームをレンダリングすることと比較して非常に速いため、ここでは色の変更は考慮されない。）。これは、処理をはるかに堅牢にし、最も複雑な製品コンフィギュレータのいくつかさえも取り扱うことができるようにする。さらに、複数の構成における順応的な変更（accommodating change）は、総当たり技術を用いる場合よりも、はるかに管理しやすくなる。
【００７１】
処理の概観．
車両の例についてのハイレベルな処理の概観では、すべてのトリムレベル及び可能なパーツにおける車両の複数の第１のデジタルモデルが生成され、まとめられる。その後、車両の製造業者から得られた構成情報は、データをモデルに添付するスクリプトに入力される。データは、カテゴリによって複数の構成要素に分解される。カメラの動きにわたってそれぞれの構成要素のＺ方向の深さのレンダリングが生成され、相互的な閉塞のすべての場合を検出する閉塞プロセッサに与えられる。このデータはその後、スクリプト／モデルのデータに返される。好ましい閉塞プロセッサは、手動の作業を不必要にするが、均一色（flat color）のレンダリングが生成され、最も少数の最終的なフレームスタックを生成する相互的な閉塞を出すために用いられる。その後、すべての車両の構成要素の最終的なレンダリングが、必要に応じて適用される一般的な銀色の車の塗装を用いて実行される。車の塗装を有する複数のフレームスタックは、車両が利用可能なすべての色に色変更される。すべてのフレームはその後、必要に応じて自動的に切り取られ、名前を変えられる。最後に、資産は、ユーザが車両を構成し、カメラの動きを通して車両を回転させることを可能にするアプリケーションに統合される。
【００７２】
処理の詳細．
要約すると、以下でより十分に詳述するように、複数の構成要素を有する製品のためのコンフィギュレータの処理は、
１）３ｄデータを複数の高次のパラメトリック曲面から複数の三角形メッシュにテッセレーションする（tessellating）ステップを含んでもよい、製品及び製品の複数の構成要素のための３ｄデータを収集しかつまとめるステップと、
２）詳細な構成情報を収集してどの構成要素の組み合わせが有効であるかを示すステップと、インタフェースを用いて詳細な構成情報をシーンファイルに入力しかつ記憶するステップと、複数の構成要素を複数の構成要素のカテゴリにまとめるステップと、複数の最終的なフレームスタックをレンダリングするステップと、色の複数のオプションを用いて合成ファイルを生成するステップと、３ｄマスクを複数の構成要素のそれぞれの部品の形状に関連付けるステップとを含んでもよい、製品の構成情報をセットアップするステップと、
３）Ｚ方向の深さの処理を用いて複数の相互的な閉塞を検出するステップと、複数の構成要素の間の複数の相互的な閉塞、及びどのフレームが複数の相互的な閉塞の検出をトリガしたかを詳述する行列を生成するステップと、コンフィギュレータスクリプトから閉塞プロセッサを用いて、閉塞プロセッサが閉塞情報を返し、結果を構成要素構成データベースに統合するステップとを含んでもよい、構成要素の相互的な閉塞を計算するステップと、
４）相互的な閉塞の複数のオプションを変更するステップ、又はレイヤ順序を変更しかつ複数のＺ方向の深さフレームを再処理するステップを含んでもよい、最適なレイヤ順序を決定するステップと、
５）相互作用によって製品の構成を変更することができるユーザのために、複数のフレームスタックをアプリケーションに統合するステップと、
６）ユーザの要求に応じて複数のフレームを動的にロードするステップとを含んでもよい。
【００７３】
構成情報／ＣＡＤデータ収集／データ準備．
コンフィギュレータの処理は、車両、車両のトリムレベル、及びすべてのオプションのパーツ及び付属品などの製品のための３ｄデータを収集すること／生成することから始まる。このデータは、三角形メッシュ、３ｄスキャンデータ、手でモデル化されたデータ、又は任意の別のタイプの３ｄデータにテッセレーションされる（tessellated）ＣＡＤデータであってもよい。車両は、単一の３ｄシーンファイルにデジタル的に組み立てられる。それぞれのトリムレベル、付属品、及びベース車両でさえも、それらをすばやくオフ及びオンすることを可能にする複数のレイヤによってシーンファイルにまとめられる。複数のレイヤのさまざまな状態をトグルすることは、それぞれの車両構成が再生される方法である。詳細な属性情報はまた、木目のパターン及び色のような材料の特質のマッチングに完全に適用される。
【００７４】
車両の構成情報のセットアップ．
モデルデータが収集される一方、詳細な構成情報も収集される。この情報は、トリムレベルのパッケージからオプションの付属品及び依存関係まで、最終的な車両においてどのパーツの組み合わせが有効であるかを示す。この情報は、具体的にはこの目的のために生成されたコンフィギュレータエディタアプリケーションに入力される。パーツは、複数の構成要素のカテゴリ（すなわち、“ホイール／タイヤ”、“地面効果”、“排気管の先端”）にまとめられる。それぞれの構成要素のカテゴリは、２つ又はそれ以上の構成要素（“１７インチの光沢のあるアルミニウムホイール”、“ＬＺＸ地面効果”、“二重のクロムの排気管の先端”）を有する。ユーザは、どの３ｄオブジェクトのレイヤがどの車両の構成要素に対応するかを指示する。すべての依存関係の情報がまた入力されて、この情報はシステムがどの組み合わせが有効で、どの組み合わせが有効でないか（すなわち、“１７インチの光沢のあるアルミニウムホイール”は、“ＬＸ”トリムレベルでは利用不可能である。）を決定することを可能にする。出力ファイルの名前をより読みやすくするために、別名が構成要素のカテゴリに与えられてもよい（“ホイール”が“ｗｈ”になってもよい。）。さらに、それぞれの部品の形状が、それに関連する３ｄデータのマスクを有するべきである。ほとんどの場合、これらのマスクは、形状そのものである。しかしながら、ホイール／タイヤのような特別な場合は、フレームスタックの数を減少させるために活用されてもよい。同じサイズのすべてのホイール／タイヤ（すなわち、１７インチの複数のホイール）は、同一のマスクデータを効果的に共有することができる。これは、ホイール／タイヤによってマスクされる任意のパーツは、すべてのホイール（４−１０種類のホイールが一般的である。）の代わりに、それぞれのホイール／タイヤのサイズ（標準装備として２−３種類のホイール／タイヤのサイズが一般的であるが、アフターマーケットでは、数百種類が利用可能である。）のためのマスクを用いてレンダリングされるだけでよいことを意味する。
【００７５】
複数のＺ方向の深さパスのレンダリング、及び相互的な閉塞の計算．
複数の構成要素が相互的な閉塞を示す場合を決定することが、処理における次のステップである。相互的な閉塞の場合を検出するために、カメラの動きにわたって３２ビットのＺ方向の深さフレームのレンダリングを処理し、かつ複数の構成要素の間で複数の相互的な閉塞が発生するすべての場合、及びどのフレーム又は複数のフレームが検出をトリガしたかを詳述する行列を生成するアプリケーションが開発された。プログラムは、それぞれの構成要素がカメラの動きにおけるそれぞれのフレームのためのレンダリングされた自分自身のＺ方向の深さを有することを必要とする。
【００７６】
コンフィギュレータエディタ及びアプリケーションインタフェースは、ユーザが、相互的な閉塞の処理のために必要とされるすべてのＺ方向の深さレンダリングを生成する、レンダリングのジョブのバッチを投入する（submit）ことを可能にするようにセットアップされる。すべてのレイヤが一度に送信されてもよく、又は個別の複数のレイヤが一度に１つ送信されてもよい。
【００７７】
複数のＺ方向の深さフレームが仕上げられると、閉塞プロセッサは、コンフィギュレータエディタから開始されてもよい。プロセッサは、すべての閉塞情報を返し、結果を構成要素構成データベースに統合する。
【００７８】
Ｚ方向の深さ方法の代替となる方法は、相互的な閉塞行列を手動で決定することである。これを実行する１つの簡単な方法は、低い品質のレンダリングの設定で、均一色でそれぞれの構成要素をレンダリングすることである。これら均一色のレンダリングはその後、手動の相互的な閉塞のテストのために、合成ソフトウェアにインポートされる。複数の構成要素は互いの上に階層化され、複数のフレームスタックは、カメラの動きを通して、どの構成要素が互いに影響するかをテストするために循環される。この手動の方法は、オペレータに責任を課すので好ましくなく、複数のフレームをレンダリングして組み立てる処理は、高度にパイプライン化されているので、誤った閉塞の決定の結果は、気付くためにはしばらく時間がかかる。オペレータが相互的な閉塞行列を誤った場合、これは、コンフィギュレータの処理をレンダリングのステップから再起動させる複数のフレームの再レンダリングを余儀なくさせる。
【００７９】
最適なレイヤ順序の決定．
複数の構成要素のカテゴリのための最適な階層化順序を決定することは、フレームスタックの数を最小に維持するために重要である。それぞれの可能なレイヤ順序についてフレームスタックの数をチェックする総当たり技術を用いて、最適なレイヤ順序をプログラムで決定することができる。レイヤの数が７又は８を越えると、この総当たり方法は長時間かかることがある。オペレータが、どれがよいレイヤ順序かについて知識に基づく推測を実行し、コンフィギュレータエディタにその順序についてのフレームスタックの数を計算させることがより速いこともある。オペレータはその後、元の順序と比較するために、別のレイヤ順序を試み、フレームスタックの数を計算してもよい。通常、製品の３ｄ表現をよく理解しているオペレータは、どのレイヤ順序であるべきかについてよい推測をすることができ、その後、それを絞り込んで、少数の異なるオプションをテストすることができる。オペレータがレイヤ順序についてこのような判断ができないときは、構成が簡単な場合、又は時間が制約されない場合には、総当たり技術が用いられてもよい。総当たりがオプションではない場合、合理的なフレームスタックの数を生成する任意のレイヤ順序が、実行可能なオプションである。本明細書で上述したように、いくつかのレイヤ順序が別のものよりもより多くのフレームスタックを生成する事実以外に、任意の与えられたレイヤ順序が用いられない技術的な理由はない。
【００８０】
均一色のレンダリングは、スキップされてもよいオプションであるが、このバリエーションでは、ユーザは、（コンフィギュレータスクリプトを再び用いて）非常に低い品質のレンダリングの設定で、構成要素自身の均一色でそれぞれの構成要素のレンダリングを開始して、レンダリングの時間を短く維持する。これらの均一色のレンダリングはその後、レイヤ順序のテスト、及び最終的な相互的な閉塞のテストのために、合成ソフトウェアにインポートされる（閉塞プロセッサは正確すぎることもあり、スポイラーの取り付け箇所などのメッシュにおける小さな穴に起因する相互的な閉塞の場合を検出するであろう。このような場合、オペレータは、どのカテゴリが互いに相互的な閉塞状態であるかについて、最終的な指示をするべきである。）。複数のレイヤの順序は、すべての有効なコンフィギュレータの組み合わせを生成するために必要なレンダリングの合計の数に大きな効果を有するので、オペレータはこのステップでは注意すべきである。閉塞プロセッサのバージョンは、小さい針穴のようなものが誤検出（false positives）を生成しないように、割合に基づいて動作するように設計される。さらに、閉塞プロセッサがより正確に相互的な閉塞を決定することができると、プロセッサはまた、最適なレイヤ順序を決定することができるであろう。ユーザが、最適なレイヤスタックの順序を決定すると、この情報は、コンフィギュレータスクリプトに入力し戻される。
【００８１】
複数の最終的なフレームスタックのレンダリング．
入力された構成情報を用いて、コンフィギュレータスクリプトは、適切にマスクされた複数の構成要素のレンダリングを生成することができる。レンダリングは、構成エディタからバッチで又は一度に１つ起動される。
【００８２】
分解シート（breakdown sheet）の命名．
データシートは、シーンファイルで必要とされるものよりもより詳細にコンフィギュレータ内に存在する複数の構成要素のそれぞれを分解するコンフィギュレータエディタから生成される。これは、パーツの実名、マスクｉｄ、構成要素が塗装されているか否か、閉塞の別名、レイヤ順序などのそれぞれの構成要素のための追加の情報を含む。また、塗装色のコード及び名前についての情報が、これに含まれてもよい。製品の製造業者は、最終的な提供品（deliverables）を決定する処理の一部として、分解シートを承認するべきである。
【００８３】
合成ファイルの構築．
塗装された車両の複数の構成要素をさまざまな色に色変更することは、２ｄ合成ソフトウェアにおいて実行される。専門化されたプラグインは、表面法線（surface normal）、反射、屈折などのデータを含む特別なレンダリングエレメントのバッファを用いて車の塗装のシェーダを再生するために利用される。これは、美術担当者がそれぞれのレンダリングエレメントの組み合わせを個別に微調整すること、及び２ｄの間にベース色を変更することを可能にする。一般に、ベースの銀色の車の塗装は、車両がどの色で利用可能であるかに依存して、５種類から１５種類程度の異なる色に変更される。合成スクリプト／ファイルは、生成されたすべてのレンダリングが、スクリプトに自動的に読み込まれ、かつ正しい経路（path）に書き出されるように、構成エディタによって生成される。多数のフレームスタックのためのすべてのリードノード（read node）及びライトノード（write node）をセットアップする処理は、手で実行すると手ごわくかつエラーが発生しやすいタスクであるので、このステップはオートメーションにおいて用いられる。いくつかの場合では、すべてのフレームスタックのために単一の合成ファイルを生成することは意味をなすが、一方、別の場合では、合成ファイルを別々のスクリプトファイルに分解することが意味をなす。
【００８４】
自動切り取りオプション．
ファイルサイズを減少させるために、すべての画像が、最終的なウェブアプリケーションにおいて、それらを簡単に利用可能にする方法で、構成要素のカテゴリによって自動的に切り取られる。自動的な切り取りは、ジョブを投入するための開始アプリケーション（kick-off application）を用いるレンダラ上で実行される。切り取りは、構成ファイルによって直接的に駆動される。
【００８５】
資産の名前変更オプション．
処理におけるより初期のステップによって生成された名前は、最終的なウェブアプリケーションにおいて使用するには適切でないことがあり、特に、パーツの番号、又はいくつかの別の命名規則に基づいて構成情報を提供する外部のデータサービスとの統合を試みるときに適切でないことがある。すべての資産をウェブアプリケーションによって要求される任意のフォーマットに名前を変更することを可能にする堅牢な名前変更処理が統合されている。名前変更のステップは、構成ファイルによって再び駆動される。これは、パーツの名前が、車両の色に基づいて変化する場合（これは、パーツが制限された数の色に塗装される直前である、又は事前に塗装されているときに発生する。）にも順応する。
【００８６】
最終的なウェブアプリケーション．
コンフィギュレータの処理の最後の部分は、ユーザが、マウスの相互作用又は別の入力デバイスを用いて、製品、すなわち車両を“回転させる”ことを可能にするアプリケーションに、複数のフレームスタックを統合することを含む。アプリケーションは、ユーザが製品の構成を変更するというような要求に応じて、レイヤ順序及び相互的な閉塞情報に基づいて、複数のフレームを動的にロードしなければならない。このようなユーザインタフェースは、ユーザの入力ごとに要求に応じて複数のレイヤを組み立てる２．５ｄビューアとなることができる。
【００８７】
論理．
すべてのレイヤがレンダリングされると、それらのレイヤは、さまざまな方法によって製品の正確な表現に組み立てられる。これは、典型的に、どのように部品が組み合わされるかに関連した論理を考慮するプログラムによって達成される。この論理は、レイヤの数又はフレームの数が、数個から数十万個に増加するにつれて、ますます重要になる。
【００８８】
これらの製品の組み合わせがどのように組み立てられるかに関連した論理は、典型的に、組み立てガイドを介して、又は製品に関する人間の知識に基づいて、製造業者によって提供される。さらに、論理をさらに定義する独特なパッケージに組み合わされるいくつかの構成要素が存在してもよい。
【００８９】
製品の構成は、典型的に、複数のレイヤ及び複数のフレームへのローカルインタフェースを介し、スタンドアロンコンピュータ又はインターネットを経由し、ウェブブラウザ又はアプリケーションを介してユーザに提供される。
【００９０】
すべてのレイヤを構成された製品画像に組み立てる能力は、階層化方法によって生成されたさまざまなレイヤに関連する論理を必要とする。複数のレイヤにリンクされた論理の正確さは、レイヤの数が増加するにつれて、ますます重要になる。これは、生産され得ない不正確な構成又は製品を防止する。
【００９１】
レイヤの数が増加するにつれて、組み立て処理を自動化する必要性が、ヒューマンエラーを防止するために必要になる。これは、典型的に、製造業者の組み立てドキュメントを介して、手動で論理にリンクされる複数のレイヤの命名規則を用いて取り扱われる。このリンクが確立されると、組み立てプログラムは、要求された複数のレイヤに、ユーザへ構成を提示するように命じることができる。これまで、論理と複数のフレームの命名とのリンクは、解決するために追加の資源を必要とするエラーを常に生成する手動の人間の介在を必要としていた。さらに、製品の複数のオプションにおける任意の変更、又は製品の設計の変更は、複雑性及び更新のためのコストをさらに追加する構成ファイルが再プログラムされることを要求することがある。
【００９２】
本明細書で概説されたアプローチは、リンクすること及び論理を複数のレイヤの生成フェーズに移動し、それによって、簡単なプログラムによって利用されて、視覚的なインタフェースにおいて複数のレイヤ及び複数のフレームを組み立てることができる構成論理ファイルを自動的に生成する。レンダリングのときに構成ファイルを生成することによって、製品の組み立て論理を複数の画像に手動でリンクする必要性が削除される。それによって、構成処理における手動のステップを削除する。
【００９３】
製造業者の組み立て論理に基づいて製品の複数の３ｄファイルをまとめること、及び本明細書で定義した階層化方法を用いることによって、製品論理が、複数の３ｄファイルが複数の構成の複数の製品画像を生成するためにどのように利用されるかを自動的に決定する一方、最適化処理によって全体の画像を減少させる。複数の画像がレンダリングされるときに、複数の画像がどのように構成された製品の正確な表現に組み立てられるかを決定する構成文書が生成される。構成文書の自動生成は、構成を表示することの全体の処理を簡単化する鍵である。
【００９４】
設計の変更は、製品のライフサイクルを通じて行われるので、更新された画像が新しい構成ファイルとともに生成されて、長期間の効果をさらに高める新しい構成エンジンをサポートする最新の状態に、複数の３ｄファイルが保たれることが望ましい。
【００９５】
本開示は、例示的な実施形態を用いて説明され、その一般的な原理を用いて任意のバリエーション、使用、又は適応を含むことを意図している。当業者は、以下の特許請求の範囲に列挙される本開示の精神及び範囲から逸脱することなく、さまざまな修正及び同等物を工夫することができると想像される。さらに、本開示は、それに付属する当業者の既知の又は通例の慣習であるように、本開示からのこのようなバリエーションを含むことを意図している。
【特許請求の範囲】
【請求項１】
構成可能な複数の構成要素を有する製品の複数の画像を生成するコンフィギュレータにおいて、
最適化されたレイヤ順序とともに用いられるマスキングを有する画像階層化方法を含み、
上記構成可能な複数の構成要素の相互的な閉塞の場合を検出する閉塞プロセッサを含むコンフィギュレータ。
【請求項２】
上記コンフィギュレータは、複数の画像の複数のレイヤが生成されるときに製品構成の論理を生成し、それによって、上記論理を上記複数のレイヤに自動的にリンクする請求項１記載のコンフィギュレータ。
【請求項３】
ユーザの入力に基づいて複数の画像の複数のレイヤを組み立てるビューアをさらに含む請求項１記載のコンフィギュレータ。
【請求項４】
上記リンクすること及び論理を上記複数のレイヤの上記生成フェーズに移動し、それによって、簡単なプログラムによって利用されて、視覚的なインタフェースのために上記複数のレイヤを組み立てる構成論理ファイルをレンダリングにおいて自動的に生成する組み立て処理を含む請求項１記載のコンフィギュレータ。
【請求項５】
上記画像階層化方法は、すべての単一の組み合わせのために完全な製品の画像をレンダリングする必要性を防止し、
最も一般的なファクタは、１つのレイヤ上でレンダリングされる一方、最も一般的ではない複数のファクタは、別々の複数のレイヤ上でレンダリングされる請求項１記載のコンフィギュレータ。
【請求項６】
画像階層化方法を有して複数の製品の複数の構成をサポートする、コンピュータで生成された画像のためのコンフィギュレータにおいて、
論理に基づいて多数の組み合わせに組み立てられる複数の３次元モデルから、上記階層化方法で複数の２次元画像を生成する手段と、
複数のＺ方向の深さパスをレンダリングする手段と、
上記複数のＺ方向の深さパスから、相互的な閉塞の場合を検出する閉塞プロセッサと、
最適なレイヤの順序付けを決定する手段と、
複数の最終的なフレームをレンダリングするアプリケーションと、
合成スクリプトを生成する手段とを含むコンフィギュレータ。
【請求項７】
上記画像階層化方法は、すべての単一の組み合わせのために完全な製品の画像をレンダリングする必要性を防止し、
最も一般的なファクタは、１つのレイヤ上でレンダリングされる一方、最も一般的ではない複数のファクタは、別々の複数のレイヤ上でレンダリングされる請求項６記載のコンフィギュレータ。
【請求項８】
レイヤを順序付けかつマスキングするステップと、
複数の構成要素のＺ方向の深さを用いて階層化を最適化するステップと、
複数の画像の複数のレイヤが生成されるときに、製品構成の時点で論理を生成するステップとを含み、
画像を階層化する方法を用いて、構成可能な複数の構成要素を有する製品を２次元における上記製品の複数のマルチアングル画像のために構成する処理。
【請求項９】
上記製品構成ファイルを生成する時点で論理を生成するステップは、論理を複数の画像の複数のレイヤに自動的にリンクする請求項８記載の処理。
【請求項１０】
複数の画像の複数のレイヤが生成されるとき、上記リンクすること及び論理は、簡単なプログラムによって利用されて、視覚的なインタフェースのために上記複数のレイヤを組み立てる構成論理ファイルを自動的に生成する請求項８記載の処理。
【請求項１１】
上記製品の複数の３次元ファイルをまとめて、上記最も一般的な及び最も一般的ではない複数のファクタを決定する追加のステップを含み、
論理は、上記複数の３次元ファイルがどのように複数の製品画像を生成することができるかを自動的に決定する請求項８記載の処理。
【請求項１２】
複数の画像をレンダリングし、同時に、どのように複数の画像が構成された上記製品の正確な表現に組み立てられるかを決定する構成文書を生成するステップを含む請求項８記載の処理。
【請求項１３】
複数の構成要素を有する製品のためのコンフィギュレータの処理において、
上記製品及び上記製品の複数の構成要素のための３次元データを収集しかつまとめるステップと、
３次元マスクを上記複数の構成要素のそれぞれの部品の形状に関連付けるステップを含み、製品の構成情報をセットアップするステップと、
上記複数の構成要素の相互的な閉塞を計算するステップと、
最適なレイヤ順序を決定するステップと、
相互作用によって上記製品の構成を変更することができるユーザのために、複数のフレームスタックをアプリケーションに統合するステップと、
上記ユーザの要求に応じて複数のフレームを動的にロードするステップとを含むコンフィギュレータの処理。
【請求項１４】
上記３次元データを収集しかつまとめるステップは、上記３次元データを複数の高次のパラメトリック曲面から複数の三角形メッシュにテッセレーションするステップを含む請求項１３記載のコンフィギュレータの処理。
【請求項１５】
上記製品の構成情報をセットアップするステップはさらに、
詳細な構成情報を収集して、どの構成要素の組み合わせが有効であるかを示すステップと、
インタフェースを用いて詳細な構成情報をシーンファイルに入力しかつ記憶するステップと、
複数の構成要素を複数の構成要素のカテゴリにまとめるステップと、
複数の最終的なフレームスタックをレンダリングするステップと、
合成ファイルを生成するステップとを含む請求項１３記載のコンフィギュレータの処理。
【請求項１６】
上記相互的な閉塞を計算するステップは、
Ｚ方向の深さの処理を用いて複数の相互的な閉塞を検出するステップと、
複数の構成要素の間の複数の相互的な閉塞、及びどのフレームが複数の相互的な閉塞の検出をトリガしたかを詳述する行列を生成するステップと、
コンフィギュレータスクリプトから閉塞プロセッサを用いて、上記閉塞プロセッサが閉塞情報を返し、結果を構成要素構成データベースに統合するステップとを含む請求項１３記載のコンフィギュレータの処理。
【請求項１７】
上記最適なレイヤ順序を決定するステップは、相互的な閉塞の複数のオプションを変更するステップを含む請求項１３記載のコンフィギュレータの処理。
【請求項１８】
上記最適なレイヤ順序を決定するステップは、レイヤ順序を変更しかつ複数のＺ方向の深さフレームを再処理するステップを含む請求項１３記載のコンフィギュレータの処理。
【請求項１９】
上記合成ファイルを構築するステップは、２次元合成ソフトウェアを用いて、着色された複数の構成要素をさまざまな色に色変更し、色を有する構成要素の複数のフレームスタックを処理するステップを含む請求項１３記載のコンフィギュレータの処理。
【請求項２０】
上記ユーザは、ウェブインタフェース上の相互作用を用いて、異なるビューを見せる上記製品を回転させる請求項１３記載のコンフィギュレータの処理。
【請求項１】
構成可能な複数の構成要素を有する製品の複数の画像を生成するコンフィギュレータにおいて、
最適化されたレイヤ順序とともに用いられるマスキングを有する画像階層化方法を含み、
上記構成可能な複数の構成要素の相互的な閉塞の場合を検出する閉塞プロセッサを含むコンフィギュレータ。
【請求項２】
上記コンフィギュレータは、複数の画像の複数のレイヤが生成されるときに製品構成の論理を生成し、それによって、上記論理を上記複数のレイヤに自動的にリンクする請求項１記載のコンフィギュレータ。
【請求項３】
ユーザの入力に基づいて複数の画像の複数のレイヤを組み立てるビューアをさらに含む請求項１記載のコンフィギュレータ。
【請求項４】
上記リンクすること及び論理を上記複数のレイヤの上記生成フェーズに移動し、それによって、簡単なプログラムによって利用されて、視覚的なインタフェースのために上記複数のレイヤを組み立てる構成論理ファイルをレンダリングにおいて自動的に生成する組み立て処理を含む請求項１記載のコンフィギュレータ。
【請求項５】
上記画像階層化方法は、すべての単一の組み合わせのために完全な製品の画像をレンダリングする必要性を防止し、
最も一般的なファクタは、１つのレイヤ上でレンダリングされる一方、最も一般的ではない複数のファクタは、別々の複数のレイヤ上でレンダリングされる請求項１記載のコンフィギュレータ。
【請求項６】
画像階層化方法を有して複数の製品の複数の構成をサポートする、コンピュータで生成された画像のためのコンフィギュレータにおいて、
論理に基づいて多数の組み合わせに組み立てられる複数の３次元モデルから、上記階層化方法で複数の２次元画像を生成する手段と、
複数のＺ方向の深さパスをレンダリングする手段と、
上記複数のＺ方向の深さパスから、相互的な閉塞の場合を検出する閉塞プロセッサと、
最適なレイヤの順序付けを決定する手段と、
複数の最終的なフレームをレンダリングするアプリケーションと、
合成スクリプトを生成する手段とを含むコンフィギュレータ。
【請求項７】
上記画像階層化方法は、すべての単一の組み合わせのために完全な製品の画像をレンダリングする必要性を防止し、
最も一般的なファクタは、１つのレイヤ上でレンダリングされる一方、最も一般的ではない複数のファクタは、別々の複数のレイヤ上でレンダリングされる請求項６記載のコンフィギュレータ。
【請求項８】
レイヤを順序付けかつマスキングするステップと、
複数の構成要素のＺ方向の深さを用いて階層化を最適化するステップと、
複数の画像の複数のレイヤが生成されるときに、製品構成の時点で論理を生成するステップとを含み、
画像を階層化する方法を用いて、構成可能な複数の構成要素を有する製品を２次元における上記製品の複数のマルチアングル画像のために構成する処理。
【請求項９】
上記製品構成ファイルを生成する時点で論理を生成するステップは、論理を複数の画像の複数のレイヤに自動的にリンクする請求項８記載の処理。
【請求項１０】
複数の画像の複数のレイヤが生成されるとき、上記リンクすること及び論理は、簡単なプログラムによって利用されて、視覚的なインタフェースのために上記複数のレイヤを組み立てる構成論理ファイルを自動的に生成する請求項８記載の処理。
【請求項１１】
上記製品の複数の３次元ファイルをまとめて、上記最も一般的な及び最も一般的ではない複数のファクタを決定する追加のステップを含み、
論理は、上記複数の３次元ファイルがどのように複数の製品画像を生成することができるかを自動的に決定する請求項８記載の処理。
【請求項１２】
複数の画像をレンダリングし、同時に、どのように複数の画像が構成された上記製品の正確な表現に組み立てられるかを決定する構成文書を生成するステップを含む請求項８記載の処理。
【請求項１３】
複数の構成要素を有する製品のためのコンフィギュレータの処理において、
上記製品及び上記製品の複数の構成要素のための３次元データを収集しかつまとめるステップと、
３次元マスクを上記複数の構成要素のそれぞれの部品の形状に関連付けるステップを含み、製品の構成情報をセットアップするステップと、
上記複数の構成要素の相互的な閉塞を計算するステップと、
最適なレイヤ順序を決定するステップと、
相互作用によって上記製品の構成を変更することができるユーザのために、複数のフレームスタックをアプリケーションに統合するステップと、
上記ユーザの要求に応じて複数のフレームを動的にロードするステップとを含むコンフィギュレータの処理。
【請求項１４】
上記３次元データを収集しかつまとめるステップは、上記３次元データを複数の高次のパラメトリック曲面から複数の三角形メッシュにテッセレーションするステップを含む請求項１３記載のコンフィギュレータの処理。
【請求項１５】
上記製品の構成情報をセットアップするステップはさらに、
詳細な構成情報を収集して、どの構成要素の組み合わせが有効であるかを示すステップと、
インタフェースを用いて詳細な構成情報をシーンファイルに入力しかつ記憶するステップと、
複数の構成要素を複数の構成要素のカテゴリにまとめるステップと、
複数の最終的なフレームスタックをレンダリングするステップと、
合成ファイルを生成するステップとを含む請求項１３記載のコンフィギュレータの処理。
【請求項１６】
上記相互的な閉塞を計算するステップは、
Ｚ方向の深さの処理を用いて複数の相互的な閉塞を検出するステップと、
複数の構成要素の間の複数の相互的な閉塞、及びどのフレームが複数の相互的な閉塞の検出をトリガしたかを詳述する行列を生成するステップと、
コンフィギュレータスクリプトから閉塞プロセッサを用いて、上記閉塞プロセッサが閉塞情報を返し、結果を構成要素構成データベースに統合するステップとを含む請求項１３記載のコンフィギュレータの処理。
【請求項１７】
上記最適なレイヤ順序を決定するステップは、相互的な閉塞の複数のオプションを変更するステップを含む請求項１３記載のコンフィギュレータの処理。
【請求項１８】
上記最適なレイヤ順序を決定するステップは、レイヤ順序を変更しかつ複数のＺ方向の深さフレームを再処理するステップを含む請求項１３記載のコンフィギュレータの処理。
【請求項１９】
上記合成ファイルを構築するステップは、２次元合成ソフトウェアを用いて、着色された複数の構成要素をさまざまな色に色変更し、色を有する構成要素の複数のフレームスタックを処理するステップを含む請求項１３記載のコンフィギュレータの処理。
【請求項２０】
上記ユーザは、ウェブインタフェース上の相互作用を用いて、異なるビューを見せる上記製品を回転させる請求項１３記載のコンフィギュレータの処理。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１０−７３２０７（Ｐ２０１０−７３２０７Ａ）
【公開日】平成２２年４月２日（２０１０．４．２）
【国際特許分類】
【外国語出願】
【出願番号】特願２００９−２１４５１４（Ｐ２００９−２１４５１４）
【出願日】平成２１年９月１６日（２００９．９．１６）
【出願人】（５０９２５９９９８）スピードシェイプ・インコーポレイテッド (1)
【氏名又は名称原語表記】Ｓｐｅｅｄｓｈａｐｅ， Ｉｎｃ．
【Ｆターム（参考）】
【公開日】平成２２年４月２日（２０１０．４．２）
【国際特許分類】
【出願番号】特願２００９−２１４５１４（Ｐ２００９−２１４５１４）
【出願日】平成２１年９月１６日（２００９．９．１６）
【出願人】（５０９２５９９９８）スピードシェイプ・インコーポレイテッド (1)
【氏名又は名称原語表記】Ｓｐｅｅｄｓｈａｐｅ， Ｉｎｃ．
【Ｆターム（参考）】
[ Back to top ]