JP2018170588A - モデルデータ配信サーバおよびモデルデータ受信クライアント - Google Patents

Abstract

【課題】サーバクライアント型のシステムにおいて、物体の形状を表すモデルデータの送受および画像処理におけるセキュリティ強度の向上を図る。【解決手段】サーバ２は、エンコード処理部２ｂと、デコードプログラム生成部２ｃと、データ送信部２ｄとを有する。エンコード処理部２ｂは、物体の形状を表すモデルデータをエンコードすることによって、エンコードモデルデータを生成する。デコードプログラム生成部２ｃは、エンコードモデルデータをデコードする処理手順を指示する一連の命令群によって構成され、かつ、クライアント側において、中央処理装置とは別に設けられた画像処理部によって実行されるデコードプログラムを生成する。データ送信部２ｄは、エンコードモデルデータと、デコードプログラムとをクライアントに送信する。【選択図】図２

Description

本発明は、物体の形状を表すモデルデータの送受を行うサーバおよびクライアントに関する。

例えば、特許文献１には、ＣＰＵ（メインプロセッサ装置）と、ＧＰＵ（サブプロセッサ装置）とを備えたデータ処理システムにおいて、暗号化された画像データを復号する際のセキュリティ強度を高める構成が開示されている。具体的には、ＣＰＵは、暗号化された画像データを復号することなく、ＧＰＵに転送する。ＧＰＵは、暗号化された画像データを内部メモリ（デバイスメモリ）上に展開した上で、復号、デコード、表示などの処理を行う。暗号化された画像データは、ＧＰＵの内部で処理されるため、復号された画像データがＣＰＵのメモリ上に展開されることはない。これにより、メモリダンプ等によって復号された画像データが取得されることを防止できるので、セキュリティ強度が向上する。

特開２０１２−１５１６４２号公報

特許文献１は、サーバクライアント型ではなくスタンドアロン型のシステムに関するものであって、サーバおよびクライアント間におけるデータの送受については記載されておらず、また、暗号化された画像データの復号処理についての詳細も記載されていない。

本発明の目的は、サーバクライアント型のシステムにおいて、物体の形状を表すモデルデータの送受および画像処理におけるセキュリティ強度の向上を図ることである。

かかる課題を解決すべく、第１の発明は、エンコード処理部と、デコードプログラム生成部と、データ送信部とを有するモデルデータ配信サーバを提供する。エンコード処理部は、物体の形状を表すモデルデータをエンコードすることによって、エンコードモデルデータを生成する。デコードプログラム生成部は、エンコードモデルデータをデコードする処理手順を指示する一連の命令群によって構成され、かつ、クライアント側において、中央処理装置とは別に設けられた画像処理部によって実行されるデコードプログラムを生成する。データ送信部は、エンコードモデルデータと、デコードプログラムとをクライアントに送信する。

ここで、第１の発明において、上記エンコード処理部は、モデルデータの配信毎に異なる処理でモデルデータをエンコードし、上記デコードプログラム生成部は、配信対象毎に処理内容が異なるデコードプログラムを生成することが好ましい。また、上記デコードプログラムは、画像処理部によって実行されるシェーダプログラムであることが好ましい。

第２の発明は、データ受信部と、画像処理部とを有するモデルデータ受信クライアントを提供する。データ受信部は、物体の形状を表すモデルデータをエンコードしたエンコードモデルデータと、エンコードモデルデータをデコードする処理手順を指示する一連の命令群によって構成されたデコードプログラムとを、サーバより受信する。画像処理部は、中央処理装置とは別に設けられていると共に、画像を表示する際、デコードプログラムを実行することによって、エンコードモデルデータをデコードして画像を生成する。

ここで、第２の発明において、上記デコードプログラムは、サーバより配信されるモデルデータの配信対象毎に処理内容が異なることが好ましい。また、上記デコードプログラムは、画像処理部によって実行されるシェーダプログラムであることが好ましい。

本発明によれば、サーバとクライアントとの間におけるモデルデータの送受を、モデルデータをエンコードしたエンコードモデルデータの形で行うことで、第三者による盗聴や改ざんを防止できる。また、クライアント側におけるエンコードモデルデータのデコードは、画像を表示する際、中央処理装置とは別に設けられた画像処理部がデコードプログラムを実行することによって行われる。ネットワーク上やメインメモリ上にデコード済のモデルデータを配置せず、モデルデータを表示する際（描画時）、その都度デコードすることで、セキュリティ強度の向上を図ることができる。

