モダンな OpenGL で頂点モーフ

セガゲームス、開発技術部の山田@プログラマです。
普段はゲームのランタイムライブラリ作成やらツール作成やら、深追いデバッグを担当しています。
今回より本ブログにデビューとなりましたのでよろしくお願いします。

さてさて今回のお題に入りましょう。
最近は DirectX12 や Vulkan といった新しい API がありますが、今回は OpenGL の比較的新しい機能の紹介をしたいと思います。

お題: Shader Storage Buffer Object を使う

OpenGL 4.3 で入った Shader Storage Buffer Object (SSBO) というものを使ったことはありますか?

この SSBO は知名度が低いのですが、シェーダーから自由に読み書きができるという点ですごく便利です。
シェーダーにバッファをセットするという点では Uniform Buffer Object (UBO, 定数バッファ) がありますが、
これは読み込みしかできません。書込みが可能な SSBO を使って何ができるでしょうか。

1つの例として今回は SSBO を用いての頂点モーフを考えてみましょう。
近年の描画処理においてはモデルデータを1回描画して終わりではありません。
複数回同じモデルを色々なシェーダーで描画して、最終的な画面結果を作り上げていきます。
そのため、頂点モーフの処理もまた複数回必要になってきます。
しかしながら形状自体は同じであるため、頂点モーフの結果を使いまわせれば処理コストを節約することが出来そうです。
以降はその実装についてのご紹介です。

SSBO のチュートリアル

SSBO は以下のようにして生成します。 OpenGL におけるバッファオブジェクトの生成方法と同じです。

GLuint ssbo;
glGenBuffers(1, &ssbo);
glBindBuffer(GL_SHADER_STORAGE_BUFFER, ssbo );
glBufferData(GL_SHADER_STORAGE_BUFFER, bufferSize, buffer, GL_STATIC_DRAW );

使う際には、この作成した SSBO のオブジェクトを glBindBufferBase で任意のバインディングポイントにセットしていきます。
バインディングポイントの最大数は GPU のドライバに依存するようなので若干注意が必要です。

glBindBufferBase( GL_SHADER_STORAGE_BUFFER, bindingPoint, ssbo );

こうやってセットしたバッファを シェーダーから使うには以下のように記述します。
不定の長さのものを扱えるところも SSBO の扱いやすいポイントです。

#version 430
layout(location=0) in vec4 position;

layout(std430,binding=0) readonly buffer SSBO {
  vec4 data[];
} gSSBO;

void main() {
   vec4 data0 = gSSBO.data[0];
   vec4 data1 = gSSBO.data[2];
}

頂点モーフの実装

SSBO の使い方を分かったところで、頂点モーフの実装を考えてみます。
複数のモーフターゲットがあることが普通で、処理できる個数を限定してしまうことはしたくありません。
そこで各パラメータによって複数のモーフターゲットの成分を合成し、
描画する際にはこの成分と加算することで形状が確定するということにしてしまいます。
この成分の合成する先として SSBO を使います。

f:id:sgtech:20161027134536p:plain:w300

描画のための OpenGL の呼び出しコードは以下のようなものとなります。
各頂点分だけのモーフ成分を計算したいので、 GL_POINTS で頂点分を処理しているところがポイントでしょうか。
ピクセルとしての書き込みを行う必要もないので GL_RASTERIZER_DISCARD を有効化していたりするのもポイントですね。

glUseProgram( ssboMorphShader );
glBindVertexArray( ssboMorphVAO );
glEnable(GL_RASTERIZER_DISCARD);
glDrawArrays(GL_POINTS, 0, vertexCount );

glDisable(GL_RASTERIZER_DISCARD);
glUseProgram( drawMorphShader )
glBindVertexArray( drawVAO );
glDrawElements( GL_TRIANGLES, indexCount, GL_UNSIGNED_SHORT, nullptr );

実行してみると以下のようになりました。

素直に実装したマルチストリームの頂点シェーダー版と比べて、
数回描画する場合には SSBO を使って処理したほうが高速に処理できることが確認できます。

f:id:sgtech:20161027134340g:plain

One more thing

