Text Services Framework (TSF)

フルスクリーンでゲームを作る場合、IMEを制御して自動で表示されるものをすべて止めて、自前で描画する必要がある。

かなり昔に作ったことがあり、今回そのソースを移植して対応してみた。

一応動くようになったんだけど、その頃と違い最近は予測変換が表示されるようになっている。

このリストがうまく取得できない。

色々調べてみると、IME32は一度廃止された？されそうになった？がまた復活したという経緯があるらしい。

（個人のブログでIME32がなくなるから、今後は使えないというような記事を見つけた）

では新しいAPIは何になるのかというと、TSFというものらしい。

もしかするとこっちのAPIを使えば予測変換でも正しくイベントを受けられるかもと思い対応してみることにした。

TSF

Vistaの頃にできたものらしく、そこまで新しくはないAPIでCOMベースで作られているためかなり使うのにハードルが高い。

まったく知らなかった。

サンプルプログラムをダウンロードして実行してみるもいまいちよくわからない。

どうやら、TIP(Text Input Processor)を使う側と作る側両方のソースが含まれているようだ。

まずは個人で最低限のサンプルを載せてくれている人のソースをいくつか参考にしながら調査すると、ほんとの最小限は「ITextStoreACP」と「ITfContextOwnerCompositionSink」だけを実装すれば動くっぽい。

サンプルほぼ丸写しで実装してみた。

TextStoreはその名前の通り、EditBoxの持ってるテキストを管理するクラスという認識。

IME32の場合は、変換中の文字列だけが管理され変換後は別途管理が必要だったので一元管理できる分こっちのほうがいいかも。前後の文字列から変換結果を変えたり、変換済みの文字列を再変換できる機能があるからだと思われる。

内部で持つものは、「ITfDocumentMgr」「ITfContext」「ITfProperty」「ITfCategoryMgr」「ITfDisplayAttributeMgr」「ITextStoreACPSink」

これらは内部で保持せず、使うたびに取り出す実装になっているのも見たがどちらがいいのかは判断つかず。MS-IMEとGoogle日本語入力を切り替えてもそのまま使えているので、切り替えタイミングをイベントで受けて、そのたびに作り直しということもないので保持しておくことにした。

最後のTextStoreACPSinkというのがイベントを通知させるためのもので、これをAdviseSinkした人にイベントが通知される。

ここでややこしいのが、TextStoreACPSinkを受け取るのがTIPの本体の方で自分ではない。

MS-IMEやGoogle日本語入力がAdviseSinkをしに来るから、それらに対してこちらからイベントを通知してあげる側になる。

変換文字列

先ほどのTextStoreACPSinkとは逆で、今度はこちらがイベントを受けることにより変換文字列の変更通知を受け取れるようにする。

「ITfContextOwnerCompositionSink」を継承して、必要なイベント関数を実装する。

***SinkはAdviseSinkすると通知されるようになるはずなんだけど、これの為のAdviseSinkは見当たらない。CreateContextにITextStoreACP*として、自分自身を指定しているのでこれが代わりになっているのかも？

ここまでできるとImmGetCompositionStringの代わりができたことになる。

Property->EnumRangesで「IEnumTfRanges」を取得

EnumRanges->Nextで「ITfRange」を取得

Property->GetValueにRangeを指定して、「TfGuidAtom」を取得

CategoryMgr->GetGUIDにGuidAtomを指定して、「GUID」を取得

DisplayAttributeMgr->GetDisplayAttributeInfoにGUIDを指定して、「ITfDisplayAttributeInfo」を取得

DisplayAttributeInfo->GetAttributeInfoで「TF_DISPLAYATTRIBUTE」を取得

Range->QueryInterfaceで「ITfRangeACP」を取得

RangeACP->GetExtentで、変換中の区切り位置を取得

Enum分ループすると、それぞれのTF_DISPLAYATTRIBUTE.bAttrと、区切り位置で、変換中の文字列の区切り位置と属性が得られる。

変換候補

次に変換候補のリストを取得してみる。

