ろうでんのブログ

ただのブログ

アカツキのインターンに行ってきた話

久しぶりの投稿です。
株式会社アカツキの就業型インターンシップで10営業日働いてきたので、そこでやったこと・学んだこと・感じたことについて書きます。
某配信中のスマートフォンゲームのプロダクトチームに所属して、クライアントサイドのプログラム(Unity)を触りました。

目次

お前のスペック

理系の国立大学の大学院の修士課程1年生で、2020年新卒の就職活動の最中です。
Unity 歴は半年くらいなので Unity 独自の技術についてはペーペーですが、C# 歴は7年くらいで、かつ業務(アルバイト等)にも使っているのでそれなりにできると自負しています。

与えられたタスクとやったこと

  • 「Profiler を使ってパフォーマンスを改善できそうなところ見つけて!」
    • 一瞬だけ重くなる箇所を見つけて原因を調べた
      • Unity のログ出力が瞬間的に大量に呼ばれていただけだった(なのでリリース版では生じない問題)
      • UnityEngine.Debug.Log() について改めて学んだ →後述
  • コード自動整形ツールの導入 →後述
  • プロダクトで実際に使われている Shader ファイルを見ながら Shader の勉強 →後述(メインの話)

UnityEngine.Debug.Log() について改めて学んだ

Unity でデバッグ出力をしたいとき、UnityEngine.Debug.Log() を使います。
この UnityEngine.Debug.Log() によるデバッグ出力は、リリースビルド時には実行されません。
しかし、IL 上でのメソッドの呼び出し自体は消えないため、引数の評価コストとメソッドの呼び出しコストは掛かってしまいます。
そのため、下記のページでも紹介されている手順で新しいメソッドを作ってあげます。 qiita.com noracle.jp

簡単にまとめると、

  1. Conditional 属性 [Conditional("UNITY_EDITOR")] をつけたメソッドを作り、UnityEngine.Debug.Log() をラップする
public static class Logger
{
    [Conditional("UNITY_EDITOR")]
    public static Log(string arg)
    {
        Debug.Log(arg);
    }
}
  1. UnityEngine.Debug.Log() を使用している箇所を、上記メソッドに置き換える
public class Hoge : MonoBehaviour
{
    public Update()
    {
        // Time.deltaTime の評価や、string.Format() の処理が入る
        // UnityEngine.Debug.Log($"Delta Time: {Time.deltaTime}");

        Logger.Log($"Delta Time: {Time.deltaTime}");
    }
}

コード自動整形ツールの導入

Artistic Style というツールがあるので、プロダクトチームで共有して使うためのバッチを組んでほしい!」という要望があったので、Artistic Style を呼ぶためのシェルスクリプトと、コーディング規約の設定ファイルと、利用者向けのドキュメントを書きました。
(こういう、明確な期限がないものってインターン生の課題に向いてますよね)

Artistic Style とは、C, C++, C++/CLI, Objective-C, Java, C#ソースコードインデントや改行、スペースの挿入位置などのコーディング規約を揃えたり、タブ文字→スペースの置換や改行文字の統一を自動でやってくれるすごいやつです。
「どのルールに統一するか?」を設定ファイルに記述することができるので、チームでのコーディング規約統一にも使えます。
個人的には、コーディング規約を自然言語で記述されるよりも、こういう設定ファイルの方が分かりやすいんじゃないかと思ってます。

astyle.sourceforge.net

トゥーンレンダリングの勉強

プロダクトで実際に使われている Shader ファイルを見ながら、Shader とトゥーンレンダリングを学びました。
主に トゥーンレンダリング(3D グラフィックをアニメ塗りっぽく出す技法)について学びました。

トゥーンレンダリングでは、主に下記の2つのことをやります。

  1. アウトライン(輪郭線)を出す
  2. シェードの計算をいじって、シェードラインがパキッっとなるようにする(アニメ塗り)

詳しく説明していきます。

1. アウトライン(輪郭線)を出す

アウトラインを出すには下記のようなやり方があり、それぞれ特性が異なります。

参考↓

