特集

特集

デザイナを中心に置いた，新しいHMIソフトウエア開発手法：
グラフィックメータ向けリアルタイム3Ｄレンダリングエンジンの開発＊
Artist-Centric New HMI Software Development Workflow:
Development of Real-Time 3D Rendering Engine for Reconfigurable Instrument
Clusters
西川良一

中田和行

梶田健太郎

松本壮樹

Ryoichi NISHIKAWA

Kazuyuki NAKATA

Kentaro KAJITA

Soju MATSUMOTO

石川

渡良井葉麻

巧

Takumi ISHIKAWA

Yoma WATARAI

Instrument clusters that display all information on a TFT-LCD screen, also known as reconfigurable instrument
clusters, have become the new trend in automotive interiors. DENSO mass-produced the world's first reconfigurable
instrument cluster in 2008. To satisfy customer requirements, large quantities of resources were required. Coupledwith an iterative process due to requirement changes, development costs became very high. Reducing development
costs was vital in order to expand the reconfigurable instrument cluster products-line. Therefore, DENSO developed a new workflow and technology for the reconfigurable instrument cluster. An artist-centric approach was proposed to reduce the development effort by introducing a data converter and real-time 3D rendering engine. Using
automatic shader code generation and frame rate improvement techniques contributed to rendering a high quality
image on a TFT-LCD screen. The new workflow was evaluated during a mass production development project andresulted in improved software development efficiency.
Key words：Instrument Cluster, Computer Graphics, Model Based Design, Human Machine Interface, REMO

１．はじめにージに限定して切り取り部品化するなど，工夫する必要がある．しかし，高解像度ディスプレイに対して，ゲージを含めたすべての計器をグラフィックにて表これらの技術適用で十分な効果は得られなかった．

示するメータが各自動車メーカにおける旗艦カーの新しいトレンドとなりつつある．一般車では，ここ数年

具体的には，Fig. 1にコマ毎の画像を持ってオープで小型ディスプレイを搭載したメータが主流になってニングムービー（1280x480pixel, 20 fps, 5.2 sec）を制いる．デンソーは2008年に世界で始めてフルグラフィ

作した場合の概念を示す．単純にすべてのイメージデックメータを量産化した．それは1280x480の高解像度ータを持つと，全体のムービーサイズ合計は256MBに

12.3インチTFTディスプレイを使った製品である．

もなってしまう．更新イメージ限定の部品化を適用しても，サイズの合計は178MBである．利用可能な製品化にあたり，最も大きな問題はハードウェアの制限である．なぜなら，信頼性を確保するためには，

16MBからは，かけ離れた数値である．

大容量のHDDやNAND FLASHを使用できなかったか

思い切ったデータ削減を達成させるために，我々はらである．メモリ資源の制限は厳しく，2008年には搭OpenGLを使用することを決断した．それは，3D（3載できるROMサイズは16MB足らずであった．

次元）のCG（コンピュータグラフィックス）を表現

量産化で先行する，小型ディスプレイ搭載メータのするためのクロス言語およびマルチプラットフォーム

表示は固定画像のコピーによってアニメーションを生のAPIである．現在では，ほとんどの新しいGPUでデ成していた．この手法の場合，表示部品をすべてイメ

フォルトサポートされているが，2008年当時，組み込ージデータとして持つ必要がある．そこで，データサ

み向けとしては搭載が始まったばかりの技術であっイズを縮小するための技術，例えば，イメージを圧縮た．OpenGLの使用によって，頂点情報から3D CGをする，あるいは，アニメーション中に更新されるイメ

直接描画することができる（リアルタイムレンダリン＊SAEの了解を得て，SAE2013-01-0425を和訳，一部加筆して転載
Reprinted with permission from SAE paper 2013-01-0425 Copyright © 2013 SAE International.
−149−

デンソーテクニカルレビュー

Vol. 18

2013

グと呼ばれる）．必要なデータサイズはイメージデー

る必要がある．現状では，搭載機能にもよるが，ディタを直接持つ場合より格段に小さくできる．実際に，スプレイのないメータの開発工数は40人月程度，小型

この手法によるオープニングムービーのデータサイズ

ディスプレイを装備しているメータは100人月程度ではコマ毎の画像によって制作されたアニメーションとある．一方で，2008年のグラフィックメータの開発工

等しい画質にもかかわらず，わずか3MBで実現できた．

数は400人月を超えるものであった．我々の最終目標

また，OpenGLは移植性の高さがメリットである．