メンバに「ITfUIElementMgr」を追加する。

イベントを受け取るためのインターフェース「ITfUIElementSink」を継承して、必要なイベント関数を実装する。

「ITfThreadMgrEx」からQueryInterfaceで「ITfSource」を取り出し、Source->AdviseSinkで自分自身を登録する。

BeginUIElementを受けた際、一緒に渡されるbShowにFALSEを返却すると、変換候補のWindowが表示されなくなる。

また、ルール通りにTIP側が実装されていれば、FALSEを返した場合即座にUpdateUIElementが呼ばれるらしい。なので、リスト取得の実装はUpdateの方にのみしておけばいいみたい。

このイベントが受けられるようになるとImmGetCandidateListの代わりができたことになる。

UpdateUIElementに渡されたElementIDを使って、UIElementMgr->GetUIElementで、「ITfUIElement」を取得

UIElement->QueryInterfaceで「ITfCandidateListUIElementBehavior」を取得

※未解決

Google日本語入力だと、予測変換のタイミングでCandidateListの取得は失敗する。

Tabや↓矢印キー押下後は普通に取得できる。

MS-IMEでは予測変換のタイミングで取得できる。

ただ、MS-IMEでは予測変換時でも先頭の項目が選択された状態になっているため、↓矢印を押下すると２番目の項目が選択されてしまい、どちらも微妙。

変換候補を画面表示した状態であれば未選択状態になっており、↓矢印選択時に１番目が選択状態になる。これと同じ挙動にしたいが、やり方がわからず。

CandidateListUIElement->GetSelectionでリストの選択位置を取得

CandidateListUIElement->GetUpdatedFlagsでリストの前回からの変更点を取得

CandidateListUIElement->GetCurrentPageでリストの現在のページ番号を取得

CandidateListUIElement->GetCountでリストの項目数を取得

CandidateListUIElement->GetStringでリストの指定インデックスの文字列を取得

今のところ、UpdatedFlagsで取得した値が「TF_CLUIE_COUNT | TF_CLUIE_STRING」の時に、リストをすべて取り直すようにしている。

GetPageIndexを使えば、現在のページのみに絞れるためこっちを使った方がいいかも。

変換モード

通常タスクバーに埋まってる「A」とか「あ」とかの状態を取得する方法

変換モード

これがなかなか見つからなくて1週間くらい探してやっと見つけた。

メンバに「ITfCompartmentMgr」を追加する。

イベントを受け取るためのインターフェース「ITfCompartmentEventSink」を継承して、必要なイベント関数を実装する。

登録は、CompartmentMgr->GetCompartmentで、「ITfCompartment」を取得

Compartment->QueryInterfaceで、「ITfSource」を取得

Source->AdviseSinkで自分自身を登録するという流れ。

ただ２回行う必要があって、1つ目のGetCompartmentはGUIDにGUID_COMPARTMENT_KEYBOARD_OPENCLOSEを指定する。2つ目は、GUID_COMPARTMENT_KEYBOARD_INPUTMODE_CONVERSIONを指定する。

1つ目はIMEのOpenとCloseのタイミングを得るためで、ImmGetOpenStatusの代わりになるもの。

2つ目は、ImmGetConversionStatusの代わりになるもの。

ちょっと癖があって、Close状態でも変換モードは直前のものが取れてしまうため、自分で「A」にする必要がある。Open状態はInputModeの値をそのまま使えばいい。

取得できるEnum値はTF_CONVERSIONMODE_*で、IME_CMODE_*と同じ値らしい。

これでImm系の関数を一切使わず、TSFに移行できた。

当初の目的の予測変換のタイミングについては、MS-IMEについては完ぺきに取得できるようになったが、候補リストの先頭が選択されている状態になっている問題は残っている。

Google日本語入力に関しては、予測変換が表示されるタイミングでOnUpdateUIElementは呼び出されはするが、候補リストを取得できない問題が残っている。

1/22追記

変換候補については、自前で描画せずに任せることにした。変換中は別Windowsが表示されることになるが大した問題ではないと思うことにした。