サーバクライアント型システムの全体図 サーバのブロック図 モデルデータのエンコードの一例を示す図 デコードプログラムの一例を示すフローチャート クライアントのブロック図 ＧＰＵにおける画像処理の流れの説明図

図１は、本実施形態に係るサーバクライアント型システムの全体図である。このシステム１は、モデルデータを配信するサーバ２と、モデルデータを受信可能な多数のクライアント３とがインターネットを介して接続されている。サーバ２は、クライアント３からの要求に応じて、配信データとして、エンコード処理が施されたモデルデータ（以下、エンコードモデルデータという。）と、このエンコードデータをデコードするためのデコードプログラムとを配信する。本実施形態の特徴は、モデルデータをそのまま配信するのではなく、モデルデータにエンコード処理を施して内容を特定困難な形（エンコードモデルデータ）で配信することにある。この場合、エンコードモデルデータを受信したクライアント３は、そのままでは有意なデータを復元できないので、この復元を可能にすべく、サーバ２からクライアント３にデコードプログラムが渡される。配信データを受信したクライアント３は、画像の表示に際して、エンコードモデルデータをデコードプログラムによって復元して画像を生成し、この画像を表示する。

ここで、「モデルデータ」とは、物体の形状を表すデータであって、二次元データ、三次元データのいずれであってもよい。三次元データは、三次元ＣＡＤデータ（ファイルの拡張子としては、ＩＧＥＳ、ＳＴＥＰ、ＰＡＲＡＳＯＬＩＤ、ＳＡＴ、ＪＴ、ＶＤＡなど）であってもよいし、３ＤＣＧ（三次元コンピュータグラフィックス）データや、三次元の表面形状を多数の点で表現した点群データであってもよい。また、「デコードプログラム」とは、エンコードモデルデータをデコードするためのプログラムであって、エンコードモデルデータをデコードする処理手順を指示する一連の命令群によって構成されている。この「デコードプログラム」は、クライアント側において、中央処理装置とは別に設けられた画像処理部（典型的には、グラフィックス・プロセッシング・ユニット（以下、ＧＰＵという。））によって実行される

なお、エンコードモデルデータおよびデコードプログラムの配信は、同時に行ってもよいが、セキュリティ強度の向上を図るべく、別個に配信してもよいし、所定のサイトにアクセスすることによって別ルートで入手するようにしてもよい。さらに、本実施形態に係るモデルデータの配信方法とともに、ユーザ認証や公開鍵暗号などといった周知のセキュリティ強化手法を併用すれば、データの送受におけるセキュリティの一層の強化を図ることができる。

図２は、サーバ２のブロック図である。このサーバ２は、データ要求受信部２ａと、エンコード処理部２ｂと、デコードプログラム生成部２ｃと、データ送信部２ｄと、モデルデータ格納部２ｅとを主体に構成されている。

データ要求受信部２ａは、指定したモデルデータを取得する旨の要求をクライアント３から受信する。エンコード処理部２ｂは、モデルデータ格納部２ｅを参照して、クライアント３によって指定されたモデルデータを配信対象として取得する。そして、エンコード処理部２ｂは、配信対象となるモデルデータをエンコードプログラムを用いてエンコードすることによって、エンコードモデルデータを生成する。

デコードプログラム生成部２ｃは、エンコード処理部２ｂからの指示を受けて、配信対象となるエンコードモデルデータをデコードするためのデコードプログラムを生成する。このデコードプログラムは、配信対象に対して適用されたエンコードプログラムとは逆の処理を行うものであり、エンコードプログラムが配信対象毎に異なる場合には、デコードプログラムも配信対象毎に固有のものとなる。データ送信部２ｄは、エンコード処理部２ｂによって生成されたエンコードモデルデータと、デコードプログラム生成部２ｃによって生成されたデコードプログラムとをクライアント３に送信する。