light11.hatenadiary.com

  1. 少し大きくしたモデルをアウトライン色で描画してから、元のモデルで上書き
    • 最も単純なやり方
    • 1つのモデル内の凹な部分にもアウトラインが出る
    • 描画処理は2回走る
  2. 少し大きくしたモデルのステンシルバッファの値と、元のモデルのステンシルバッファの値を別々にして、前者の部分をアウトライン色で描画し直す
    • ステンシルバッファが同じ値のモデル同士(凹な部分や、体と腕の重なりなど)にはアウトラインが出ない
    • 描画処理は3回走る
  3. ポストエフェクトで、隣接する箇所との深度が大きく異なるところにアウトラインを描画
    • 深度情報を付与してあげる必要がある
    • 凹な部分にアウトラインを出すかどうかを決められる
  4. ポストエフェクトで、隣接する箇所との法線ベクトルの方向が大きく異なるところにアウトラインを描画
    • 法線情報を付与してあげる必要がある
    • 凹な部分にアウトラインを出すかどうかを決められる
    • シワや折り目などの部分にもアウトラインを出すことができる
  5. シェーダを使わずに、モデルやテクスチャ自体にアウトラインをつける
    • モデリング担当者の思い通りの箇所にアウトラインをつけられる
    • 後からアウトラインの太さや色を変更することは困難

1について詳しく調べてみたので下記にまとめます。

最も単純なアウトラインシェーダ

Pass を2つ使い、下記の流れでレンダリングします。

  1. 1つ目の Pass で、少し大きくしたモデルをアウトライン色で描画
    • 「少し大きくする」を実現するために、頂点シェーダ内で各頂点を法線方向に移動させる
    • このときの移動させる量がアウトラインの太さになる
    • このままだと 2. のモデルを覆い隠してしまうので、Cull Front を指定する
  2. 2つ目の Pass で、元のサイズのモデルを元の色で通常通りに描画

以上の処理でアウトラインを出せますが、もうちょっと手を加えることでより良くなります。

  • 近くのアウトラインが太く、遠くのアウトラインが細くなるのをなんとかしたい!

    • 法線方向への移動量にカメラとの距離に応じた係数を掛けてあげれば、ある程度太さが一定になる
    • 「スクリーン座標系で 2px の太さにしたい」といった場合には、より重たい処理が必要になる
  • テクスチャの色に応じてアウトラインの色を変えたい!(2D CG イラストでいうところの「色トレース」という技法)

    • テクスチャの色を暗くした色で描画してあげればOK
    • 厳格にアウトライン色を指定したい場合は、モデルの頂点カラーなどにメタ情報としてアウトライン色を埋め込む必要がある

2. シェードの計算をいじって、シェードラインがパキッっとなるようにする(アニメ塗り)

通常のシェーダ(Unity でいうところの Standard シェーダ)では、シェードにはグラデーションがかかったようになります。
ですが、アニメ塗りのノーマル色/1号影のようにシェードライン(シェードのある部分とない部分の境界線)でパキッと塗り分けたい場合があると思います。
そのような場合、下記のようなやり方があります。

  1. ディフューズの計算時に、変化を大きく(係数をかける)して clamp(範囲内に収める)する
    • clamp して1になったところをノーマル色、0になったところを1号影にする
    • 1号影の色を厳密に指定したい場合、テクスチャにメタ情報をつける
  2. テクスチャに全部描いて、シェーダは Unlit(シェードをつけない)にする
    • モデルの向きに応じて陰が変わらない(逆さまになっても)

マップオブジェクトなど、向きが変わらないモデルに対しては 2. でも問題ありませんが、プレイヤキャラクタのように向きが変わるモデルに対しては 1. が望ましいです。

さて、1. の処理でアニメ塗りを再現できるわけですが、もうちょっと手を加えることでより良くなります。

  • 2号影をつける
    • 上記 1. の処理をもう一度やってあげる
  • ハイライトをつける
    • Specular の計算時に、上記 1. と似たように clamp してあげる
  • リムライトをつける
    • モデルの奥のやや横に光源があると仮定して Diffuse を計算