変換候補に実際は描画しない文字列もたくさん含まれているため、描画用のテクスチャがどんどん消費されていくのも防げる。

ItextStoreAcp::GetTextExtの引数に渡されるRECT型の変数に、変換中の矩形をスクリーン座標で返すと変換候補の画面を出す位置を調整してくれるようになる。

似たような関数でItextStoreAcp::GetScreenExtがあるが、面倒なので同じ座標を返すようにしている。今のところ不都合は発生していない。

International Components for Unicode (ICU)

Windowsで文字列を扱う際UTF-16を使っているが、ユーザ入力データを扱う場合まともには扱えないということがわかった。

サロゲートペア

UTF-16でも１文字は２バイトで表現しきれないので、サロゲートペアという苦肉の策が取られた。

これは今までのShiftJISなんかと同じで、最初のコードがこの範囲ならその後も含めて１文字と表すような感じで、ありがたみがない。

ただShiftJISと違って普段使うほとんどの文字は２バイトで表せるため、仮にサロゲートペアに対応してなくても不具合が顕在化しない場合もある。

内部処理的には問題はほとんど起きないが、文字数を制限するような場合に問題になる。

サロゲートペアが文字列中に含まれていると、含まれている文字数分文字数が増えてしまう。

１０文字制限の場合、サロゲートペアが１文字含まれていると９文字入力した時点で制限にかかってしまい、ユーザの見た目とギャップが生まれる。

また、EditBoxなどに任せずに自前で１文字ずつ追加、削除をする場合、サロゲートペアを考慮してない場合は上位のみ削除して下位が残ったままだと表示に影響が出る。

サロゲートペアだけであれば、適切に範囲チェックを行い、文字数のカウントもサロゲートペアを考慮してやれば比較的簡単に対応できる。

ただ問題なのが結合文字や絵文字だ。

結合文字　合字　絵文字

例えばMS-IMEで、「あ」を入力して変換確定後、続けて「３０９９」と入力してF5を押下すると、「あ」とこのコードが合体して「あ゙」となる。

合体させるのはいくらでもよくて、ここに書かれているようなコードを何回も同じように付け足すと、どんどん付け足されて1文字扱いとなる。

この仕様はやばい。

どうやら、単純なルールは存在せず、ここに書かれていることをすべて理解して実装すれば文字の区切り判断はできるらしい・・・が、そんなことやってたら時間が足りないし、今後も仕様が追加されていくので実装しきれない。

ICU

というわけで、ICUというライブラリの出番。

この中のICU4CというのがC/C＋＋用のライブラリなのでGitHubからVisualStudioで開いてみた。

allinoneというソリューションを開いてビルドすると何やらいろいろビルドされた。

やりたいことは「書記素単位で文字を取得する」ということになるので、インクルードファイルは「ubrk.h」、ライブラリは「icuuc.lib」でコンパイルは通った。

早速動かしてみると、「icuucNN.dll」がないと怒られる。

（NNはバージョン。試したときは74）

binから持ってきて再実行すると、「icudtNN.dll」がないと怒られる。

binから持ってきて再実行すると、U_MISSING_RESOURCE_ERRORというエラーになる。

icudt.dllはunicodeのデータが入っていて、本来は20MBくらいあるみたい。

自分の環境で出来上がったファイルは3KBしかなく、中身がなさそう。

どうやったら中身がある状態でビルドできるのかわからなかった。

ファイル指定もできるらしく、chromiumとかに含まれているicudt.datとかがおそらくこれのことっぽい。icudt.datを配置してu_setDataDirectoryで指定してみたけどうまく動かなかった。

次に試したのがnugetにあるicu4cのライブラリ。

古いものしかなくて一番新しそうな58というのをインストールしてみた。

こっちは問題なく動いた。icudt58.dllのサイズは１９MBぐらい。

さらに調べてみると、Windows10以降にはマイクロソフト版ICUが含まれているらしい。

何も入れる必要ないみたいだ。

