透過画像を使ったボタンの範囲から透過されている部分を削除する

問題 Unityのボタンに円形の画像を使った際、ボタンの選択範囲が四角になってしまうため、円形の外にも選択判定ができてしまう問題があった。 単純な円形なら後述するICanvasRaycastFilterを使えばいけるけど、半円やキャラクタの形をしたボタンなどを実装したい場合は厳しそう。 例えば、下の星の画像でボタンを作り、星の範囲だけに判定をもたせたいのに、 こんな感じに、画像がちょうど入る四角い範囲がボタンになってしまい、ピンク色のところにも判定ができてしまう。 前提 画像の非選択にしたい場所が透過されている ようは透過画像を使いたい デモ 処理の説明の前にとりあえずデモ。 左が処理前、右が処理後です。 処理前は星の外をクリックしても反応していますが、処理後は反応しなくなりました。

解決方法 RaycastMask.csをProjectにコピペ
RaycastMask.csをProjectに置く。 また、コピペする際、25,122行目のフラグがあると動かないのでそれを除いたものをする。 Projectにある使いたい画像の設定を変える ボタンを作る おわり ちょっと解説 RaycastMask.csのざっくりとした処理 画像の情報を取り、透過されているかを判定する(GetPixcel) 透過されていない範囲にレイキャストを与える(ICanvasRaycastFilter) GetPixcel とは 座標(x, y)のピクセルのカラーを取得します。Unity - スクリプトリファレンス: Texture2D.GetPixel これで画像の状態を取ることができる。 ICanvasRaycastFilter とは RaycastMask.cs が継承してるクラス。 この要素はレイキャストをフィルタリングすることができます。トップレベルの要素がヒットした場合、その位置が有効であるとさらに 'チェック' することができます。 ICanvasRaycastFilter - Unity スクリプトリファレンス これを使うことで、uGUIの選択範囲を広めたり狭めたりできる。 詳しい使い方は以下のサイトをみればわかると思います。 UnityのuGUIのクリック範囲を広げたり制限したりする方法 - テラシュールブログ Read/Write Enabled とは テクスチャデータをスクリプトからアクセスできるようにします(GetPixels、SetPixels、その他の Texture2D 関数)。注意することとして、作成されたテクスチャデータは、テクスチャアセットとして必要なメモリ量は倍となります。必ず、必要な場合のみ使用してください。これは非圧縮や DXT 圧縮のテクスチャでのみ有効であり、その他の圧縮テクスチャの種類では読みこむことができません。デフォルトでは無効となっています。 テクスチャ - Unity マニュアル

Read more →

最近読んでる本

Read more →

日本語がわからない

Read more →

UNIXという考え方を読んだ

はじめに  今回は「UNIXという考え方」を(半年以上前に)読んだのでその感想をかいていきます。  UNIXにおける考え方やプログラミングをする上で大切なことはもちろん,研究や普段の生活でも言えるようなこともたくさんかいてあって面白い本でした。 本の感想  UNIXの考え方 : 基本的な9つの定理と10このUNIXの文化がかいてあり、それぞれ実例などを踏まえて解説していくって感じでした。  その中でも個人的に面白かったところや絶対覚えておこうって思った以下のセクションについて、ざっと簡単にまとめて思ったことをかいていこうかなと思います。 スモール・イズ・ビューティフル できるだけ早く試作する 1つのプログラムには1つのことをうまくやらせる 森林を守る 部分的総和は全体よりも大きい 90パーセントの解を目指す スモール・イズ・ビューティフル 内容 小さいものは、大きいものにはない利点がいくつもある。小さいもの同士なら、簡単に独自の便利な方法で組み合わせることが出来るというのもその一つだからだ。  目的とそれに対するアプローチを明確にして、細分化して実装すれば、似たような場所には同じプログラムを再利用できるよね。 ほかにも、小さいと再利用できるだけじゃなくて、わかりやすいし保守もしやすい、他のツールと共存しやすいなど様々なメリットがある。 思ったこと  最近はプログラムをできるだけいい感じのまとまりを関数にするように意識してプログラムを書くようにしました。 1つのプログラムには1つのことをうまくやらせる 内容 一つのことに集中することで、プログラムに不要な部分をなくせる。不要な部分があると、実行速度が遅くなり、不必要に複雑になり、融通が効かなくなる。  一つのことをうまくできるプログラムを複数組み合わせたりカスタマイズすることで、目的に沿った処理を果たせるほうがいいよね。 じゃないと、似たような目的なのに、それぞれに対して全て新しいものを作る「車輪の再発明」をするのは無駄だよね。 さらに、一つの機能に絞ることで、プログラム自体も小さくできるよね。 思ったこと  細分化するメリットがこれだなっていうのが分かった気になった。 できるだけ早く試作する 内容 あらゆるプロジェクトにおいて、試作は重要だ。一般的に試作は設計全体のうちのほんの一部として扱われているが、UNIXにおいての試作は、効率的な設計には欠かせない重要な一部だ。  仕様書とかをかいてないでとりあえず試作を作ったほうがいいよね。 試作を作ると何がうまくいき、何がうまくいかないかがわかるようになる。 これによって、様々なリスクを減らすことができるよね。 思ったこと  キレイなプログラムを書こうと考えてる暇があったら汚いプログラムでいいからとりあえずかいて、そのあとリファクタリングするのを意識するようにした。 あとは、研究でもとりあえずプロトタイプとかをさっさと作ったほうがいいのかなって思った。 森林を守る 内容 UNIXユーザーは紙のドキュメントを嫌う。全てのテキストファイルをコンピュータに保存して、強力なツールでそれらを操作するのだが、このことには十分な理由がある。  プログラムを印刷してメモをするひとがいるけど、印刷するとそのプログラムは並び替えも移動も編集もできなくなってしまって無駄だよね。 思ったこと  昔、印刷されたプログラムとにらめっこをしてるひとをみてワオっておもったことが、言葉にされてて個人的に感動した。 他にも、メモとかも電子化したほうがメリット多いよねって思う。 りんごペンを買ってからは紙に何かをすることをほとんどしなくなった。
Read more →

ゲームオブジェクトが消えた

Read more →