【Unity】 パーティクル

はじめに

こんにちは、ソーシャルゲーム事業部のUnityエンジニアの佐藤です。
今年はハースストーンとオーバーウォッチに費やした1年でした。
ブリザードさんのゲームは面白いですね〜。

諸事情によりパーティクルの話を先にさせていただきたいと思います!


この記事はカヤックUnityアドベントカレンダー2016の14日目の記事となります。

今回はUnityのパーティクル(Particle System)についての記事です。

「パーティクルを初めて触るなら、この辺のパラメーターを調整するといい感じになるよ〜」 というポイントをお伝えしたいと思います。

Particle Systemとは

UnityではParticle Systemという機能があります。
簡単に説明すると、「パラメーターを設定して、炎や粒子といったエフェクトを作る」機能です。
今回は、Particle Systemのパラメーターを幾つか紹介していきたいと思います。

作って触ってみよう!

実際に触りながら作ってみましょう。

Hierarcyビューからパーティクルのインスタンスを作れます。

2016-11-22 19 11 48

4d1dc434b4092f3d69123429324f4cbb

Duration

パーティクルを発生させる時間(秒)です。
この時間を経過すると、パーティクルの生成がストップします。

Looping

Durationで指定した時間を過ぎた場合にループするかを指定します。

Prewarm

パーティクルの再生を開始した時に、事前にパーティクルを配置しておくか を設定するパラメーターです。

Prewarm なし
9c0ed8f875bbf955e8b293dfec19ccdb
再生を開始すると、徐々にパーティクルが広がります。

Prewarm あり
e1db3c419ce65e51fbce705722f8ef0e
再生を開始すると、パーティクルが事前に配置されています。

Start Life Time

パーティクルの寿命(秒)です。

Start Life Time : 0.1秒
c3da7524a75842994e7947df942ad480

Start Life Time : 1秒
edd20dd77181c63c2c42edfed4374647

Start Life Timeが短いほうが消えるのが早いですね!
逆に長い方は遠くまで粒子が届いています。

Start Speed

パーティクルのスピードです。
単位はm/sec。

Simulation Space

パーティクルを発生させた際に、発生源を原点として動くかを設定できます。

Simulation Space : Local
f697682f56935290499ce2bbada732d2
Partice Systemを動かすと、既に放出されているパーティクルも追随します。

Simuration Space : World
162c106b5a1e6a2d657a05e7fa9a56ce
Partice Systemを動かしても、放出されているパーティクルには影響ありません。
放出された時の開始位置が原点となります。

Play On Awake

有効にすると、Awakeが呼ばれた時(シーンに配置された時)に再生を開始します。
無効にすると、スクリプトなどで再生を要求します。

Max Partices

このPartice Systemの最大パーティクル数です。
同時に表示できるパーティクルの数を指します。

Emission

この項目ではパーティクルの発生間隔を調整します。

Rate

  • Timeの場合 : 1秒間あたりのパーティクル発生数
  • Distanceの場合 : 1m移動する毎に発生するパーティクル発生数 を設定します。

Rate : Distance
c0b1f75bedcd30d3b6a2192e83a797a6
移動する毎にパーティクルが発生するようになっています。

Burst

Timeを指定した場合のみ、Burstオプションを設定することができます。
指定した秒数毎にパーティクルを放出します。

1秒ごとに30個パーティクルを発生するバーストを3回繰り返す、Durationが5秒のパーティクル
8d9b1d000d2c45fb6be0e959582a4577-1

パーティクルの発生に緩急を指定したい場合などにぴったしです。

Shape

パーティクルの放出方向を指定できます。

Cone型
04d1f9bec71ab35bdd534105e924d1c8

指定方向にパーティクルが広がります。
炎とかに使えそうですね。

Sphere型(球)
f89b030db670ac788e3acd4dbdd116e1

球場にパーティクルが広がります。
爆発とか光源とかに良さそうですね。

Box型
13929e5cfea821867f65dad76f1f8648

指定した方向へパーティクルが進みます。
煙みたいに見える!!

Render

パーティクルの形やマテリアルを設定することができます。

Particle Systemで作る?アニメーションで作る?コードで書く?

演出やエフェクトを作る際に、Partice Systemを使うか、アニメーションで作るか、コードを書くかということを考える時があるかもしれません。

たくさんモノを放出して、ランダム性を許容する 時はParticle Systemを使うのが良いかなと思います。

ただし、ドローコールをしっかり管理しないと動作が重くなったりするので、気をつけましょう。