早速、インクルードファイル「icu.h」、ライブラリファイル「icu.lib」で試したら問題なく動いた。

「あ゙」はもちろん、「👨‍👩‍👧‍👦」も１文字として判定できるようになった。

対処してないと、「あ゙」は２文字、サロゲートペアを考慮しても２文字、「👨‍👩‍👧‍👦」は１１文字、サロゲートペアを考慮しても７文字として判定されてしまう。

DirectX12 DrawText

DirectX12で文字描画する場合、最初に見つけた方法がID3D11On12Device経由でDirect2D/DirectWriteを使って描画するというもの。

最初はこの仕組みで満足していたんだけど、マルチスレッド対応とちゃんとしたダブルバッファリングの仕組みに変えてから、11on12を捨てたいと思うようになった。

マルチスレッドとダブルバッファリング

マルチスレッド＆ダブルバッファリングで完全にCPUとGPUを並列に処理できるようになった時、Direct2D用の描画が気になるようになってきた。

描画コマンドはすべて別スレッドでコマンドリストに書き込むようになっており、メインスレッドの利用を極力抑えるようにしているが、Direct2D部分はマルチスレッド対応以前のメインスレッドが描画コマンドを発行する仕組みのまま。

いまはFPSぐらいしか表示してないので特に影響はなさそうだけど、大量の線、矩形、文字列を描画するような時に問題になってくると思われる。

フォントテクスチャ

というわけでDirect12だけにして、11on12はやめることにした。

といっても、文字描画の仕組みがなくなってしまうので裏でDirect2D/DirectWriteの仕組みで文字列を描画して、結果のビットマップをテクスチャにして表示してみようと思う。

DirectWrite版フォントテクスチャ

Direct2DのID2D1RenderTargetクラスにCreateWicBitmapRenderTargetという関数があったのでこれを使って文字描画したビットマップを取得してみる。

途中ハマったことは、IWICBitmap::CreateBitmapのピクセルフォーマットの指定。

最終的には、GUID_WICPixelFormat32bppBGRを指定してうまく行ったけど、アルファ付きに出来ない。アンチエイリアス部分が背景色に影響して結果が変わってくる。

下記は取得したビットマップの背景色を透過させてPNG保存した画像。

背景黒

背景色が黒だとアンチエイリアス部分に水色や茶色などが使われている模様。

グレースケール

SetTextAntialiasModeをD2D1_TEXT_ANTIALIAS_MODE_GRAYSCALEにすると想像していた結果になった。D2D1_TEXT_ANTIALIAS_MODE_CLEARTYPEの方が見た目がいいんだろうけど、加工する場合はこっちのほうが使いやすい。

背景緑

背景を真緑にして、透過色として識別しようと思ったらこんな結果に。

透過を意識したデータを作れないので、これを使う場合はグレースケールになるかな。

GetGlyphOutline版フォントテクスチャ

昔、DirectX9とか？でID3DXFontが遅かった時代に使われていた手法で、GetGlyphOutlineを使ってフォントテクスチャを作って文字を描いていたらしく、この方法でも試してみた。

取得できる値は指定したクオリティのグレースケールのビットマップ。

これをアルファ値として別途真っ白のビットマップとして保存してみた。

GGO_GRAY2_BITMAP

GGO_GRAY4_BITMAP

GGO_GRAY8_BITMAP

それぞれの処理時間の違いは、ほとんどなさそう。0.2～0.9msとぶれ幅が大きいけど、大体が0.3ms前後だった。

これなら常にGGO_GRAY8_BITMAPで良さそう。

フォント作成時、CLEARTYPE_QUALITY、CLEARTYPE_NATURAL_QUALITYを指定するとClearTypeも使えるっぽい。ただ、CLEARTYPE_QUALITYはほとんど処理速度は変わらなかったけど、CLEARTYPE_NATURAL_QUALITYにすると約２倍になった。

比較

フォント品質

