『Ｌｉｇｈｔ　Ｗｏｒｋｓ』

正直自分で作っておいて、しょうもないもん作ったなと言う感想だったりします。
ミク自体をMMDの物理演算で髪の毛とかふわふわ動かしたらかなり良い感じになるかと思いますが、本来は単純にAEで大昔に作ったエクスプレッション用の三角関数を手直しして組み込むテストのつもりでしたので、まぁこれで良いかなと。
三角関数とは言っていますが、実はどの動きもsinのみで動作させています。
cosはsinの90°位相ですし、tanはちょっと扱いづらいので、ゲームの動きなんかは良くsinをベースに作られる事が多いです。
シューティング等は昔は有機的な動きは三角関数で作る事が多かったので、結構そう言うのを見るとニヤッとさせられたりします。



さて、この動画の種明かしは簡単です。
☆の一つ一つにabsolute(吉里吉里で言うindex)を設定させてあり、特定の条件下（この場合は画面中央より上か下か）でそれをキャラの手前か奧かに切り替えているだけです。
こう言うのはAEで動画を作るよりTJSでクラスを作ってしまう方が楽です。
AEは使ってるとわかるのですが少し変わったところがあって、一見簡単そうな事程恐ろしく手間が掛かったりします。
今回のこれもそうで、キャラを中心に立たせるために手前と奧に分割して動画を作ろうとすると上手くいきません。
☆の一つ一つを手動で動かせば可能ですが、膨大な手間が掛かる上に手直しや微調整にさらに膨大な手間が掛かります。

こう言うエフェクトは魔法少女物とかで使えるので、面倒でも作っておけば後々いくらでも役に立ちます。

某所でこう言う質問が出てましたのでお答えしておきます。
ぶっちゃけ分かってしまうとなんだと言う程度の事です。
答えは[wv]タグを書かない。これだけです。
[wv]は処理待ちをするタグですので、それを書かない事で再生終了を待ちません。
むしろこれを知らないとloopパラメータでハマります。いつまで経っても次に進みません。事実上loopパラメータが死にパラメータになります。
初心者はもちろん、逆にきっちりと[wt]等をお約束と理解して必ず表示タグとセットとして考えてる人がはまりやすい部分です。

ここのところちょっと忙しくて、更新遅れています。
次回は、最近のゲームで定番と言っても良い画面外からスライドしながらじわっと現れるカットイン的なアレをマクロ化しましたので、それを公開しようかと思ってますが動画が準備出来ていません。orz
近いうちに公開予定ですので、お待ち下さい。

この時期は例年なら図書館通いで本を読み漁ってる時期なのですが、なかなかそれもままならない状況です。
あの少しかび臭い古書の匂いは大好きでとても落ち着くのですが、ついつい眠くなってしまうのが欠点ですね。
そういえばうちが書く話しの中で映画の話題が登場すると、恋愛物の代表作として真っ先に登場するのは決まって「ノッティングヒルの恋人」(Notting Hill)です。
ロンドン西部のノッティングヒルで小さな古書店を営んでる冴えない主人公が、ハリウッド女優と出会って恋に落ちると言うあり得ないシチュエーションの話しです。
現代版ローマの休日とも言われてた作品で、シチュとしてはあり得ない故にゲーム向けのシチュかなと思います。
展開は映画としてはオーソドックスでベタですが映画好き”なら”楽しめる話しです。
主題歌のエルビス・コステロの「Ｓｈｅ」はＴＶＣＭ等でも結構頻繁に使われてますので、そちらの方が有名かも知れません。
ただこの曲は、日本ではコステロで有名になった曲ですが、原曲はシャルル・アズナブール。　ガンダムファンの間では比較的知られてる方で、シャアの名前の元ネタになった方です。
このＳｈｅと言う曲はとても美しい曲で、古典的な叙情詩の形で韻を踏みつつ彼女への想いを切々と語っています。
私みたいな英語音痴にもその歌詞を見ただけでその美しさに惹かれます。
ネットには幾人かの方が翻訳されてらっしゃいますので興味が有れば一度原文と一緒に見てみるのも面白いと思います。