図３は、モデルデータのエンコードの一例を示す図である。例えば、モデルデータが三次元座標よりなる多数の頂点Ｖによって構成されている場合、最もシンプルな例として、所定のエンコード規則にしたがって、Ｘ座標、Ｙ座標、Ｚ座標を入れ替えるスクランブルが考えられる。同図の例では、奇数番目の頂点Ｖ2n-1（ｎは自然数）については、Ｘ座標をＺ座標に、Ｙ座標をＸ座標に、Ｚ座標とＹ座標にそれぞれ入れ替え、偶数番目の頂点Ｖ2nについては、Ｘ座標をＹ座標に、Ｙ座標をＺ座標に、Ｚ座標をX座標にそれぞれ入れ替えている。また、座標値の入れ替えに代えて、頂点Ｖ同士を入れ替えてもよい。このようなエンコード処理を行うことで、有意なモデルデータは有意でないデータに変換される。ただし、これは一例であって、クライアント３側の画像処理部で演算可能な形態であれば、スクランブルに限らず、どのようなエンコード手法を用いてもよいことに留意すべきである。

図４は、図３に示したエンコードに対応するデコードプログラムの一例を示すフローチャートである。このデコードプログラムは、配信対象となるエンコードモデルデータをデコードする処理手順を指示する一連の命令群によって構成されている。詳細については後述するが、本実施形態では、クライアント３側の画像処理部（例えばプログラマブルシェーダ）によって実行されるシェーダプログラムをデコードプログラムとして用いる。同図の例は、シェーダプログラムとして、頂点の座標変換方法を規定した頂点シェーダプログラムを用いるケースを示している。

まず、ステップ１において、頂点フォーマットが定義される。つぎに、ステップ２において、どんな頂点情報を扱うのかをシェーダに教えるため、頂点シェーダで扱う頂点データが宣言される。

ステップ３以降は、シェーダプログラムの実体部分である。ステップ３において、頂点シェーダプログラムを作成し、画像処理部が理解できる形にコンパイルした上で、バッファにコンパイル後の命令が保持される。ステップ４において、シェーダプログラムバッファを用いて、頂点シェーダインターフェイス（シェーダハンドラ）が生成される。ステップ５において、頂点シェーダインターフェイスをストリームに設定し、固定機能パイプラインをプログラマブルパイプラインに切り替えて、レンダリングが行われる。

ステップ３以降の実体部分において、デコードの処理内容として、上述したエンコードとは逆の手順が記述される。例えば、図３に示したエンコードの場合、奇数番目の頂点Ｖ2n-1（ｎは自然数）については、Ｚ座標をＸ座標に、Ｘ座標をＹ座標に、Ｙ座標とＺ座標にそれぞれ入れ替え、偶数番目の頂点Ｖ2nについては、Ｙ座標をＸ座標に、Ｚ座標をＹ座標に、Ｘ座標をＺ座標にそれぞれ入れ替えるといった如くである。

なお、セキュリティ強度の向上を図るという観点でいえば、モデルデータのエンコードは、配信対象毎にエンコード方法を変えることが好ましい。この場合、エンコード処理部２ｂは、モデルデータの配信毎に異なる処理でモデルデータをエンコードする。そして、デコードプログラム生成部２ｃは、エンコード処理部２ｂが採用したエンコード方法に応じて、配信対象毎に処理内容が異なるデコードプログラムを生成する。

図５は、クライアント３のブロック図である。このクライアント３は、ＣＰＵ３ａ（中央演算装置）と、画像処理部としてのＧＰＵ３ｂと、データ受信部３ｃと、メインメモリなどの記憶装置３ｄと、ＧＰＵ用メモリ３ｅと、表示装置３ｆとを主体に構成されている。記憶装置３ｄは、ＣＰＵ３ａがアクセス可能であり、ＧＰＵ用メモリ３ｅは、ＧＰＵ３ｂのみがアクセス可能である。

データ受信部３ｃは、サーバ２より送信されたエンコードモデルデータと、デコードプログラムとを受信する。これらのデータは記憶装置３ｄに記憶される。記憶装置３ｄに記憶されたモデルデータのエンコードされたままなので、記憶装置３ｄをダンプしても、有意なデータを取り出すことは困難である。ＧＰＵ３ｂは、ＣＰＵ３ａとは別に設けられており、ＣＰＵ３ａの指示に基づいて、もっぱら画像処理を担当する。ＧＰＵ３ｂは、表示装置３ｆに画像を表示する際、サーバ２より配信されたデコードプログラムを実行することによって、エンコードモデルデータをデコード、すなわち、有意なデータに復元して、画像を生成する。