はグラフィックメータの開発工数を100人月以下に下APIは標準化されているため，既存のソフトウエアをげることである．

移植することにより，他のOpenGL対応のハードウェ

Fig. 2に示す，開発工数の内訳を見ると，グラフィア上で同じ動きが再現できる．例えば，PC上のシミックアプリケーションの開発が最大であることが分かュレーションから，ターゲットハードウェアへシーム

る．工数増大の主な理由は，ハンドコードで機能実装レスに移行することができる．もちろん，ハードウェしていたからである．グラフィックのアプリケーショ

アが変わる場合の移行も簡単である．

ンコードを画像データから自動的に生成することができれば，工数を下げることができる．

開発を通じて明らかになった課題は，開発工数の低減である．顧客の要求を満たすためには多くのソフト

経験上，仕様変更によるやり直し工数が多い事が分

ウエアエンジニアが必要だった．変更要求が度重なる，かっている．2008年には度重なる大規模な仕様変更がいわゆるスパイラル開発により，非常に大きな工数とあり，変更のたびにソフトウエアを1から作り直してなった．なぜ我々はスパイラル開発をする必要がある

いた．また，製品が開発されるまで，見栄えを確認すのだろうか．「高品質グラフィックのアピールがしたることができなかったため，フィードバックするのがい．」，「車両モデルの毎の差別化がしたい．」という顧遅くなってしまっていた．これには，仮想試作を利用客要求がある．しかし，ハードウェア制限のために，することによって，要求定義と分析の段階において顧客からの要求をすべて満たすことは難しい．我々はPCシミュレーション上で見栄えを確認することがで顧客と共に実際のターゲット上で，描画結果を確認しきれば，製品完成まで待つこと無く，フィードバック

ながら，納得のできる表示を見いだすことが必要であすることが可能となり，その結果，大きなやり直しをる．グラフィックメータの高い柔軟性と車の急速な高防ぐことができ，開発工数を下げることが可能となる．

機能化により，開発規模の急増加と複雑化は避けられない．顧客とより高いレベルの製品を追求するためには，開発効率を上げ，スパイラル開発に対応できるプ
ロセスを獲得しなければならない．

Fig. 2

Breakdown of the development cost

３．HMIツールの課題
開発効率を向上する1つの解決法は，既存のHMI
Fig. 1

Implement size of animation by bitblt（Human Machine Interface）ツールを使用することである．HMIツールはグラフィカルなHMIの開発を支

２．開発費の分析援する．HMIツールにはCGコンテンツ作成，様々な開発工数の低減は，グラフィックメータの搭載を拡

組込プラットフォーム向けのコード自動生成，シミュ大するためにも重要である．拡大を実現するために，

レーションおよびドキュメント生成の機能を備えてい我々は従来のメータと同じレベルまで開発工数を下げる 1）．世界には多くのツールが存在するが，どれも業

−150−

特

集

界標準にまで至っていない．グラフィックさらに，そデザイナ中心の新しいワークフローをFig. 4に表す．

れぞれのツールにはイメージやシーン作成のために独

このワークフローにおいて，データコンバータを用い自の方法が存在する．デザイン業界のCGソフトに慣れることにより，CGデザイナによって作成されたCGデているデザイナが，それぞれのツールを習得し，使用ータを実機実装可能なデータへ変換できる．変換されするのは非効率，困難である．デザインデータ（例えたデータはレンダリングエンジンで実行することがで

ばAUTODESK社 3dsMAXで作成したモデルデータ）

き，実ターゲット上でのレンダリング結果をチェック

をインポートできるツールはある．しかし，ほとんどすることもできる．問題がある場合は，CGデザイナの場合，シーン構成作業はその後で必要となり，それだけでCGシーンデータを修正し，改訂できる．
さらにプレビュアの使用により，PCでも結果を確

ぞれのツールには行うべき独自の方法が存在する．
その結果，ソフトウエア開発者がデザイナの作った認することができる．我々は仮想試作としてこの仕組

デザインをツール上で作り直す必要があるため，デザみを使用し，開発の初期段階のうちにCGデザイナにイナから実機までのワークフローは作り替えに苦しむ

フィードバックすることができる．CGデータをインこととなる．設計が変更される度に，デザイナと開発ポートできる多くのツールがあるが，それらの多くは者の両方が再度工程を繰り替えさなければならない．

アニメーションのシーンデータをサポートしていな
い．新しいワークフローの特徴は，CGデザイナの成４．デザイナを中心とした新しいHMIソフトウエア
開発手法