Direct2D版の方が見た目がきれい。アンチエイリアス部分に別の色が入るとキリッとする。ただ、取得したデータをキャッシュして色をシェーダ側でつけるとなると、グレースケールにすることになるので差はほとんど無くなる。GetGlyphOutlineは純粋に白のデータにアルファ値だけのテクスチャが作れるため、こちらの方が使い勝手がいい。

処理速度

２文字の場合、Direct2Dが1.5ms(1.2ms)に対して、GetGlyphOutlineは0.3ms。

２０文字の場合、Direct2Dが1.5ms(1.2ms)に対して、GetGlyphOutlineは1.0ms。

※Direct2Dのカッコ内はグレースケールの処理時間

Direct2Dの方はこの程度の文字数の差によって速度は殆ど変わらなかった。

GetGlyphOutlineは文字が増えると処理時間も線形に延びていく。

どちらの仕組みでも、毎フレームのテクスチャ生成は現実的ではなさそう。

数字、アルファベット等よく使う字は予め生成し、ほかは逐次キャッシュしていく仕組みにしたり、ゲーム内で使う文字列をローカライズファイルに纏めておいて、そこから使ってる文字のテクスチャを事前生成するなど工夫すれば速度に関しては問題なさそう。

フォントテクスチャ作成

文字のビットマップを取得する

TEXTMETRIC oTM ;
::GetTextMetrics( hDC, &oTM ) ;

GLYPHMETRICS oGM ;
const MAT2 oMat = {{0,1},{0,0},{0,0},{0,1}} ;

tWC c = L'漢' ;
auto nSize = ::GetGlyphOutline( hDC, c, nGradFlag, &oGM, 0, nullptr, &oMat ) ;
tBin oData ;
oData->Resize( nSize ) ;
::GetGlyphOutline( hDC, c, GGO_GRAY8_BITMAP, &oGM, oData.Count(), oData.Val(), &oMat ) ;

TEXTMETRICとGLYPHMETRICを使って、テクスチャに書き込みと描画する際の頂点データ用の値を準備する。

フォントのサイズについて

TEXTMETRICとGLYPHMETRICの関係図

一般的なフォントサイズといえばtmHeight。

それが、青い線（ベースライン）を挟んで、tmAscentとtmDescentに分かれる。

ビットマップの画像はgmBlackBoxX、gmBlackBoxYのサイズで返却される。

ただし、返却されたメモリの横幅は４バイトアラインになっているため、4の倍数に補正する必要がある。

（例えばgmBlackBoxX=7の時、メモリの横幅は8となる）

auto w = oGM.gmBlackBoxX ;
auto nMask = a-1 ;
w = ( w + nMask ) & ~nMask ;

テクスチャの書き込み座標

最初の文字のX座標は０。次の文字はgmBlackBoxXをインクリメントしていく。

テクスチャの横幅が残りtmMaxCharWidth分ない場合は次の行に改行して０にリセット。

Y座標は、行数にtmHeightを掛けたものが基準。

その基準にtmAscent - gmptGlyphOrigin.yを足した位置が書き込み位置となる。

頂点座標

配置位置（＝基準）にgmptGlyphOrigin.xを足す。注意点は、例えば一番最初の文字がｊの場合、上図のようにgmptGlyphOrigin.xがマイナスになっている（前の文字に重なる）

必要に応じて位置を補正する

テクスチャの横幅はgmBlackBoxXなので、その分の幅を取る。

次の文字の開始位置は基準からgmCellIncX行ったところとなる。

高さは常にtmHeightで処理する。

パフォーマンス

横４００文字、縦１００行、計４万文字を表示してみたところ、FPSが20ぐらいになった。

試しに同じ条件でDirect2Dで描画すると60FPSで表示される。

文字列は１行0～9を４０回繰り返した文字列を１００行分表示している。

おそらく、１００行分同じ文字列なのでうまく使いまわしているのかもしれない。

そこで全行ランダムにして表示するようにしたらDirect2DでもFPSが３０まで落ちた。

パフォーマンスチューニング１

頂点バッファをx,y,u,v,r,g,b,aで作って１文字４頂点１セットでバッファを毎フレーム書き込んでいる。インデックスバッファは適当な文字数分予め用意しておき、足りなくなったらまたある程度余裕を持たせて作成するようにしていた。