さて、頂点モーフターゲットの成分を合成している部分について注目してみると、
テクスチャ未使用、ピクセルシェーダーも不要と、単なる計算処理しかしていません。
この部分について OpenGL にも搭載されている ComputeShader (以降 CS) を使ってみることにしましょう。

モーフターゲットについては SSBO で作成しているので、そのまま CS にセットできます。
また、今回も SSBO に結果を書き込むため、描画処理そのものは先ほどのものと共通で使えます。

計算処理から描画までの OpenGL の呼び出しコードは以下のようなものになります。
モーフの計算部分については Vertex Array Object (以降 VAO) のセットが不要です。

glUseProgram( computeMorphShader );
glDispatchCompute( vertexCount/32+1, 1,1);

glUseProgram( drawMorphShader )
glBindVertexArray( drawVAO );
glDrawElements( GL_TRIANGLES, indexCount, GL_UNSIGNED_SHORT, nullptr );

同じ SSBO を使ったコードで、頂点シェーダー版と ComputeShader 版とで、
実行について速度差が生まれるかどうかについてですが、今回の例においては劇的な差はありませんでした。
若干 頂点シェーダーSSBO出力版のほうが軽いでしょうか。

f:id:sgtech:20161027134503g:plain:w400

最後に

SSBO を用いた頂点モーフの実装例を紹介しました。
勢い余って OpenGL の Compute Shader による実装までやってしまいましたが、いかがでしたでしょうか。
OpenGL 4.x もまだまだ面白いと感じてもらえたら幸いです。




モデル協力:セガ・ハード・ガールズ


セガ・ハード・ガールズ公式 HP:http://shg.sega.jp/ 公式twitter:アソビン教授(セガ・ハード・ガールズ) @SHG_Official TVアニメ『Hi☆sCoool! セハガール』公式HP: http://shg.sega.jp/anime.html

(C)SEGA /セハガガ学園理事会


CEDEC2016プロダクションラウンドテーブルの振り返りとレガシーなJenkins環境に纏わる話

f:id:sgtech:20160926170951j:plain

 

こんにちは。セガゲームス開発技術部所属のこかわです。

社内ではビルドエンジニア&QAエンジニア(自称)として、開発部署やQA部署の業務がスムーズに進むためのサポートを行っています。CEDEC運営委員等、社外でも開発者向けイベントを中心に活発に活動しています。

今回はまだ開発者ブログならではの内容は薄めですが、CEDEC2016を振り返りながら、そこから繋げてセガ社内のプロダクション技術の話をしてみたいと思います。

 

キーワードを解説しながら要約すると、「ビルドエンジニアリング=チームで(巨大な)アプリケーションを開発する中で最新の動くアプリケーションを安定かつ素早く作る(ビルド)仕組み」が「レガシー=長い期間使い続ける事で古くなった、先任者が作り上げて手が出せなくなった」状況に対してどう取り組んでいくかというお話です。

 

CEDEC2016プロダクションラウンドテーブルの話

f:id:sgtech:20160926170952j:plain

プロダクションラウンドテーブル | 公式サイト | CEDEC 2016 | Computer Entertainment Developers Conference