果物を直接利用することができるということである．
データコンバータとリアルタイム3Dレンダリングエン
ジンの詳細は後述する．

メータはドライバの最も重要な情報源であるだけでなく，人と車の間に，ある種のパーソナルな関係性を構築する役割，ドライバと車をつなぐ役割がある．メータのデザインは，明快さ，正確さ，そして美しさを反映したデザインであることが求められる．本論文では，データコンバータおよび3Dのリアルタイムレンダ
リングエンジンの導入により，開発工数を低減したこと，そして，デザイナ中心のアプローチで開発することを提案する．最終目標は，コンセプトから製造までのソフトウエア開発工程におけるロスを最小化して開Fig. 3

Conventional workflow

発することである．デザイン業界標準のCGソフトで表現されたデザイナのアイデアが，実際のターゲット
上で正確に再現されなければならない．
4.1

コンセプト

従来のワークフローをFig. 3に示す．CGデザイナはCGのシーンを作り，ソフトウエア開発者はデータを作り直し，グラフィックアプリケーションを実装する．
その後，実ターゲット上のレンダリング結果を確認しFig. 4

デザインにフィードバックすることができる．そのた

Artist-centric new workflow

め，結果確認により問題を見つけた場合，CGデザイ

4.2

ナおよびソフトウエア開発者の両者が変更しなければシーン作成からレンダリングまでの作業過程，構成ならない．このワークフローは，たとえその問題が要素および構成要素間のデータフローをFig. 5に示す．

CGデザイナの仕事であっても，ソフトウエア開発者

新しいワークフローの詳細は，以下の通りである．
最初に，デザイナは3D CGソフトで3Dモデルとシーも修正しなければならない．したがって，効率が悪くなる．

開発手順の詳細ンを作成する．（モデリングステージ）次に，3Dモデ−151−

デンソーテクニカルレビュー

Vol. 18

2013

ルとシーンからシーンデータをインポートしてからレ

4.4

ンダリングエンジンで使用するためにデータ変換すレンダリングエンジンは，変換ステージで生成される．変換されたデータは，レンダリングエンジン用のたシーンデータを使い，表示デバイスに描画する．あシーンデータおよびシェーダプログラムを含んでいるオブジェクトをレンダリングする時，オブジェクト

る．（変換ステージ）にリンクされるシェーダプログラムが使用される．レリアルタイム３Ｄレンダリングエンジン

最後に，レンダリングエンジン上でデータを実行す

ンダリングエンジンは，シェーダジェネレータによっる．レンダリングエンジンは，変換されたデザイナのて生成された情報と現在のシーン状態を基にシェーダ

データと開発者のアプリケーションコードからの動的パラメータを計算する．その後，エンジンは，パラメ

な入力データに基づいて適切なOpenGL ESコマンド

ータを設定し，GPUを制御するためにグラフィックを呼び出す．（レンダリングステージ）

APIを呼び出す．
レンダリングエンジンは速いレンダリング，軽量さ，高い移植性と拡張可能性，のようなニーズを満たさなければならない．
4.5

ソフトウエア開発者の役割

ソフトウエア開発者の役割は，アニメーションを制御することだけである．アニメーションには2種類ある．あらかじめ定義されたアニメーションとプログラ
マブルアニメーションである．あらかじめ定義されたアニメーションの場合，3D CGソフトでつくることができ，アニメーションのためのレンダリングフレーム
はユーザアプリケーションから直接指定できる．プロ
グラマブルアニメーションの場合，パラメータは各々Fig. 5 Overview of the work process, components anddataflowのオブジェクトのために設定することができる．例えば，速度計の針の動きを表現するためにCGデザイナ

4.3

が各々のフレームに最小値から最大値まで一定の速度

データコンバータ

データコンバータは，エクスポータとプリプロセッサ

で針を動かす3Dアニメーションを作成する．ソフトウ

から成り，エクスポータは3D CGソフト（AUTODESK

エア開発者は，レンダリングエンジンAPIを呼び出し，社 3dsMAX）のプラグインソフトである．またそれは，現在の値に対応するアニメーションを描いたフレーム

環境非依存のシーンデータを出力する．プリプロセッサを指定するアプリケーションコードを書くだけであは，実ターゲット環境用にシーンデータを変換する．

る．0km/hから180km/hにかけての針の動きがフレー

モデリング段階の出力であるシーンデータは，レン

ム0からフレーム180へのアニメーションとなる場合にダリングステージで必要とされるシェーダプログラム