１文字のデータはfloat(4byte)✕８✕４＝１２８byteとなっているため、これを減らそうと考えた。

頂点バッファを渡すのをやめて、構造化バッファを渡して頂点シェーダ内で位置、UVを作ることにした。色に関しては一旦保留。

構造化バッファで渡す値は、x,y,w,h,u,v,uw,vhで、１文字のデータはfloat(4byte)✕８＝３２byteとなり１／４に削減した。

結果、FPSは２５に上昇したけどまだDirect2Dに負けている。これなら新しい仕組みにする意味がない。

パフォーマンスチューニング２

渡しているx,yはディスプレイの座標なので、unsigned shortで問題ない。

また、w,u,vはフォントのマスタ情報を別途構造化バッファで作って、そのインデックスを指定するようにすれば、１つのunsigned shortで表現できる。

パフォーマンスチューニング１では、色を一旦保留にしたが、色マスタ情報作って同様の考え方にすれば１つのunsigned shortで表現できる。

というわけで、x, y, no, colとなり、１文字のデータはunsigned short(2byte)✕４＝８byteで更に１／４となり、色情報も追加できた。

結果、FPSは３０に上昇し、ほぼDirect2Dと同じになった。

追加の検証で、１行の文字列をまとめて描画ではなく１文字づつ描画するように変えてみた。

Direct2Dは３FPSとなり、１／１０に落ちた。

新しい仕組みの方は１２FPSでDirect2Dの４倍で動いてる。

Releaseビルドならこの状態でも６０FPSでてる。

限界を探るため、今度は色をすべての文字でランダムにすると２５FPSとなった。

色マスタ情報が大きくなり毎フレームの更新に負荷がかかるのだろう。

色数が多すぎる場合は、使う色を限定化してマスタの更新をなくせばこの状態でも問題なく動きそう。

結果的にドロ－コールを１００回呼び出しで比較するとほぼ同じ速度で、４万回呼び出す場合は、マルチスレッド対応されている新方式の方が速くなった。

サロゲートペア対応

実装している最中気になっていたのが、サロゲートペアについて。

GetGlyphOutline関数に渡す値が１文字分のコードなので、サロゲートペアの場合だめだろうと思っていた。

サロゲートペアといえば「𩸽（ほっけ）」なので文字列に指定してみる。

Direct2Dでは問題なく表示されるが、GetGlyphOutlineでは中点が２つが表示される。

GetGlyphOutlineのコードを渡す型が32bitなので、まとめて渡してみてもだめ。

調べてみると、GetCharacterPlacement関数でGlyphIndexというものを取得して、GlyphIndex指定でGetGlyphOutlineを呼び出せば取得できるらしい。

tStr s = L"𩸽" ;
tWC nBuf[2] ;
GCP_RESULTS oGR = {} ;
oGR.lStructSize = sizeof(oGR) ;
oGR.lpGlyphs = nBuf ;
oGR.nGlyphs = 2 ;
::GetCharacterPlacement( hDC, s, oGR.nGlyphs, 0, &oGR, GCP_GLYPHSHAPE ) ;

関数がうまくいくと、oGR.nGlyphsは１になり、nBuf[0]にGlyphIndexが入っている。

GetGlyphOutline関数に渡していたGGO_GRAY8_BITMAPをGGO_GRAY8_BITMAP | GGO_GLYPH_INDEXに変えて、文字コードを渡していたところにGlyphIndexを指定するとサロゲートペアのビットマップが返ってくるようになった。

なんと読むのかもわからない文字だけど混在していても表示できている。

Motion Blend

今回はモーションブレンドをやってみる。

アニメーション

FBXをAssimpで読み込む際、アニメーションを含むメッシュの場合は一緒に読み込んでいる。

各アニメーションはそれぞれ切り替えれば作られた通り動きはするんだけど、アニメーションを切り替えた際、その前の姿勢を無視して切り替えたアニメーションIDの再生が始まるため、ものすごく不自然になる。