図６は、ＧＰＵ３ｂにおける画像処理の流れの説明図であり、一例として、マイクロソフト社が開発・提供しているゲームなどのマルチメディア向けＡＰＩセットであるＤｉｒｅｃｔＸ（特にＤｉｒｅｃｔＸ９）の流れを示している。まず、「頂点データ」とは、ローカル座標で定義され頂点バッファに格納されている頂点データのことである。頂点バッファの中には、位置や頂点の色、テクスチャ座標などが設定されている。「プリミティブデータ」とは、基本的な図形、例えば点、線、三角ポリゴンなどで構成されている幾何学図形で、序列（インデックス）バッファとして定義される。頂点バッファおよびインデックスバッファは、両方あってもよいが、どちらか一方であっても構わない。これらの情報は、「テセレーション」に渡される。これは、ポリゴンを細かく分割する部分である。通常、この機能はサポートされないことも多く、何もせずに通り抜ける時もある。

「固定機能パイプライン」および「プログラマブルパイプライン（頂点シェーダ）」は、三次元のポリゴンの情報を直方体の座標系に変換する。プログラマブルパイプラインについて、プログラマがこの頂点変換作業を独自の方法で記述する。これらのパイプラインを通った座標は直方体の座標系に凝縮される。視点を正面に設定した場合、二次元のスクリーン画像となるが、その際、必要のない情報が多く含まれることになる。そこで、「背面カリング」、「クリッピング」、「属性の評価」、「ラスタ化」などによって、無駄を省きながら、不要な情報が破棄される。以上の処理によって、頂点の変換およびスクリーンでの位置決めが終了する。

以後の処理は頂点ではなく、描画される１点毎に各種の描画処理と判定とが行われる。最初の「ピクセルシェーダ」では、ラスタ化の段階で、ポリゴンをスクリーン上にどうやって描画するかが記述され、最終的には「ピクセルカラー」が出力される。プログラマはピクセルシェーダを独自にカスタマイズすることで、様々なエフェクトを発生させることができる。「テクスチャサーフェイス」は、テクスチャ情報のことであり、「テクスチャサンプラ」は、入力されたテクスチャに各種フィルタを適用する。これにより、ピクセルシェーダは、指定のテクスチャ座標（テクセル）に対して、適切な色を取り出すことができるようになる。

ピクセルシェーダによりスクリーン上でのピクセルカラーが決まった後は、「アルファテスト」、「深度テスト」、「ステンシルテスト」、「フォグテスト」、「ブレンディング」などにより、描画するか否かの判定が行われる。これらの判定を経て、バッファにピクセルが描画される。

プログラマブルシェーダは、ＧＰＵ３ｂのうち、「プログラマブルパイプライン（頂点シェーダ）」と、「ピクセルシェーダ」の部分について、独自の命令群を差し込むものである。頂点シェーダおよびピクセルシェーダには、それぞれＧＰＵ３ｂに命令を与えるための命令群が予め用意されている。本実施形態では、クライアント３側の画像処理部３ｂが有するプログラマブルシェーダによって実行されるシェーダプログラムのうち、特に、頂点の座標変換方法を規定した頂点シェーダプログラム（図４参照）をデコードプログラムとして用いる。ＧＰＵ３ｂは、このプログラムを実行することにより、エンコードモデルデータを逐次的にデコードしながら画像処理を行い、表示装置３ｆに画像を表示させる。なお、デコードプログラムとしては、頂点シェーダプログラムに代えて、ピクセルシェーダプログラムを用いることも可能である。

このように、本実施形態によれば、サーバ２とクライアント３との間におけるモデルデータの送受を、モデルデータをエンコードしたエンコードモデルデータの形で行うことで、第三者による盗聴や改ざんを防止できる。また、クライアント３側におけるエンコードモデルデータのデコードは、画像を表示する際、ＣＰＵ３ａとは別に設けられた画像処理部（典型的にはＧＰＵ３ｂ）がデコードプログラムを実行することによって行われる。この画像処理は、メインメモリ等の記憶装置３ｄを用いることなく、ＧＰＵ用メモリ３ｅを用いて行われる。このように、ネットワーク上やメインメモリ上にデコード済のモデルデータを配置せず、モデルデータを表示する際（描画時）、その都度デコードする。エンコードモデルデータは、表示画面（１フレーム分）を形成するために必要なデータのみが部分的に順次デコードされていき、ＧＰＵ用メモリ３ｅに全てのデータが一括で展開されることはない。これにより、モデルデータの送受および画像処理におけるセキュリティ強度の向上を図ることができる。