100km/hを表現するときは，APIをパラメータ100でを含まない．したがって変換ステージの出力としては，呼び出すだけであるため，OpenGLのプログラミング

変換されたシーンデータだけでなくシェーダプログラは必要とされない．

ムも必要である．
シェーダプログラムは，変換ステージでシェーダジ

4.6

利点

ェネレータモジュールから生成される（Fig. 5を参照）．

この新しいワークフローでは，デザイナのどんな変このモジュールのための入力はシーンパラメータ（主更でも，すぐに，そしてシームレスに実ターゲットににオブジェクトのマテリアル情報とオブジェクトを輝適用される．

かす光源の情報）である．このモジュールの出力は，そのうえ，モデルステージの出力を基にPC上で描

シェーダ言語（GLSL）で書かれたソースコードとそ

画できるプレビュアを用いて仮想試作ができる．特徴

れを実行するための情報である．

は，プレビュアが実際のターゲット環境向けに特殊化

−152−

特

集

されるため，CGデザイナは簡単に汎用PC上で実組込ムの開発コストを削減できる．また，デザイン制作者

システムのレンダリングを機能させ，出来栄えを確認の教育コストの低減を実現することもできる．

することができるのである．
5.1.1

５．技術課題5.1.1.1

コンセプト
シェーダジェネレータモジュール

シェーダジェネレータモジュールはFig. 6に示す手

レンダリングエンジンは，デザイナの意図したデザ順でシェーダプログラムを生成する．

インにできるだけ近いかたちで組込プラットフォーム
上にて，変換データを解釈（実行）することが重要である．
TFTディスプレイへの高品質な描画の達成に貢献す
る技術的な取り組みとして，シェーダコード自動生成，
および，フレームレート向上手法を本論文では取り上げる．
5.1

プログラマブルシェーダーコードの自動生成

高画質の実現手法として，シェーダコード自動生成技術を紹介する．シェーダは見た目に大きな影響を与える．データコンバータは，3DCGソフトでデザイナが調整できるパラメータを元にシェーダコードを自動的に生成，最適化できる．3dsMAX上のシーン設定から直接生成できることがポイントである．シェーダはグラフィックハードウェア上で描画エフェクトを計算するのに主に使われるコンピュータプログラムである．シェーダは，ジオメトリ変換，ピクセルシェーデ
ィング機能やカスタムエフェクトを実現するGPUプロ

Fig. 6

Procedure of shader generation

グラマブルレンダリングパイプラインをプログラムするのに使われる．OpenGL，OpenGL ESの公式シェーシェーダのソースコードは独自形式のテンプレート

ディング言語はOpenGL Shading Language（GLSL）

ソースコードを基に生成される．そのテンプレートソである．シェーダジェネレータはブリンシェーディン

ースコードをインスタンス化するためにいくつかのテ

グのパラメータを元にシェーダコード生成と静的最適ンプレートパラメータが必要になる．それらのパラメ化を自動的に実行できる．ブリンシェーディングモデ

ータを決定するために，先ず，シーンパラメータを解ルは有名なシェーディングモデルの一つであり，十分析し必要な情報を収集する．

リアルであり，処理負荷がそれほど高くないためリア

次に，それらの情報を基に，テンプレートソースコ

ルタイムレンダリングに適しているといわれている．

ードを選択し，同時にテンプレートパラメータも生成

多 く の 3DCGソ フ ト は こ の パ ラ メ ー タ を も つ ．

する．そしてこのテンプレートパラメータを指定して，3dsMAXにおいては標準マテリアルのデフォルト設定

この選択されたテンプレートソースコードをインスタ

はブリンシェーディングである．

ンス化する．このテンプレートのインスタンス化はシ

シェーディング言語はプログラミング言語として定ェーダユニットタイプ毎に行われる．シェーダユニッ

義されているためハンドコーディングは可能だが，プトの種類は一般的に頂点シェーダとフラグメント（ピログラマブルシェーダーは自由度が高いため，所望のクセル）シェーダがある．

表示を達成するには高度な知識，技術が必要である．

次に，生成されたシェーダのソースコードは最適化

シェーダ自動生成ができることにより，グラフィクス

モジュールによって最適化される．最適化の詳細は後

データの制作過程を簡素化し，高品質な3DCGシステ

述する．

−153−

デンソーテクニカルレビュー

Vol. 18

2013

まず，シェーディング言語のコードを最適化に適した

最後にこのシェーダのソースコードを実行する際に，レンダリングエンジンが必要とする情報を生成す

中間言語のコードに変換する．