CEDEC2016では、上記ラウンドテーブルの中で「レガシー開発環境をなんとかする」というテーマの担当をしました。(ラウンドテーブル記録資料:CEDiL

CEDECでは最近プロダクション分野ができ、ゲーム開発会社内でもビルドエンジニアとしてビルド周り自動化の専任者も出てきている中で、環境のメンテナンス・自動化技術の属人化といった課題が取り上げられました。

特に自動化で業界デファクトスタンダードとして使われているJenkinsの話題は例年多く話題に挙がります。(Jenkins: https://jenkins.io/

こかわは長い間このJenkinsに関連するプロダクション環境のサポートを社内で行ってきましたので、そこにフォーカスして話を進めます。

 

自身がセガ社内で扱ってきたJenkins環境

これまでに作ったJenkins環境

2008年入社から今までで、ぱっと思い出せる範囲で8インスタンス以上は本番運用されるJenkinsを立てました。1年に1Jenkinsは立てている事になりますね。

最初は、アーケードゲーム向けライブラリの自動ビルドから始まり、

 CEDEC2010 タダで始めるゲーム開発自動化のススメ

Unity製スマートフォン向けアプリの自動ビルドや自動デプロイ環境の構築がたくさんあって5つくらい、

 [Unite Japan 2013]Unity × Jenkins:一歩進んだ使い方 on Vimeo

その他1つくらい、といった感じでそこそこの回数、運用を考えながらJenkins環境を立ててきました。

ゲーム開発の自動化はプラットフォームが多様な点を軸に、言語やコンパイラなど下回りが全く異なったり、扱うデータがソースコードだけでは無い点など、いろいろやれる事が多くて楽しいです!

 

こういった中で、いろいろ背景や運用方法、導入時期の異なるJenkins環境を立ててきた結果、完全にレガシー状態になっているもの、レガシーにならないように気をつけて運用しているものそれぞれ存在するので、今回はそこから極端な事例をピックアップして具体的に紹介してみようかなと思います。

# ここでのレガシーは、Jenkins環境(本体バージョンや設定の属人化)に限定して話を進めます。

 

1. 完全にレガシー状態になっているJenkins環境

CEDEC2010 タダで始めるゲーム開発自動化のススメ この講演内の実例の環境です…。

2008年に入社後ライブラリチームに入った直後に立ててから、2016年現在まで稼働し続けています。

ライブラリ自体がレガシーになり頻繁な開発には使われなくなったものの、バグ修正依頼に対処した後の、リリース作業の自動化という点でまだ現役です。

Jenkinsバージョン:1.487

一回アップデートしようとした時に起動せず⇒元のバージョンに戻して復旧

というトラブル以降、バージョンを上げていません。

特定のプラグインでエラーが出ていたところまで特定しましたが、対応する時間を取るのを諦めてそのままになっています。

ジョブ数:163

上のCEDEC講演資料で紹介したような内容(自動ビルド、自動テスト、静的解析3種類以上、コードメトリクス計測、ドキュメント生成、パッケージリリースなど)に加えて、当時は個人のミーティングの予定などもRedmineでチケットにしていたのでそのリマインダーメールがJenkins経由で飛んでくるジョブなど、若気の至りで作ったレガシーなジョブの集合体になっています。いろいろな事を1つのJenkinsに詰め込んでプラグインも多く入っているのでこれがバージョンアップを阻害している要因でもあります。自作のJenkinsプラグインも入っています。

結論

この環境はレガシーから脱却するのを諦め、このまま最低限必要な機能を維持したまま、役割が終わるのと同時に閉じるつもりでいます。

ラウンドテーブルでも触れましたが、プロジェクトの終わりが見えている場合や今後ジョブの追加や変更など変更が予想されない場合はそのままの環境で走りきるのも手だと思います。

# もちろん、セキュリティ面やハードウェア交換、関わる人などの状況によって、きちんと対応しないといけないラインは変わると思います。

Jenkinsの設定については他のプロジェクトや今後も使えるジョブはそこだけ取り出して、新しいJenkins環境に移す事を考えた方がスムーズでした。

 

2. レガシーにならないように気をつけて運用しているJenkins環境

CEDEC2015 長期運営タイトルに後からパイプラインの自動化を導入した際の技術的Tips この事例でのJenkins環境を紹介したいと思います。

ここでは、自動化設定が複雑かつ長期的にメンテする可能性があったので、レガシーにならないように気をつけて運用した例です。

 

gitでJenkins設定の管理

ラウンドテーブルで提案した通り、Jenkinsの設定ファイルをgitでバージョン管理しています。

このやり方の最大のメリットは、設定のバックアップという意味以上に、コミット時に設定変更の意図を残せる点です。

 

コミットログはこんな感じです。

コミット日時作成者コメント
b6d6682e 2015/01/13 14:56 粉川 貴至 リファクタリング。古いJobの整理。名前修正。
c4ac6f8b 2015/01/14 16:21 粉川 貴至 ビルド失敗時にビルドログをメール本文に追加
7e2c1957 2015/01/14 16:47 粉川 貴至 結果通知メール微修正
9a1eb98a 2015/01/14 21:31 粉川 貴至 遅延展開書き忘れ
7cdde7a4 2015/10/27 11:22 粉川 貴至 #2740 コンバート時のJenkins設定ミスを修正
47e02bbd 2016/02/22 11:51 粉川 貴至 #3630 タイトル機能追加に伴う自動処理追加対応

 

Jenkins設定を作りながらJenkins運用も進めている場合に「どのタイミングで設定をどう変えたか」をコミットログですぐに確認する事ができます。

また、運用開始後に問題や変更が起こった場合、チームのイシュートラッカーにチケットを立てから対応して、コメントにチケットIDを含めています。チームの開発の流れと同列に、振り返る必要があった時に見つけられるようにこのようにしています。

 

後はこれをやる時に、実際に動いているJenkins環境の JENKINS_HOME 以下を直接バージョン管理対象にしているのですが、ビルド時に作られるファイルなど設定だけを管理する上で必要の無いファイルは除外しています。

同じようにする場合の .gitignore ファイルのサンプルを置いておきますね。

.owner
jobs/*/builds/*
jobs/*/workspace/* 
jobs/*/lastStable jobs/*/lastSuccessful jobs/*/nextBuildNumber
logs/ war/ updates/ secrets/ fingerprints/ /*.log
Redmineと連携して設定のレビュー

ラウンドテーブルで挙がった「Jenkins設定が属人化されて1人しか触れない」問題に対しては、Redmine Code Review プラグイン( http://www.r-labs.org/projects/r-labs/wiki/Code_Review )を利用して、情報共有を行っています。

レビューチケット例 

f:id:sgtech:20160926170950p:plain

この場合の設定のレビューは、xmlファイルを比較したり確認したりする事になるので視認性は悪いですが、ある程度Jenkinsの管理に慣れてさえいれば、設定を差分で確認できる事の方がメリットが大きいです。

また、先の通りJenkins設定がバージョン管理されているので、レビューを回された当人の手元で該当バージョンの環境を再現する事もできます。

結果

このJenkins設定のバージョン管理とレビューの仕組みは、うちのチームに社内Jenkins環境サポート人員が1人増えて2人になったタイミングで導入しました。

該当プロジェクトのJenkins設定を把握してもらうのに、非常に効果的に働きました。

1人でJenkins設定の面倒を見ている場合でも、年単位で運用していると設定変更の経緯を忘れている事も多いので、本当にこれはやっておく価値があると思います。

最新の Jenkins 2 ではまた違ったアプローチも考えられますが、今日はここまで。

 

まとめ

という事で、CEDEC2016のフォローアップ記事+ちょっと突っ込んだ内容という形で、社内で実際に運用しているJenkins環境を2つ紹介しながら色々書いてみました!

 

ゲーム開発を支える技術ということでゲーム開発の技術そのものでは無いためちょっと興味から遠い方も多かったかもしれませんが、毎回執筆者も内容も変わる予定ですので次回をお楽しみにお待ちください!

技術ブログ始めます&CEDEC2016セガグループセッション紹介

セガゲームス、開発技術部の麓です。

本日からセガグループの技術ブログを開始します。

ここではセガグループの、面白そうな、役に立ちそうな、興味を持って貰えそうな。

そんな技術に関係する記事を月一程度の頻度で連載していきます。

 

先ずは第一弾、近々開催されるカンファレンス。

知る人ぞ知るCEDEC2016(2016年8月24日~26日)で、登壇(関係)者数15名に及ぶセガグループの社員が講演に関係するセッションの紹介をします!

※順不同

 

スマホゲームにおけるゲーム性と物語性の“運用で摩耗しない”基礎設計手法 ~チェインクロニクル3年の運用と開発の事例を交えて~ 【レギュラーセッション】
スマートフォンの国産ネイティブゲームにおける主流のゲームサイクル(キャラクターコレクションを中心に置き、イベント投下型の運営が行われるタイトル) において、あらかじめ用意されていたゲーム性と物語性は、運営における拡張の過程で、徐々にその価値を摩耗していくことが宿命づけられています。
本セッションでは、チェインクロニクルでも用いた「ゲーム性と物語性の摩耗を初期設計によっていかにして防ぐか」という手法について解説し、チェインクロニクルの初期開発および3年におよぶ運用における事例を交えつつ、汎用的な基礎設計指針を提示していきます。
株式会社セガ・インタラクティブ
松永 純
日時 : 8月24日(水) 11:20~12:20

 

技術から語る「龍が如く」の10年 ~ 今世代で何が変わるのか ~ 【レギュラーセッション】
10年の節目を迎えた「龍が如く」シリーズ グラフィックスと物理制御を中心に技術面での変遷を振り返り、どのような進化を遂げてきたのかを踏まえた上で、PS4専用タイトルとなる、最新作「龍が如く6(仮)」においてどのような新しい試みが行われているのかを紹介します。
株式会社セガゲームス
厚 孝 ・ 藁間 直弘 ・ 高木 英嗣
日時 : 8月24日(水) 11:20~12:20

 

龍が如く6における次世代神室町の作り方
龍が如く6における次世代神室町の作り方について解説するセッションです。
シリーズを通してメインステージとして登場し続けた神室町を次世代に向けてリニューアルするにあたって立てた構想と、実際に行った検証例、昨今のトレンドとなっている物理ベースレンダリングの導入、過去作から引き継いでいる経験と知恵などについて説明するセッションになります。
内製エンジンでの制作を行っているので内製エンジンで制作するメリット、デメリットなどについても触れられればと思います。
株式会社セガゲームス

濱津英二 ・ 中井友泰

日時 : 8月24日(水) 17:50~18:50

 

大量外部発注時代を乗り越える為の発注方法 【ラウンドテーブル】
ハードの性能があがり、求められる物量が大量になっていく中、内部制作だけではまかなえなくなり、外部発注の需要が高まっています。 外部発注の経験が深い各会社が「外部発注のノウハウ(独自の秘訣)」、「クオリティコントロールをどのように行っているか」「今後のベストな形」について具体例を交えながら紹介いたします。
株式会社セガゲームス ほか
木津 恵一 ほか
日時 : 8月24日(水) 14:50~15:50

  

プロダクションラウンドテーブル 【ラウンドテーブル】
プロダクション分野に関する、手法・技法にまつわる課題や解決事例などを共有するためのラウンドテーブルです。
CEDEC2016プロダクション分野定義: http://cedec.cesa.or.jp/2016/koubo/field.html#g02 
株式会社セガゲームス ほか 
粉川 貴至 ・ 竹原 涼 ほか
日時 : 8月25日(木) 11:20~12:20

 

Technical Artist Bootcamp 2016 vol.1 【レギュラーセッション】
前半:「プロジェクト配属型TAとしての働き方、組織活動の実例とツール開発のヒント」 弊社のアーティスト出身者で構成されるTAセクションの活動を例にプロジェクト配属型TAのプロジェクト内での活動とTA組織としてアーティスト全体へのフィードバック事例と組織で活動することの意味。
そしてMAYAのツール開発を例にアーティスト向けツールの開発、導入、普及、運用の取り組み方。 
株式会社セガゲームス セガネットワークス カンパニー ほか 
亀川 祐作 ・ 麓 一博(セッションコーディネートのみ) ほか
日時 : 8月24日(水) 11:20~12:20

 

MAKING OF "THE GIFT" ~ Unityを用いた高品質映像制作 ~
GDCで公開され話題になったMARZA製オリジナルショートムービー "THE GIFT"。このムービーは全てunityでシーン構築&画像出力されています。
本セッションでは、映像プロダクションである我々がunityエンジンを用いて、どのように映像制作に行ったのかをプロダクションの視点から説明します。
具体的には、プロジェクトの目的、ワークフロー、パイプライン、アセット作成、シェーダー開発、エフェクト開発の項目ごとに詳細を説明し 最後にまとめとして、本作品制作においてunityがどのようにパフォーマンスを発揮したか、逆にどの点で苦労したか 今後はどのような開発を進めていくつもりなのかをお伝えします。
マーザ・アニメーションプラネット株式会社 

加治佐 興平 ・ 守随 辰也 ・ 鴻巣 智 ・ 松村 知哉 ・ 松成 隆正 ほか

日時 : 8月24日(水) 13:30~14:30

 

CEDECに参加される皆様はもちろんのこと、CEDECを知らない方もこれを機に興味を持って技術共有と交流の場を大いに活用して頂けることを願っています。

それでは今月はここまで。

次回の更新をお楽しみに。

 

※複数社登壇の場合でもセガの社員のみ表記しています 

Powered by はてなブログ