なお、上述した実施形態では、図６のＤｉｒｅｃｔＸ９を例に説明したが、最新のＤｉｒｅｃｔＸ１２では、これとは異なる環境が採用されており、ブラウザで動作するＷｅｂＧＬは、ＯｐｅｎＧＬベースであるため、図６とは環境が更に異なる。レンダリングパイプラインの詳細は環境に依存しており、本発明は、画像処理部としてのＧＰＵ３ｂの環境を問うものではない。本発明において重要なことは、画像処理部において、「頂点データをラスタライズして画面に表示するまでの間に、ユーザが作成した処理を挿入できる」ことである。この条件を満たす限り、本発明は、画像処理部の環境を何ら問うものではないことに留意すべきである。

また、上述した実施形態では、「画像処理部で動作するプログラム（シェーダ）」として、頂点シェーダについて例示し、ピクセルシェーダについても適用可能である旨説明したが、本発明はこれに限定されるものではなく、両者を区別することについても、本質的な意味はない。例えば、統合型シェーダ・アーキテクチャのＧＰＵでは、これらを区別しておらず、頂点シェーダやピクセルシェーダとは別のジオメトリシェーダ等が使用可能な環境も存在する。本発明は、クライアント３が備える画像処理部の環境下で動作する各種シェーダ（プログラム）を広く用いることができる。

１ サーバクライアント型システム
２ サーバ
２ａ データ要求受信部
２ｂ エンコード処理部
２ｃ デコードプログラム生成部
２ｄ データ送信部
２ｅ モデルデータ格納部
３ クライアント
３ａ ＣＰＵ
３ｂ ＧＰＵ
３ｃ データ受信部
３ｄ 記憶装置
３ｅ ＧＰＵ用メモリ
３ｆ 表示装置

Claims (6)

1. モデルデータ配信サーバにおいて、
   物体の形状を表すモデルデータをエンコードすることによって、エンコードモデルデータを生成するエンコード処理部と、
   前記エンコードモデルデータをデコードする処理手順を指示する一連の命令群によって構成され、かつ、クライアント側において、中央処理装置とは別に設けられた画像処理部によって実行されるデコードプログラムを生成するデコードプログラム生成部と、
   前記エンコードモデルデータと、前記デコードプログラムとをクライアントに送信するデータ送信部と
   を有することを特徴とするモデルデータ配信サーバ。
2. 前記デコードプログラムは、前記画像処理部によって実行されるシェーダプログラムであることを特徴とする請求項１に記載されたモデルデータ配信サーバ。
3. 前記エンコード処理部は、前記モデルデータの配信毎に異なる処理で前記モデルデータをエンコードし、
   前記デコードプログラム生成部は、前記配信対象毎に処理内容が異なる前記デコードプログラムを生成することを特徴とする請求項１または２に記載されたモデルデータ配信サーバ。
4. モデルデータ受信クライアントにおいて、
   物体の形状を表すモデルデータをエンコードしたエンコードモデルデータと、前記エンコードモデルデータをデコードする処理手順を指示する一連の命令群によって構成されたデコードプログラムとを、前記サーバより受信するデータ受信部と、
   中央処理装置とは別に設けられていると共に、画像を表示する際、前記デコードプログラムを実行することによって、前記エンコードモデルデータをデコードして前記画像を生成する画像処理部と
   を有することを特徴とするモデルデータ受信クライアント。
5. 前記デコードプログラムは、前記画像処理部によって実行されるシェーダプログラムであることを特徴とする請求項４に記載されたモデルデータ受信クライアント。
6. 前記デコードプログラムは、前記サーバより配信される前記モデルデータの配信対象毎に処理内容が異なることを特徴とする請求項４または５に記載されたモデルデータ受信クライアント。

Images