歩き⇔走りの切り替えアニメーション

Unreal Engineでゲーム制作をしている人の動画を見ているとき、２つあるアニメーションを混ぜて１つのアニメーションとして利用していた。

そんなことができるのかと驚いた記憶がある。

この仕組みを使えば、あるアニメーションから別のアニメーションへの切り替えもスムーズに行えるはず。

モーションブレンド

FKアニメーションの仕組みで、アニメーションのある時間の状態を作る際、前後の確定したキーフレームから、位置、スケール、クォータニオンのベクトルを取り出して線形補間をしている。

この処理がモーションブレンドなんじゃないか？

実は既に似たようなことはやっていたのか。

現在のアニメーションの補間されたベクトルと、切り替えるアニメーションの補間されたベクトル同士を補間すれば期待した動きになると予想。

ブレンド結果

あっさりうまく行った。

ただ、切り替えのタイミングによってはぎこちない場合もあったりする。

この辺はアニメーション同士のつながる位置のオフセット情報を設定できるようにしたりすれば常にきれいにつながるような気がする。

Particle5 Trail

前回に引き続きパーティクルの拡張をする。

今回は、トレールのメッシュを追加する。

トレールメッシュ

今までのメッシュはVertexBufferに書き込んで、そのあとメッシュデータを書き換えることはしなかった。

トレールメッシュの場合は毎フレーム書き込むため、今までの仕組みとは別にする必要がある。

通常のパーティクルは１つのオブジェクト＝１パーティクルに対応しているが、トレイルの場合はどうしようか悩んだ末、複数オブジェクト＝１パーティクルとした。

複数のオブジェクトはトレイルの軌跡を表す位置として利用する。

パーティクル内の複数データの管理は今まで名称で行ってきたけど、これは最初に考えたキャラクタ管理用のデータだったから。

ただ、パーティクルでもそのまま使っていたけど、ユニークな名称にする必要があるし、そもそも名前で管理してもあとから名前で参照することもないしメモリが無駄になる。

また、トレールの場合データのインデックスが重要になってくるが、今のデータ構造だとインデックス順に取り出すことが出来ないため、管理方法を変えることにした。

いろいろ考えた結果、Listで管理することにする。

トレールの場合、オブジェクトの追加を先頭にしていく必要がある。

Vectorだと追加の度にデータ全体をずらす必要が発生するためListのほうが都合がよい。

ただ、データの参照に不安が残るが、実際参照する場面では先頭から順番にアクセスする使い方しかないため問題にならなさそう。

頂点データを順番に、とりあえずy座標を-0.5、+0.5したものを並べていく。

表示してみると、なんとなくうまく行っているように見える。

しばらく動かしてみると、当然のことながら上下から見ると完全に見えなくなる場所が出てくる。

トレールのビルボード

視線のベクトルと、ノード間のベクトルの外積を使えば視線とトレールの線に直交する方向が得られるので、それに幅を掛けて＋とー方向に足せばいい。

視錐台カリング

通常の仕組みに乗せて、各点単位に視錐台カリングを行う。

頂点バッファを作る際に、すべての点がカリング対象になっていたら描画をスキップする。

ホーミングレーザ

仕組みが出来たので、ホーミングレーザを作ってみる。

昔、Catmull–Rom Spline補間でレーザの軌跡を作ったけど、今回はこの記事を参考した。

パーティクルオブジェクトの位置を、この計算式で算出して追加するだけで、予定時間にその点を通るような加速度を算出してくれる。

予定時刻を過ぎたら、１秒間で徐々にアルファを０にして消す。

実際には命中して爆発などを起こすんだろうなぁ。

初速は視線のベクトルで、２秒後に赤い四角の的を射抜くホーミングレーザ。

Particle4 オーラ

前回に引き続きパーティクルの拡張をする。

今回は、円柱のメッシュを追加する。

円柱メッシュ

円盤と違って、円柱の場合は特に悩むことなくUV展開は出来そう。