る．この情報には，そのシェーダが必要とする頂点要

次に， 中間言語のコードを最適化する．実際には不素やパラメータは何か，そのパラメータをどのように要な処理や変数を削減する．

計算するのか，描画されるポリゴンは背景画像とどの

最後に，中間言語のコードをターゲットのシェーディ

ように混合されるのかなどの項目が含まれる．

ング言語のコードに再変換する．
この手順によって，ターゲットのシェーディング言語

5.1.1.2

で記述された，最適化されたシェーダコードが生成さシェーダコード最適化

れる．

シェーダコード最適化の利点は以下である．
・複雑な計算が必要なシェーダが作成できる・レンダリングが高速化される

5.1.2

・アプリケーションの初期化時間が短縮される考案手法によって，デザイナの意図したデザインを実験検証

1つのシェーダプログラムが使用できるGPU資源のいかに実機上で再現できているかについて検証した．

量には限界値がある（たとえば，レジスタや命令の数）．

画質の定量的評価指標として，3dsMAXによる元の描最適化によって使用されるGPU資源の量は自動的に削画結果と実機の描画結果のピクセル比較を考えた．実減される．そのため複雑な計算ができるシェーダを作機としてカスタム評価ボードを使用した．ボードはル成できる．

ネサスエレクトロニクス社製のSH-Navi3（SH7776），

レンダリングの高速化は以下の理由で実現される．

64MBのROM， 256MBのRAM， DVGA（1280x480）

・最適化前のプログラムに存在する無駄なコードが12.3インチTFTディスプレイを搭載している．描画結果として，LVDS出力を，インターフェース変換アダ削減されるので実行時間が短縮される

プタ（IA-542-B（LVDS to DVI）: ASTRODESIGN Inc.）・使用されるGPU資源が減少することによってGPUと コ ン バ ー タ キ ャ プ チ ャ BOX（ DVI2USB solo:

内の実行の並列度が向上する

Epiphan Systems Inc.）を用いてキャプチャした．

・CPU側から設定するパラメータが少なくなるので客観的画質評価メトリクスとして，広く使われていCPUとGPUの負担が減少する
シェーダコードの不要なコード削減により，ソース

るPeak Signal-to-Noise Ratio（PSNR）を用いた．一般

コードサイズが小さくなることで，コンパイル，リン的に，PSNRが30dB以上であれば処理された画像は人

ク時間が短縮されるため，アプリケーションの初期化

間 の 眼 で 許 容 で き る 範 囲 の 画 質 劣 化 と い え る 2）．

時間が短縮できる．

PSNRが40dB以上であれば元画像と処理された画像はシェーダコードの最適化はFig. 7で示す手順で実行さ人間の眼では差を近くできない．そのため，ここではれる．

PSNRが30dB以上であれば画質は十分であるとした．
テスト条件として，1つのティーポットの3Dモデル
を様々なパラメータ設定で描画するテストシーンを準備した．各シーンにおいて，3dsMAXの描画結果と実機の描画結果を解像度640x480の32bitビットマップとして取得した．3dsMAXで設定できる一般的なパラメータを全てカバーできるように12種類のテストシーンを選択した．テストシーンはマテリアルパラメータ（ambient，diffuse，specular，shininess， emission，bump，reflection），ライトパラメータ（directional light，spot light，omni light），その他のパラメータ（environment map，
skinning, morphing 等）を含む．

Fig. 7

Procedure of shader code optimization
−154−

特

集

5.1.3

計算して，一回の描画コマンドで処理した方が性能改検証結果

Table 1はPSNR結果を示す．すべてのシーンにおい善する場合がある．本手法は，あらかじめ指定されたて30dBを上回っていることから，十分な再現性を達成

グループ内の代表メッシュが，代表でないメンバーのできているといえる．主観評価でも元画像と処理されメッシュの頂点をまとめて一つの頂点配列として保た画像の違いの検出は難しいと判断できた．

持・描画する．それゆえに描画コマンドの呼び出し回

Table 1

数が削減できる．

Results of PSNR

一般的に，各オブジェクトはシーングラフのトラバース順に描画される．シーングラフのデータは構造化されたグラフとして管理される．ノードはリンクによって接続され，ルートノードはシーンデータの始点として定義される．ルートノードからスタートしてノード間のリンクがすべてのノードを通過するまでたどられる．シーングラフのトラバースは深さ優先（兄弟ノードに行く前にすべての子ノードをトラバースする）
で実施される．提案手法はこの一般的な処理から逸脱している．
下記の制約を満たすオブジェクト同士はグループ化
することができる．
・同一のマテリアルを参照しているオブジェクト同
5.2