おわりに

明日はアファトのAnimationの話です。
Unity5.5でアニメーションのエディターが強化されたので、Animationで動きを作るケースが増えるかも?
これからAnimationをやってみようかと思う人は、ぜひ御覧ください!!

響け♪ eupho ニアム

※ この記事は Tech KAYAC Advent Calendar 2016 14日目の記事になります

こんにちは、劇場版でガルパンにどハマりして映画なんて全然観ない人間だったのに気づいたらほぼ毎週立川や幕張新都心にガルパン劇場版観に行って気づいたらこの一年で50回以上観てたりしてTV版一挙オールナイトも観に行ったりして、果ては大洗に行ってクイズラリーとか参加して海鮮丼食べたりギネス飲んだりギネス飲んだお店にあんこう祭りでテンション上がって買ってしまったフィギュアを忘れてきたりしてる(これ書いてる時点でまだ預かってもらってる迷惑な)超絶にわかガルパンおじさんの瀬戸です。気づいたら会社の机の上もカオスになってきました。

f:id:mix3IRC:20161212205736j:plain

ガルパンはいいぞ

テスト遅い問題

アプリ開発しているとテストは書くわけですが、開発が進み2年も運用しているとテストの数が増えてきて当然のことながら少しずつテストの時間が延びていきます。 今関わっているプロジェクトでは最近は一回のフルテストで 18分 ぐらい掛かっています。一回のテストで 20分 近い時間がかかるとリポジトリへの push で自動テストをしたりすると簡単に渋滞してしまうので自動テストする対象は絞ってたりします。

自動テストの対象を絞ると部分的に自分でテストを走らせないといけないわけですが、そういうことをしているとたまにはテストしないままマージするようなことも発生したりするので、出来ればすべてのブランチを自動テストしたいのが正直なところです。

なのでそのためにもなるべく テストは速くしたい!

eupho

過去、自称穏健派の過激派による過激な対応によってテスト時間の改善が行われ、今も go-prove が使われているわけですが

(※詳しくは去年の Advent Calendar 記事参照)

techblog.kayac.com

それでも 18分 掛かっている現状に自分はこう思ったのでした。

 ( ˘⊖˘) 。o( go-prove が2台のサーバで動いて半分ずつテスト分担したら2倍速になるのでは? )

...

ということで誰でも思いつく非常に安直な発想のもと出来たのが eupho になります。

go-prove をサーバ・クライアントで動かすようにしたもので、だいたい以下のような動作をします

  • サーバ: テストファイルのパスを列挙、クライアントにそれを配りきって全てのテスト結果を貰うまで待ち続ける
  • クライアント: テストファイルのパスがもらえなくなるまで取りに行ってテストを実行しテスト結果をリクエストで通知する

絵にするとこんな感じでしょうか?

f:id:mix3IRC:20161212210354p:plain

実際に動かしてみるとこんな感じになります

f:id:mix3IRC:20161212210524g:plain

jenkins で実用するときは「euphoを起動するジョブ」と「eupho-slaveを起動するジョブ」に分けて用意して、「euphoを起動するジョブ」が走る時に「eupho-slaveを起動するジョブ」を curl で buildWithParameters 経由で起動するか Trigger/call builds on other projects で起動するのが良いのかなと思います。このとき Build Blocker Plugin を使って node level でのブロックを併用すると 1node に偏らないので良さそうです。

結果

eupho を使って18分掛かっていたテストを2台使って実行したところ10分で終わるようになったのを確認しました。

これが…

f:id:mix3IRC:20161212211803p:plain

こうなって…

f:id:mix3IRC:20161212235421p:plain

こうじゃ!

f:id:mix3IRC:20161212211810p:plain

最高ですね!

slack に報告したところ…

f:id:mix3IRC:20161212213553p:plain

ステマのごとく絶賛されてしまいました!コワイ!

まとめ

  • 自動テストのことを考えるとテストは速い方が良い
  • テスト遅い問題、テストを実行するサーバを複数に分散させるのはアリかもしれない
    • もちろんスケールアップも1つの手
  • まだ eupho を実戦投入してないけど動きそうな雰囲気なのでちゃんと使いたい
  • 何がいいかは人それぞれですが、ワタクシ個人としましてはガルパンと響け!ユーフォニアムはいいぞ

明日は 飛鷹 君です!

こんな「〇〇はいいぞ」を書きたいだけの記事とは違う、素敵なお話をしてくれることでしょう!お楽しみに!