インターンシップを通して感じたこと

私は他社でのアルバイトや就業型インターンの経験があります。
それと比較して最も感じたことは、社員と同様の流れで仕事をできたことだと思います。
他社のインターンでは、インターン専用のカリキュラム(?)に沿って以下のような流れで仕事を進めることがしばしばありました。

  1. 「〇〇を実装する」や「〇〇のバグを直す」といったタスクが与えられる
  2. 問題の対処をする
  3. 問題が解決できたか確認する
  4. Pull Request を出す
  5. 「社員が忙しいのでレビューできない!ごめんね!」
  6. 退職後マージ

一方でアカツキでは、以下のような流れで仕事を進めることができました。

  1. 現状のプロダクトを触って自分で問題点を見つける(自分でタスクを決める)
  2. 問題の原因を調べる
  3. 問題の対処をする
  4. 問題が解決できたか確認する
  5. Pull Request を出す
  6. (レビューされる)
  7. レビューに応じて直す
  8. 6-7 を繰り返す
  9. マージおめでとう!

こうして社員と同じ流れをたどることができ、ただ技術力をつけるだけでなく、仕事を進める力がつけられたのではないかなと思います。

総評

アカツキでのインターンを通して、

  • Unity 力
  • Shader 力(トゥーンレンダリング 完 全 に 理 解 し た
  • コーディング規約治安部隊力
  • タスクを見つけて実行する仕事力

をつけられたと思います!

今回のインターンでは、メンターの方だけでなく、プロダクトチームのいろんな方々にお世話になりました!
この場を借りて感謝申し上げます🙏

aktsk.jp

備忘録

触ったことがあるプログラミング言語

今まで自分がどの言語に触れてきたかを忘れないように書いておきます.時系列のつもりです.Visual BasicHaskellのようにサンプルコードくらいしか触ってない言語は除きます.

HSP

ニコニコ動画で見かけた,MIDORIKAWA氏のHSPでゲームを作る動画を見たのがきっかけでした.

おそらく中2か中3の頃だったと思います.その頃,ゲームと呼べるような代物は作れませんでした.コーディングもかなり汚く,gotoをいっぱい使っていたと思います.当時書いたコードが入っていたHDDが飛んだため,何一つ残っていません.

C

高専1年でプログラミング研究部というプログラミング系の部活に入り,最初にCを学びました.主に競技プログラミングに向けてやっていました.当時はVisual C++ 2010を使ってました.後にC++に繋がります.

高専では,座学・実験ともにCを一番使っていたと思います.ただしC89とかいう産廃でした.劣悪環境.

高専5年では,MieruEMBと呼ばれる,組込みシステム教育用のボードのFPGA上で動作するMIPS32プロセッサで動作する小さなゲームを開発しました.某アクションゲームのパロディゲーです.フルスクラッチでゲームを開発したのはこれが初めてだったと思います.

HTML+CSS

同じく高専1年の頃ですが,こちらは自分一人の趣味として触りました.プログラミング言語と言うよりはマークアップ言語ですが…….何かホームページ的なものを書いていました.とても汚かったです.JavaScriptは使っていなかったと思います.

高専4年の実験で改めて学び直しました.何をしたかは覚えていません.

C++

高専1年の夏,競技プログラミングをするにあたって一歩前進してC++に触れました.

一気に大量の言語仕様に触れたため,恐れおののきました.今でも怖いです.

何故か高専では習わずに終わり,「電子情報工学コースって何だ」という疑問が残りましたが,大学でも習いませんでした.競技プログラミング,ゲーム開発のみならず,プログラミングのバイトでも使っている,一番お世話になってる言語なのに,何故習わないんだ…….

東方弾幕風

またまた同じく高専1年の頃,プログラミング言語というよりはゲームスクリプトですが,弾幕STGで弾を吐き出したりしてました.データは飛びました.

JavaScript

高専1年の冬,部活の一環で学ぶ機会がありました.ちょっとしたものしか作れませんでしたが,色々な言語を学ぶきっかけになりました.動的型付けの言語は汚いと思いました.

大学1年の実験でも改めて習いました.

Java

高専1年の末期,Twitter4JというJava向けのTwitter APIのラッパライブラリがあり,それを使ってTwitterクライアントでも作りたいな~~と思い,学び始めました.

それまでprintf( "hoge\n" );で済んでいたものがSystem.out.println( "hoge" )というクソ長い物体になり,なんか気持ち悪いなと思いながら書いてました.それまではスネークケースばっか使っていたのに,キャメルケースとかいうものに触れて,別世界を見たかのような気分でした.しかし,C++よりかは分かりやすい言語だと感じました.unsignedが無いのはどうかと思いましたが.

高専2年か3年の実験でもJavaを習いましたが,至って簡単なものでした.高専4年と5年ではAndroidアプリケーション開発に発展し,かなり実用的なものを学びました.おそらく高専で習った中で一番役に立つものだったかと.

結局Twitterクライアントは作りませんでした.

C♯

高専2年の頃,部活の先輩の「神言語」という紹介で触れました.

C++に比して圧倒的に単純明快な言語仕様と,コーディング量の少なさ,Visual C# 2010のコーディング支援機能の豊富さなど,一気に入信しました.今でも1番書いてて楽しめる言語だと思います.開発のバイトでも使っています.

PHP

高専4年の実験で,サーバサイドスクリプトとして学びました.動的型付けの言語は汚いと改めて思いました.

MySQL

高専4年の実験で,関係データベース周辺の内容を学びました.LINQの理解へ繋がりました.

MIPSアセンブリ

ハードウェア系の授業でほんのちょっとだけ習いました.

Verilog-HDL

ハードウェア系の授業で,MIPSマイクロアーキテクチャFPGAに焼くために習いました.

CASL2

アセンブラの授業で習いました.

Python

大学1年の実験で習いました.環境由来のクソさに嫌気が差しました.インデント主体の構文は嫌いではありませんが,色々な名称が中途半端な省略形にされていて読みづらいと思います.これから人工知能系の研究へ(多分)進んでいくので,もっと触らないといけないと思っていますが,あまり機会がありません.

Scheme

初めての関数言語です.括弧だらけで吐き気がしました.あまりにも可読性が低い物体が出来上がったので,二度と触れたくないと思いました.Haskellってまだマシなんだなぁと感じました.

Ruby

ツクールのスクリプトを書くのに使いました.痒いところに手が届くというタイプの言語だと感じました.ただし,endは嫌いです.

MATLAB

大学1年の画像処理系の授業で習いました.元々インタプリタは嫌いですが,更に嫌いになりました.汚い.MathematicaScilabも汚い.

R

大学1年の統計・分析の実験で習いました.使いこなせれば考えは変わると思いますが,とてつもなく微妙な言語だと思いました.インタプリタは嫌いです.

これから触れたい言語

一応,忘れないために.

電気通信大学の単位認定のおはなし

はじめに

これは2016年度に電気通信大学へ編入した私の単位認定に関するエントリです。
総合情報学科の情報です。

2015年度に編入した人(1つ先輩)のお話です↓
marin72.hatenablog.com

2016年度に編入した人(同期)のお話です↓
nishikino3.hatenablog.com

続きを読む

はてブロ始めました

はじめに

記事タイトルの通りです。
見出しはダジャレです。

さて、始めたと言っても、まだ何の記事も書く予定はありません。
書くとしたら、グループとかいうので設定したプログラミング関連の話かと。
多分、Androidアプリ向けのGoogleマップAPIの話になるかな。
どうせ普通の日記みたいになりそうですけどね。
何の記事にしろ、書くのは面倒なので後々やります。

FC2ブログ時代

ブログ自体は2016年3月21日時点で既にFC2ブログを利用しています。
しかしながら、いかんせんたった1ヶ月更新していないだけでデカい広告が出てウザいので、移転する形ではてブロの利用を始めます。
ここ数年はほぼTwitterでの発信でほぼ事足りているので、すぐ1ヶ月経ってしまってました。

移転と言っても、暫くはFC2ブログの方も残しておきます。
今はFC2ブログからエクスポートしたものをそのままインポートした状態なので、画像リンクがFC2のドメインになってます。
画像ファイルのエクスポートが面倒なのと、画像リンクのアドレスを修正するのが面倒なので後々やります。

@Wiki時代

今回の移転の話とは関係ありませんが、FC2ブログを始める前は@Wikiでブログらしきものをやってました。
@Wiki時代で書いてた頃のブログの存在を知ってる人はいるんですかね……。

当然、@Wikiはブログ向けのサービスではないので、ちゃんとしたブログ向けのサービスに移転しようと考えました。
ただ、(記憶によると)@Wikiでは一般的なHPのようにトップページを作って、そこから時系列とは関係のない分類から各記事に飛べる構造だったはずなので、同様のことをホームページでやろうとしてたはずです。
なので、確かほぼ同時期にブログとHPを開設して、日記的なことはブログに、何かしらカテゴライズできそうなトピックに関する記事はHPに移転させました。
もうアクセスする人もいないと思うので先ほど削除しました。

ブログとHPは、色々なサービスでアカウントを作りたくなかった(当時はあまりにも自分にとって信頼が置けるサービスかどうかの判断基準が厳しかった)ので、ブログもHPも作れるFC2にしました。

FC2 HPについて

ちなみに、2016年3月21日現在のHPの状況についてですが、背景が何故か陸上自衛隊の迷彩服2型の柄でとても読みづらいし、リンク切れ多発してるし、文字化けしてるページだらけだし、いかにも厨房な文体でウザいし、普通にダサいそびえ立つ糞な状態です。

なんだかもう色々とぐちゃぐちゃになってて気持ち悪い状態なので、いっそのこと全部直す際ははてブロに一本化させたいと思っています。
思っているだけで、面倒なので後々やります。

Yahoo!ブログ時代

時代ってほどではないはずですが、Twitter始めてすぐの頃、PSNでのフレンドが多く利用してたヤフブロを開設してたはずです。
確かブログバトン(だったかな?)で2、3記事書いただけだと思います。
その後、ヤフブロ利用停止したかどうかは覚えていません。
まだ残ってるかどうかの確認も面倒なので後々やります。

Blogger時代

@Wikiより前(もしかしたら@WikiからFC2ブログに移転する間だったかも)はBloggerでブログを書いていました。
Bloggerを選んだ理由は、既に登録してるGoogleアカウントで利用できるからとかそんな理由だった気がします。
大嘘こいてるかもしれません。
既に削除しています。

Googleのサービスで思い出しましたが、iGoogleとかPicasaをちょっとだけ利用していたのを思い出しました。
懐かしいです。

ほげほげ

他にも何かブログサービス利用してた気がする……。

おわりに

一応グループ(?)はプログラミングになっていますが、だったらQiitaの方が良い気もします。
ただ、あんまり自分の管理下のものが色々なサービスに分散させたくないので、どうしましょうかね。
考えるのも面倒なので後々やります。

……懐古話ばかりになってしまいました。
年齢は2015年10月25日時点で20歳になり、一昨日(2016年3月18日)は高専を卒業したばかりです。
もう懐古厨ですさよなら。
高専通うとろくな人間にならないよ。

アフィブログ

2014/10/09以来の更新です

今のメインPCは買ってから4年以上経過していて、そろそろ本格的にぶっ壊れてもおかしくない頃なので、新しいPCを買いたいと思います

卒研追い込み期間にメインPCがあぼんしたら困りますしね

新しいPCはBTOあたりで検討していましたが、ちゃんと調べたら自作の方が2万程度安くなるっぽいので、自作にします

CPUクーラー取り付けるのが面倒です

以下、買うパーツのアフィ

以上

HDDが壊れたので

狼電です

サムソン()のHDDでディスクアクセスが止まるようになりました

おかげでWindowsが使えない状態なので、現在USBブートのKNOPPIX()を使うハメになっています

↓の530 120GBに買い換えようかと思っています

以上