士のみ同じグループにできる．

メッシュ自動連結・1つのオブジェクトは一度に1つのグループにのみ

高フレームレートを達成する手法として，メッシュ

所属する．

自動連結技術を紹介する．この手法はなめらかな動き

・同じグループに所属するオブジェクト同士が重なの見栄えに寄与する．

らない．
5.2.1

コンセプト

グラフィックメータはインジケータ，指針，ダイア

5.2.2

データコンバータ

ル，情報表示のためのパネル，Lane表示，turn by

ワークフローにおいて，メッシュ自動連結技術は，

turn（TBT）ナビ表示などを表示する．グラフィック

データコンバータによるデータ変換時にコンフィグフ

メータの特徴として，描画対象のオブジェクトが大量ァイル入力オプションを設定して適用できる．コンフにあるが，各オブジェクトは単純な形状（長方形）で

ィグファイルは各オブジェクトの連結グループの指定

頂点数が少ないことが多い．

を含む．前述した制約のチェックはコンバート時に実

描画コマンド（OpenGLではglDrawElements（ ））施される．

が呼ばれ，描画処理が走るたびに関数呼び出しによるデータコンバータは，連結対象のメッシュのどれか

オーバーヘッド時間がかかる．頂点数が多いオブジェ

一つ（トラバースで最初に出てきたもの）を代表としクトを描画する際にはオーバーヘッドの占める割合はて扱う．代表メッシュはその他のメッシュの頂点デー

相対的に小さい．しかし，頂点数の少ないオブジェク

タを連結した状態で，かつ非VBOとして保持する．代トを処理する際にはオーバーヘッド時間が処理時間の表以外の連結対象メッシュは実体を持たない代わりほとんどを占める．

に，代表メッシュ内の頂点配列のどこからどこまでがそのメッシュ由来の頂点かを保持する．

描画コマンドの関数コールによるオーバーヘッド
は，特に組込環境では描画速度に大きな影響を与える．
したがって，頂点数の少ないオブジェクトが大量に存

5.2.3

在する場合は，vertex buffer object（VBO）化せず，

Fig. 8，Fig. 9はレンダリングエンジンにおけるメッ

ひとつの頂点配列に統合し，頂点変換をCPU側で自前

シュ自動連結技術特有の処理フローを示す．トラバー−155−

レンダリングエンジン

デンソーテクニカルレビュー

Vol. 18

2013

ス処理とレンダリング処理がある．
トラバース処理（Fig. 8）において，代表メッシュ
については，元となる各オブジェクトの情報を元に全ての頂点属性変換をCPU処理し，頂点配列を直接書き換える．ノードの可視性の値については共通シェーダでの処理になる．そのため，連結された各メッシュの連結前のノードの可視性パラメータを考慮しないと代
表メッシュの可視性のみが適用されることになる．この問題を避けるため，個々のノードの可視性値を内部
的に頂点αに変換する．また，次に説明するレンダリ
ング処理で使用するための情報としてvisibility flagをノードの可視性をもとにセットする．
レンダリング処理（Fig. 9）においては，代表メッシュがもつ連結した頂点のみを描画する．可視性0のオブジェクトについて，頂点αを0にすることでも対応可能だが，ピクセル負荷がかかってしまうため，オ
ブジェクトを非描画とする処理をしている．具体的にFig. 9Mesh Concatenation（Rendering）

は，トラバース処理でセットしたvisibility flagを用いて，インデックス配列上で，描画不要な頂点のインデ

5.2.4

ックスを削除する．元のメッシュの可視性が0でなけ

Fig. 10は提案手法により実現される性能改善の理論

れば，元のインデックスを，描画用に確保したRAM的モデルを示す．従来，1つのオブジェクトを描画す

上の一時的なインデックス配列領域にそのままコピーるために描画コマンドを呼ぶたびにオーバーヘッド処する．

理と本処理が頂点に対して実行される．提案手法の適シミュレーション