さてこのノッティングヒル、女性はこう言う恋愛物好きなんだろうなと思ってそう言う話を何度かした事あるのですが、どうもこの映画に関しては反応はマチマチでした。
何人かの女性の話しを要約すると、ダメ男や気弱な男が好きな女性や母性が強いタイプには向いてるけど、男に現実を求めるタイプの女性には全くつまらない映画だそうです。
なるほどと妙に納得しました。
そういえばいつの頃からでしょうか、ハリウッド映画で妙に強い女性が主人公の話が席捲し出したのは。
男子の草食系が増えたからでしょうか？それとも女子の肉食系が増えたからでしょうか？

セーブロード関係への対応をコメントアウトしてました(;^_^A ｱｾｱｾ･･･
しかも微妙にセーブロード関係でバグってました。
修正して、お詫びに簡単に扱えるようにマクロを組み込みました。
first.ksに動作させた物、pict_seamless.ksの後ろの方にマクロエリアがあります。
両方を参照してください。
1つ前のエントリーもすでに修正済みですが、こちらpict_seamlessからＤＬして頂いても同じ物がＤＬ出来ます。
不具合等ありましたら、ご連絡下さい。

pict_seamlessです。
具体的には上下左右を連結して動かすプラグインです。
元々パノラマ画像をグルグル回す用に作った物を整えただけなので、かなり使い勝手は悪いと思います。
最低限読み込む画像をf.ps_storage[チャンネル] ="ファイル名"で指定して、表示するレイヤーをf.ps_layer[チャンネル] = "レイヤーナンバー"で指定して、pict_seamless.start(チャンネル)で動かします。
止める時はpict_seamless.stop(チャンネル)でその場で止まります。
チャンネルは0～4があり、通常0にしておけばokです。色々なチャンネルを食い散らかすと、作業用のレイヤにはチャンネル毎に最後に読み込んだ画像を消さずに残してありますのでその分メモリを喰います。
そんな時は動いてない時にpict_seamless.cls()を実行して下さい。この場合チャンネル番号は不要です。作業用の”全ての”レイヤーを捨てます。
それと注意が一つ。f.ps_layer[チャンネル] = "レイヤーナンバー"で、レイヤーナンバーは" "か' 'で数字を括って下さい。文字列として渡さないと誤動作が起きる可能性があります。これは吉里吉里の仕様です。(べ、別に数値受け渡しの時にstringで括り忘れたわけじゃないんだからね！)
またレイヤーはfreeimageなどでクリアされた状態の物を直接指定すると、これも吉里吉里の仕様上画面サイズが取得されません。出来るだけスクリプト側でコントロール出来るようにわざと取得しない仕様にしてありますので、適当なサイズの画像をダミーでvisible=falseで事前に読み込むか、透明なレイヤーを読み込んで対処してください。

《言い訳タイム》
方向変更はフラグに方向を代入して、そのたびに初期位置をリセットしています。
なめらかにリアルタイムで変化させるには、以前似たような物を作った時におそろしく複雑な構文になってしまった挙げ句ちょっとしたバグでも原因特定がとんでもなく困難だった経験があり、ちょっとしたトラウマで今回はパスしました。orz

改変などは自由に行ってください。たぶんそのままだとマクロも組んでいないので使いづらいと思います。

このたびは大地震に遭われた皆様、本当に心からお見舞い申しあげます。
頑張ってと言う言葉はこれまでも何百回もかけられてる事でしょうし、これ以上頑張りようが無い状況かと思いますので、「早く笑えるようになって下さい」と一言のみを添えたいと思います。

さて業界に目をやると、関東以北はかなり停滞しているようです。
茨城等に本社を置かれてらっしゃる会社様などは人的被害は無かったと言うお話しでほっとしましたが、機材やライフラインなどかなり動きが取りづらいご様子。
その中でも、自分達がやるべき事はゲームを作って笑顔を作る事と言う信念で仕事をなされてる姿はとても見習うべきところが多いと思います。
都内のいくつかの会社様の方も、棚の物が落ちて怪我をされたと言う方がいらっしゃいましたが、ほとんどの方は無傷でまずは安心しました。
ただ、揺れの恐怖・いつ停電するかわからない不安・交通手段の問題等まだまだ予断を許さない状況が続いていらっしゃるようで半分機能していない状況と伺っております。
また今回の震災で仙台のデュプリ屋さんが被害に遭われたとの事で、かなりの会社がそこで焼いていた関係で発売延期となった商品も多いとか。
さらに追い打ちをかけるように夏も電力不足により輪番停電予定などもあり、かなり制作が厳しくなっていると言う事でした。
関西以南では震災後の最初の月曜から通常通りの仕事はしていたと言うお話しは聞きますが、営業の方はさすがに止まっていると言うお話しも伺いました。
ただ、関西以南の外注は逆に仕事が増えたと言うお話しも聞きますし、業界全体としては騙し騙し動いてるのかなと思います。

なんにしても色々な場所で自粛自粛と言われている状態が延々続いています。
自粛しないと不謹慎と叩かれるご時世ではありますが、このままこんな事が続いてると日本全体が完全に傾いています。
こう言う業界は、社会が健全に機能して始めてなりたつ業界ですので、逆に派手に動いて社会に活気を持たせるような事が出来ないだろうかと考えてしまいます。
一人の力じゃ難しいですが、業界全体でお祭りみたいにぶち上げてもいいんじゃないだろうかと思うのですが如何なものでしょう？

世はいつの間にか春。
なんだか最近変に忙しくて、更新が遅れてます。
何も書かないのもあれなのでいつもの映画の話しを。

ミュージカル映画っぽいのばかりご紹介してるので、たまには少し毛色の変わったものを……と言うわけで、今回のお題は「コンタクト」(contact)です。
カール・セーガンと言うNASAの元科学者で小説家の同名作品の映画化したものです。
物語の作りとしては、かなりリアリティを追求していて当時のアメリカ大統領のクリントンの会見映像を使って物議を醸し出した事でも有名です。
SETI計画の研究者のエリー（ジョディ・フォスター）はあるとき知的生命体からと思われる電波をキャッチする。
その電波がなぜ知的生命体からと分かるのかとか、どう言う内容だったかが前半のキーポイントで実にSF的にリアリティがある作りになってます。
その電波の内容を精査した結果、地球外の現在の地球以上の知的水準にある生命体からのメッセージと結論付けた米国政府はその電波の中に含まれていた設計図を元に全世界的超国家プロジェクトでよく分からない物を制作する事を呼びかけるのですが……
この物語が他のSFと大きく違うのは、このあたりから話しがおかしな方向へと向かいます。
謎の設計図によるわけのわからない建造物の設計と言うSF色を残しつつ、「人類は神に選ばれた唯一の存在」とするキリスト教系の信徒が一斉に計画の中止を求めてデモを行ったりしはじめ、また地球外に存在すると言う事実自体がでっち上げと市民は語り始め、そのプロジェクトで建設している建造物――たぶんベガへの移動装置だろうと曖昧に結論付けられた装置に乗る事になったのは神様の存在を肯定した元政府顧問だったりと、たぶん現実に地球外知的生命体の存在が公表されたらこんな感じだろうなと思わせてくれる展開です。
しまいには９．１１事件の前の作品とは言え、キリスト教の狂信者がその発射直前の建造物に対して自爆テロを起こす始末。
結局第二候補だったジョディフォスターが繰り上がりでパイロットに選ばれて、未知との黄金体験を行うのですが、端から見るとその操縦ポットがポトンと地面に落ちただけにしか見えず、巨額の費用を投じて結果の無いものをつくってしまった事への連邦裁判が始まりその証人に呼ばれるジョディ・フォスター。
彼女は物語の中盤で、若い宗教学者に科学者として、神様も信じないし存在を証明出来ないと言う事は存在しないと言う事だとハッキリと言い放つが、それに対して彼は「それでも神様はいらっしゃる」と答える。
彼女への裁判での詰問はさながら中世の宗教裁判や魔女狩りのような雰囲気で、その中で彼女は彼女が体験して提出されたレポートがウソか勘違いであったと証言しろと迫られる。
誰も彼女が体験した事を証明出来ないし、証明を裏付ける物が何もないためなのだが、それでもわたしは確かに体験したんだと証言の撤回を拒否します。
ここで、観てる私たちもハッとします。
事実と真実は違う物などと良く言いますが、まさにその通りなんだなと思い知らされます。
見てる物・見える物が必ずしも正しいとは言えないと言う強烈なメッセージです。
私なども現実の存在としての神様と言うものは否定的なのですが、実は肯定する事と否定する事は一枚の鏡の裏と表の差でしかなんじゃないかと思わせてくれます。

さて彼女の体験した黄金体験の映像は今となってはこじんまりと纏まった古い物に感じますが、当時のSFXとしては実に見事でとても美しくそれまでのかなりリアルな現実からポンと放り出される事でより強く印象に焼き付きます。
個人的にはヤマトよ永遠にの「新宇宙Ⅱ」のシーンの鳥肌と似てました。
そういえば数日前、以前隕石に微生物の痕跡があったと主張していた科学者が、結論として間違い無い事実としたのを、ＮＡＳＡの科学者が否定的な見解を示してると言う記事を見ました。
ＮＡＳＡはＮＡＳＡで、つい先月地球外で生命の存在の可能性がある星が５４個あると発表したばかり。

神、空にしろしめす、
すべて世は事もなし。

今回は某所のにコメ頂きましたので、【吉里吉里】ちびミクでシネスコ演出の４：３９あたりの斬線（造語）の作り方です。
これを作ってる時にマルチトランスを思いついたと書きたかったのですが誤解を与えてしまったようで、そのお詫びです。
とは言っても、やってる事は過去の斬撃のエントリーでやってる事と全く同じで、音はエントリーで使った音を多重で重ねたwavを作ってるだけです。
作り方がわからないのはおそらく線自体だと思いますので今回はそれの作り方です。
これはフォトショップの使い方の講座ですので、今回は記事のみで動画は作ってません。
さてこの斬線の作り方は分かってしまうとなーんだと言う程度の事なのですが、種明かしすると暗い部分から順次表示していくと言うユニバーサルトランスの特性を利用した一枚絵です。

まずパスを作ります。

パスは図のように１本で奧に表示させたい線から方向を考えながら引いていきます。
書き終わったら、それと同じくらいの長さ（長すぎるかなと思うほどでもＯＫ）で画面の外にパスを適当に伸ばします。
どうせそこは写らないので適当でかまいません。

次に描きたい太さのブラシを設定します。
特に自由に太さを設定して大丈夫ですが、ブラシの間隔は狭い方が良いと思います。
設定したらパスを”パスコンポーネント選択ツール”等で選択して右クリック＞”パスの境界線を描く”で、ブラシを選択。
強さのシミュレートにチェックを入れて”ＯＫ”です。




後はその線にスタイルで光彩などを設定すれば斬線の出来上がりです。



これを反転するとルール画像が出来上がります。
この作画で手前から奧への斬線が表示されるわけです。

ちなみに逆に奧から手前は、ちょっとこの方法では完成度が低くなります。
理由は交差してる部分がかなり大きくなるのでその部分が切れて見えるからです。
それに対応するには、例えば３種類くらいに奥行きを変えた斬線を描いて、それを順次重ね合わせていけばうまく行くのでは無いかと思います。
その場合の斬線の引きはちょっと工夫が必要だと思いますが・・・

とあるHPでhactの話題が出てましたので、小ネタを１つ。
私も最初の頃hactタグの応用例の「メッセージ履歴をクリックしたときに実行する TJS 式を生成する」関数の意味が分からずえらく頭を抱えました。
その時に思いついた物ですが、ストレージをコンテナ化すれば作業が楽じゃないだろうか？と言う単純な発想です。
結論から言えば、「マクロでやった方が楽」でしたが、まぁ吉里吉里はこう言う事も出来るんだよとおつきあいください。
まず下記をご覧ください。


@iscript
f.音楽_top = 'kag.bgm.stop(),kag.bgm.play(%[storage:"';
f.音楽_und = '",loop:true])';
f.音楽_mid = [];
//------この中に配列登録------
f.音楽_mid[0] = '無音.wav';
f.音楽_mid[1] = '曲１.wav';
f.音楽_mid[2] = '曲２.wav';
f.音楽_mid[3] = '曲３.wav';
f.音楽_mid[4] = '曲４.wav';
f.音楽_mid[5] = '曲５.wav';
//----------------------------
f.音楽 = [];
for(var i=0 ;i < f.音楽_mid.count ;i++)
{
f.音楽[i] = f.音楽_top + f.音楽_mid[i] + f.音楽_und;
}
@endscript


//音楽を鳴らす実行タグ（例では曲１が流れます）
[eval exp="&f.音楽[1]"]


何をやらせてるのかと言うと、kag.bgm.stop(),kag.bgm.play(%[storage:"曲目",loop:true])と言う文字列をf.音楽[x]に入れて、それを[eval exp="&f.音楽[x]"]で評価して鳴らしています。
一見するとフラグに何か無意味な事をさせてるだけのように見えるのですが、f.音楽[x]の中に前奏を止め新しい曲をループで流すコマンドがすべてパッケージングされてますので、そのフラグの中身を評価して実行――つまり音が鳴るわけです。
配列ですから、f.音楽_mid[]の配列の後ろを書き換えて追加すればいくらでも増やせます。
もちろんＣＧ等にも応用が出来ますし、tjsで制御可能なほとんどのコマンドをパッケージング出来ます。

このコンテナ化の利点は、まずスッキリ見えるため初心者が組むにも設定だけ誰かがしてあげれば簡単にコピペで組めてしまう事。
はめ込むだけですので、ＣＧだろうと音楽だろうと同じレベルで取り扱い出来ると言うのは初心者には大きな利点です。
また逆に、一見するとフラグに何かしてるだけのように見えるためフラグ名を偽装すればスクリプトを覗こうとした人がちょっと見では意味不明に見える事でしょうか。
反面、融通が利かないと言う欠点があります。
それは文字列の中に変数を組み込む事で解決する問題ではありますが、それではコンテナ化した意味が薄れてある意味本末転倒ではあります。

追記20110217a

《修正》
loopの位置指定が間違ってましたので修正しました。

うねうねとした表現です。今回は主にお仕事用プレゼンの意味合いが大きいです。
ＡＥでこう言う処理をよくさせてたのですが、吉里吉里で出来ないか調べていたらlayerExRaster.dllが転がっていましたのでそれを動かすスクリプトを組んでうねうねさせてみました。
やらせている事は単純です。
水面とそれ以外の部分に分解して水面をラスター処理で動かします。
たったこれだけの事で画面に動きが出るので、演出面ではとても助かります。
ただこのlayerExRasterは横方向へのラスターはいけるのですが縦方向には対応していませんので、後でTJSで作り直すつもりです。
.dllですので元々はc++で組まれていてうちはその技術は無いのですが、幸い中身を読んだ限り単純にサイン曲線を使って行の開始位置を南京玉簾みたいに制御してるだけのようですので処理速度の問題以外同じに作る事はそんなに難しくありません。
あとたぶん試してませんが、ラスター処理したものをアフィンで９０°傾けてやれば無理矢理縦ラスターは出来ると思います。（試してませんが、この.dllの仕様を見た限り左右判定やブラーはラスター処理の後に掛けることでちゃんと機能してますのでたぶん可能です）
また現状だと通常状態からぐにゃりとリアルタイムで歪ませるようには組んでいないので、それも同時に組み込むつもりです。
もっとも前回の動画で使ったopacityをなめらかに変化させる自作プラグインがあるので、クロスフェードさせたみたいにじわっと浮き出させる表現は可能なのでとりあえずはこれで良いかなとも思いますが。
このラスター処理と言うのは一見するとSTGくらいしか見かけることが無い効果なのですが、実は思いの外ADVとは相性が良く、演出面においては今回の水面などのように揺れる演出を行う時にかなり効果的です。
他にどう言うものに使えるかはまた追々公開していきたいと思いますが、エロゲ的シーンには結構欠かせない処理に使えたりします。

今回使った色相をリアルタイムで変化させる自作プラグインはlayerExRaster.dll同様にlayerExImage.dllを使ったプラグインなのですが、こちらはたぶん実用には向きません。
と言うのも、こちらはさすがにうち程度では中身を読めるレベルの物ではなかったのでどう言う作りかわかりませんが、この色相変化させる処理に恐ろしくマシンパワーを使ってました。
最初このリアルタイムで色相を変えるプラグインとvideoタグでvideoを動かしてテストしてたのですが（べ、別にコメントアウトし忘れたわけじゃないんだからね！）、動画がコマ落ちしてて驚いて調べたらこのプラグインだけでうちのマシンでCPU稼働率が20％もありました。
もちろん単発の使用にはちゃんと使用に耐えるスピードなのですが、リアルタイムには難しいようです。
Layer.adjustGammaメソッドを試していませんが、もしかするとこちらの方を使って作り直した方が良いかもしれません。
ちなみにlayerExRaster.dllとlayerExImage.dllは共存が難しいようで、同じレイヤーに両方をリアルタイムで処理させると時々そのレイヤー表示が乱れます。
なので、今回は色相変化させるレイヤーの上にラスター処理用のレイヤーを重ねると言う処理をしています。

『マルチトランス』です。
簡単に言えばユニバーサルトランスを使って最大四段階で次々にルール画像を変えてトランスしていきます。
とりあえずなデモはfirst.ksをごらんください。
また詳しい説明はmtrans.ksに細かく書いてあります。
かなりクセがあるトランスを行いますので使い方次第ではかなりの可能性は秘めてると思いますが、うちは演出でユニバーサルトランスを滅多に使わないので今一使いどころに迷ってます。
じゃぁなんで作ったんだよと言うツッコミは無しの方向で。
思いついたから仕方ありません。

権利放棄は致しませんが、改造や改変はご自由に行って頂いて結構です。
またその際連絡等も必要ありません。
でもどこで使ったよー！と後ででもこっそり教えて頂ければ後々の参考になるのでうれしいです。

なんだかよくわからないけどとりあえず組み込んでみるかって人は、「mtrans.ks」「右下から左上.png」「右上から左下.png」「左下から右上.png」「左上から右下.png」をパスが通ってるところにおいて、

[call storage="mtrans.ks"]

をシナリオの頭にでも書いて下さい。
あとはfirst.ksに書いてあるコマンドを試せばそんなに難しく無いと思います。

改造する方へ
一部パラメータの取得等でTJSを使ってますが、それ自体は大して難しい事は無いと思います。
ただ不要な部分や回りくどい処理をしてる部分はほとんどそぎ落として、ブロックごとに簡単なコメントを振ってはありますが、拙いせいで一部なんでこんな事をしてるのか理解不能な所があったりするかと思いますが、そのときはご容赦ください。

あと中のコメントで必須パラメータはlayerとstorage云々と書いていますが、実はそれすら必要ありません。
初期設定でデフォルトトランスが設定されており、ただトランスすれば通常のユニバーサルトランス的に使えます。
これはある意味想定外だったのですが、とにかく相当無茶をしても飛ばないようにと組んでいたらパラメータ無しでも動くようになってました。

何かバグなどありましたらこちらに書き込んで下さい。


追記20110204c
プレリリース版より若干修正しました。
主な修正・変更点は以下の通りです。

《修正》
・vague値をパラメータでセットした場合、以降正しくデフォルトが反映されてなかった不具合を修正しました。
・time・dividesをf.mtrans_time・f.mtrans_dividesでmtransタグの外部でセットした場合、正しく反映されてなかった不具合を修正しました。

《変更》
・opacityの計算式をより厳密な書式に変更・統一しました。
・wtタグのcanskip=true/falseを選択出来るように変更しました。

その他コメントを若干修正。

最近、TJSを使って小物のプラグインをいくつか作っているのですが。
それでちょっと気になって、video(mpg)と.asdによるスクリプトアニメーションのそれぞれのCPUとメモリ負荷を調べてみました。
使用した素材は、videoの方はよく動画の右上から射し込んでる斜光。
.asdアニメーションの方はその斜光を400*300（面積で1/4）に作り直して、10fps（videoは30fpsなので1/3）で出力してそれを並べて作りました。
つまり.asdはvideoの約1/12負荷と言う事になります。
結論から言えば、それぞれメモリ使用量は共に+20m前後増加でほとんど変わりありませんでした。
CPU使用量はさすがに.asd使用時が4%安定 video使用時が9～30%と不規則に変化します。

条件を全く同じにするとまた結果は違ってくるかとは思いますが.asdアニメは_aファイルが一枚画として大きくなりやすく固まりそうになる事も結構ありました。
何よりうちが連結ファイルを作る事に慣れてなかったので連結と.asdファイルを作るのに手間取ったと言う部分もあります。
特に連結ファイルは、フリーソフトではちょっと大きなものを作ろうとするとすぐにエラー落ちするような物ばかりしか見つけられず苦労しました。
そう言えば、連結と.asdを自動で出力してくれるプラグインをどこかでちらっと見かけた気もしますが。

目パチくらいならあきらかに.asdの方が作りやすいのですが、どちらを使うかの判断はCPU負荷を取るか作りやすさを取るか……と言うところでしょうか。