矩形を円の分割数分つなげるだけ。

円柱

特に悩むことなくあっさり出来た。

上を広くした円柱

上を狭くした円柱

パラメータを追加して、上の半径を調整できるようにした。

オーラっぽい効果

魔法陣＋オーラ

２つの円柱を、前回作った魔法陣に重ねてみた。

シェーダ

float2 uv = In.UV + float2( -0.7 * In.UV.y, 0.0 ) ;	// ひねり
Out.Col = Tex.Sample( Sampler, In.UV + float2( 0.0, Param.Time )) ;
float mask = ( sin( ( uv.x + Param.Time*0.5) * 8 * 3.1419 )+1 + cos( ( uv.x + -Param.Time) * 2 * 3.1419 )+1  ) * In.UV.y ;
Out.Col = pow( Out.Col, 1.25 ) * mask ;
Out.Col *= In.Col ;
Out.Emissive = Out.Col ;

Particle3 魔法陣

前回に引き続きパーティクルの拡張をする。

今回は魔法陣の演出をやってみたい。

円盤メッシュ

まずパーティクル用メッシュに用意したのは矩形メッシュ。

今回はこれに加えて、円盤のメッシュを追加しようと思う。

ただ、今まで円盤のメッシュを扱ったことがない。

やりたいことは、テクスチャの画像が円に沿ってぐるっと張り付いて、UVのU方向のスクロールが回転、V方向のスクロールが中心に吸い込まれていく感じに動いてほしい。

円盤のUVの展開について色々調べたけど全然見つからなかった。

仕方がないので自分で考えた方法がこれ。

UV展開図

円の分割数を指定すると各頂点の位置を計算する。

x = cos( i ÷ 分割数 ✕ ２π )　※ i は0～分割数までのループカウンタ

y = sin( i ÷ 分割数 ✕ ２π )

u = i  ÷ 分割数

この図の場合、分割数３で中心に点０、UVは点０が一番上の中心。

そこから半径 (x,y) ✕ 0.5の位置に点２、(x,y) ✕ 約１０％の位置に１の点を置く。

Vは点２が１、点１が上から約１０％の位置。

後は分割数分ループする。

謎のエネルギー

とりあえずはメッシュにテクスチャを貼り付けて確認してみる。

セルラーノイズにフラクタルノイズを掛けたもの

まずノイズテクスチャを用意する。

円盤メッシュにテクスチャ展開

メッシュに貼り付けた結果。

なんかうまく行ってるっぽい。

マスクイメージ

上記にこのマスクを掛けて

ひねりを加えるとこうなって

色をつけたらこうなる。

最後にUVスクロールでvのマイナス方向に動かすとこんな感じになった。

シェーダ

float2 uv = In.UV + float2( -0.7 * In.UV.y, 0.0 ) ;	// ひねり
Out.Col = Tex.Sample( Sampler, uv + float2( 0.0, -Param.Time )) ;	// マイナス：外側 / プラス：内側
float mask = ( 1 - cos( In.UV.y*2*3.14159265 )) * 0.5 ;
Out.Col = pow( Out.Col, 1.25 ) * mask ;
Out.Col *= In.Col ;
Out.Emissive = Out.Col ;

魔法陣

魔法陣テクスチャ

絵かきツールで適当に画像を用意して、背景をアルファ０になるようにして保存。

シェーダ

Out.Col = Tex.Sample( Sampler, In.UV + float2( Param.Time*-(( step( 0.5,In.UV.y ) + step( 0.5,In.UV.y ) - step( 0.75,In.UV.y ))*2-1)*0.1, 0.0f )) ;
Out.Col *= float4( 0.25f, In.Col.gba ) ;
Out.Emissive = Out.Col * 2 + In.Col.r * float4(1,1,1,1) ;

３つの階層に分かれているので、中心を時計回り、真ん中を反時計回りで高速、外側も反時計回りで低速で回すようにしてみた。

あと、出現時にEmissiveを最大にして光らせるようにした。

更新関数から受け取るrの値で制御している。

魔法陣