用により，描画コマンドは連結したグループに対して1回のみ呼ばれる．一方，前述したメッシュ連結による特殊処理が実行される必要がある．特殊処理は主に頂点変換なので，処理時間は計算対象の頂点数に依存する．式（1）は理論モデルから導かれる処理時間を表す．oh は1オブジェクトあたりのオーバーヘッド時
間， obj はオブジェクト数， v は1オブジェクトあたりの頂点数である．簡単のため，v の値はシーン内のすべてのオブジェクトで一定とする．オーバーヘッド
時間は一定値，主処理，特殊処理は v の1次関数と想定した．m が主処理の傾き， s を特殊処理の傾きとする．言い換えると，m， s は各処理の1頂点あたりの処
理時間である．提案手法の適用により，2つのダミー
頂点がグループ内のすべてのオブジェクトの間に追加される．また，頂点数が偶数のオブジェクトに対し，1つのダミー頂点が追加される．簡単のため，すべて
Fig. 8のオブジェクトの頂点数が偶数とすると，1オブジェ

Mesh Concatenation（Traversing）

クトあたり（v +3）個を処理する必要がある．

−156−

特

集

モデル内の全頂点数（v*objで表現される）は提案手

5.2.6

検証結果

法の適用有無にかかわらず一定と想定できる．式（2）Fig. 11はシミュレーション結果とCPU負荷の測定結は式（1）から導かれる．結果として，提案手法適用

果を示す．シミュレーションに使われたoh，m ，sの前後の処理時間はいずれも1次関数である．

値はそれぞれ0.16ms， 0.00077ms，0.0035msであり，これらは実機で測定された．結果から，理論モデルが実際に測定された性能をよく説明できているといえる．式（3）から，今回使用した実機ではobj > 97 を手法適用前の処理時間が手法適用後の処理時間より満たせば提案手法は効果があるといえる．測定結果は大ならば，提案手法は効果があるといえる．そのため，

オブジェクト数が100を超えたところで提案手法は効条件が式（3）を満たせば手法は効果があるといえる．

果があることを示している．

Fig. 11 Result of the measurement of the CPU load and thegraph of numerical simulation by using equation (2)with oh = 0.16, v*obj=4000, m=0.00077, and s =0.035

理論モデルではGPU負荷を考慮していない．Fig. 12
はGPU負荷の測定結果を示している．GPU負荷の特性については更なる調査が必要ではあるが，今回の場合
は提案手法適用前後でそれぞれ30ms，35msほどである．Fig. 13は実際の処理時間（CPU負荷とGPU負荷のFig. 10 Theoretical model of the performance improvement
realized by the automatic mesh concatenation
technique

うち長いほうの時間）を示す．結果から，オブジェク
ト数が200を超えると提案手法は効果があるといえる．
提案手法は最適化の条件がそろえば効果があるとい

5.2.5

える．特にグラフィックメータにおいては単純な描画

シミュレーション検証

オブジェクトがたくさんあるため最適化の条件に当て性能特性が前述したシミュレーションと等しいかど

はまり易い．

うか確認するため，実機で処理時間を測定した．実機仕様は，シェーダコード自動生成の実験と同じである．
4,000頂点の3Dモデルを準備した．測定条件として，オブジェクト数1，10，100，125，200，250，500，
1000とし，オブジェクト構造はオブジェクト数と1オブジェクトあたりの頂点数の積が一定になるように調整した．描画タスクの処理時間を提案手法の適用前後で測定した．CPU負荷とGPU負荷をそれぞれ測定した．
長いほうの時間が実際の処理時間である．また，式（2）を用いたシミュレーションのためにoh，m，sを測定した．

Fig. 12−157−

Result of the measurement of the GPU load

デンソーテクニカルレビュー

Vol. 18

2013

Fig. 14 Example of 3D-CG screen by developed product
Table 2

Result of object reduction

Fig. 13 Result of the processing time (the longer time
between CPU and GPU loads)

5.2.7

実機検証例

メッシュ自動連結技術を試作品に適用した効果の例を示す．試作品はルネサスエレクトロニクス社製のSH7769，128MBのROM，256MBのRAM，DVGA（1280x480）12.3インチTFTディスプレイを搭載してTable 3いる．

Result of the processing time

Fig. 14は試作品の3DCGを示す．コンテンツは4ゲー
ジ（スピード，タコ，燃料計，水温計），テルテール，
タブメニュー，運転支援システム表示などである．この3Dモデルは154オブジェクト14,960頂点からなる．
いくつかの最適化手法の適用により，17.2msの向上がTable 4 Evaluation of the new workflow on mass production
project

見込まれたが十分ではない．メッシュ自動連結の適用により，今回の場合は154オブジェクト中の123オブジ
ェクトが8グループに分類できた．Table 2は結果の内訳を示す．1オブジェクトあたりオーバーヘッド時間（0.16ms）分の処理時間削減が見込まれるので，提案手法による効果は18.4msとなる．合計で35.6msの削減が見込まれる．
効果確認のため，提案手法適用前後の描画タスクの

６．量産適用効果

処理時間を測定した．表示条件は仕様上最も高負荷な今回考案した新しいワークフローをグラフィックメ

条件とした．Table 3に測定結果を示す．結果から，ータの量産プロジェクトにて評価した．Table 4は開GPU負荷に影響を与えずにCPU負荷を下げることがで

発コスト，コード行数，搭載機能数およびプロジェク

きているといえる．なめらかな表示の実現のために高ト中のイテレーション（スパイラル？やり直し？）回

フレームレートが（特に，動きのはやいタコ指針表示数を示す．開発コストは開発期間中のアプリケーショ

に対して）望まれている．人間の視覚特性を考慮する

ン開発コストの累積値である．LOCについてはグラフと，少なくとも30fpsの達成が求められる．30fps達成ィックアプリケーション部に限定してカウントした．

のためには，CPU負荷を33ms以内に抑える必要があ

LOCは開発期間中の変更行数の累積値である．

り，メッシュ自動連結技術がその達成に寄与した．

車両Aのアプリケーションコードはハンドコードで実装された．一方，車両Bはすべてのアプリケーショ
ン開発に対して新しいワークフローが適用されたた
め，ほとんどのコードは自動生成された．自動生成コ

−158−

特

集

ードのほとんどはグラフィック描画のためのパラメータであり，グラフィックコンテンツの規模に従って大きくなる．
結果をみると，新しいワークフローにより，車両Bのプロジェクト規模が車両Aより大きい（LOCは17倍，
機能数は2倍，イテレーション回数は3倍）にもかかわらず，車両Bの開発コストを車両Aと同等に抑えることができていることが確認できた．車両Bのプロジェ
クトにおいて，車両Aと比較して顧客要求の変更が頻繁に発生したが，我々は新しいワークフローにより対応することができた．この新しい開発手法を使うことにより，我々は顧客要望にこたえることができる，あるいは要望以上のことができると考えている．
Fig. 15 System block diagram（the past, the present andthe future）

７．むすび
ツールチェーンを活用したプログラミングレスの開＜参考文献＞

発の達成が理想の世界である．
デンソーはグラフィック開発の自動化を，データコ

1）Y, Lefebvre, “An Embedded Platform-Agnostic

ンバータとレンダリングエンジンを用いて達成した．

Solution to Deploy Graphical Applications” SAE

更なる開発費低減に向けて，次のゴールはモデルベー

Technical Paper 2011-01-2551, 2011, doi : 10. 4271/

ス開発ツールとの統合である．

2011-01-2551

我々のソフトウェアアーキテクチャの基本コンセ

2）Chen, T.S., C.C. Chang and M.S. Hwang, “A

プトは，よく知られているモデル・ビュー・コント

Virtual Image Cryptosystem Based upon Vector

ローラ（MVC）である．各パートの独立性を保ってQuantization” IEEE Transactions on Image

おり，実際には2つの異なるマイコンに配置していた

Processing, 7: 1485-1488, 1998, doi : 10. 1109/83.

（Fig. 15）．一方のマイコンは車両制御用でありモデル

718488とコントローラを担う．このマイコン上では既存の品
質保証済のメータのソフトウエア資産が使われている．
他方のマイコンは描画専用であり，ビューを担う．モ
デルベース開発ツールの適用はコントローラに対してのみ進んでいた．時代のニーズとして，機能や表示の追加，各車種の差別化が求められている．更なる効率化のためには，コントローラとビューを1つのマイコン上に統合し，ツールチェーンを用いて開発プロセスをカバーする必要がある．

−159−

デンソーテクニカルレビュー

＜著

西川

中田

和行

（なかた

りょういち）

かずゆき）

情報通信システム開発部

情報通信システム開発部

グラフィックメータ，

グラフィックメータ，

ディスプレイECUの開発に

ディスプレイECUの開発に

従事

従事

梶田

健太郎

（かじた

2013

者＞

良一

（にしかわ

Vol. 18

松本

けんたろう）

壮樹

（まつもと

そうじゅ）

情報通信システム開発部

株式会社スリーディー

グラフィックメータ，

3Dグラフィックス技術の研究

ディスプレイECUの開発に

に従事

従事

石川

巧

（いしかわ

渡良井
たくみ）

葉麻

（わたらい

ようま）

株式会社スリーディー

株式会社スリーディー

3Dグラフィックス技術の研究に

代表取締役

従事

3Dグラフィックス技術をコアにした事業を展開−160−