iOSDC JAPAN 2018に参加＆登壇してきました
2018/08/30〜2018/09/02に開催された iOSDC Japan 2018に参加してきました。
昨年参加し、このカンファレンスの雰囲気にすっかり心奪われてしまった私は、今度はスピーカーとして参加したいと思いCfPを4種5つ出しました。
結局応募締切ぎりぎりまで応募しようかどうか迷っていた「作ってわかるレンダリングパイプライン CPUで3D描画」が採用されました。
なぜぎりぎりまで迷っていたかというと、アイデアとしては考えていたものの応募時点で実装は全く無かったからです。 そのためプロポーザルの最後は「描画させてみます」ではなく「期待通りに描画されるのかを検証してみます」と若干弱気になっています。
できてよかった。
というわけで今年は念願のスピーカーネームプレートもGetです。
会場
今年も昨年と同じ会場だったので田舎者の自分も下調べ無しで安心して向かえました。 ただその油断が命取りで、渋谷駅ダンジョンで3回くらい同じ場所を通り、到着予定時刻から30分以上も遅れました。
それはともかく今年も昨年と同様、非常に快適な時間を過ごせました。 延べ800人超の参加者が集う場所で、このような快適な空間を提供するためにスタッフの方がどれほどの活動をされているのかと考えると頭が下がります。
有志の方々だけで運営されているとはとても信じられません。
今年のお昼ご飯もとても美味しかったです。
聞いたトーク
今年もどのトークを聞こうか非常に悩みました。 まぁ実はその悩んでる時間もそれはそれで楽しいのですが。
個々の感想は書ききれませんが、昨年同様とても興味深い内容でした。 15分、30分と限られた時間の中で視覚と聴覚からものすごい情報量が流れてくるので自分はただただキーワードのメモを取るのが精一杯でした。今もメモとスライドを突き合わせ、内容を見ながら咀嚼中です。
何より皆さん知識も豊富だがトークが本当に上手い。
結局私が聞いたレギュラートークは以下の通り。
前夜祭
- ARKitのための3D算数
- キラリと光るテクニック。アプリをデモするときの心構え
- iOSエンジニアの為のgrpc-swift入門
- 再利用可能なUI Componentsを利用したアプリ開発
- ツールとして利用するUIテスト
- アルゴリズムを通じてよりよいアプリを
day 1
- 複数のライブ映像を同期再生するのが大変だったので知見をお伝えします
- MicroViewControllerで無限にスケールするiOS開発
- 安定したチャットを実現するためのアプリとAPI設計
- grpc-swfitを使ってiOSアプリでも快適なgPRC通信を行う
- 肥大化しがちなアプリの起動経路を整理する
- iOS WKWebViewの魔改造
- Swiftコードから状態遷移図を自動で生成し、継続的にメンテナンスしやすくする
- 差分アルゴリズムの原理について
day 2
- iPhoneが数秒おきにクラッシュするんだけど！
- 詳解Fastfile
- Depth in Depth
- ARKit Maniacs
- Synchronized iPhones!
- iOSアプリ設計パターン入門 執筆陣によるトーク(アンカンファレンス：正式名称不明)
day 3
この自分の発表の後、LLDBの話を聞こうか圏論の話を聞きに行こうか直前まで迷っていましたが、緊張の糸が緩んだのでしょうか。しばらく放心状態になっている間に結局時間が過ぎ、どちらも行けませんでした。勿体無い。
登壇
というわけで最終日、発表当日。実は偶然にも誕生日でした。
自分で言うのもなんですが、それなりにいい出来だったのではないかと思います。
3D描画の仕組みを解説し、Swiftでどのように実装したかを簡単に説明しました。 そしてデモでは実際に自作のパイプラインで色々なオブジェクトを表示し、簡単な3Dグラフィック表現を解説しました。 使ったモジュールはFoundationとsimdのみです。
リクエストが有ったのでコードは少し整理した後、近日中にアップロードする予定です。
(2018/09/05更新:GitHubに公開しました。リリースビルドしないと遅いです。)
反省点
タイトル
まず、タイトルに「レンダリングパイプライン」は使わないほうが良かったなと後悔しています。 CfP応募時の注意書きにも書いてあった気がしますが、やはり一般的でない用語は避けるべきでした。
申し訳程度に「CPUで3D描画」とは付けていましたが、よくよく考えるとそもそも3D描画処理がどこで行われているかに関心がある人はそれほど多くないと気づきました。 ARKitもSceneKitもMetalもAPI、つまり結局はインターフェースなので実装側がどうなっているかは別に意識しなくても良いわけです。
#iosdc #b のセッション人少ない。裏セッションが強いのわかるけど、CfPを僕なりに解釈すると「ゼロから作る3Dエンジン」って話だと思われ、すごくおもしろそうなんだけど。
— Shuichi Tsutsumi (@shu223) 2018年9月2日
#iosdc で今日興奮したのは、@ta_ka_tsu さんの発表。
— K-BOY@筋肉エンジニア (@kboy_silvergym) 2018年9月2日
これSceneKit使ってなくて、Swiftで.objファイルをパースしてレンダリングもswiftで書いてCPUで動いてるの、めちゃカッコイイと思った。
『ScenKit？邪道！3DレンダリングパはSwiftで作れる！』的なタイトルだったらもっと人来たかな笑 pic.twitter.com/dLrSstWh73
まさにお2人のおっしゃる通りで、 「3D描画エンジンを作る」 「SceneKitなどを使っていない」 ことを明確に主張すべきでした。 そのほうが「えぇ！？一体どうやって！？」と、好奇心を刺激でき、もう少し人を集めることができたかもしれません。
デモアプリ
もう一つの反省点は一言で言えばデモアプリに関して注意が足りなかった点です。 当日の朝、接続チェックを行った時点で実機で動作することを確認し、QuickTimePlayerで実機の画面をスクリーンに表示できることも確認しました。これでもう準備万端だと思い込んでいました。
が、発表直前にデモ用アプリを起動すると クラッシュしました 。それはもう血の気が引きました。 開始時間も迫りスタッフの方も緊急事態を察知したのか「どうしました？」「デバッグログ見たほうがいいかもしれません」と色々助言を下さいましたが、さすがにデバッグしている時間は無いと判断。 結局シミュレーターでデモを行うことにしました。
「シミュレーターで動作しているということはMetalを使っていない証拠です」
とか、苦し紛れの言葉が出てきましたが、 OpenGLESや上位レイヤーのSceneKitならシミュレーターでも動作させられる ので実は説得力はありません。 せめてパイプラインの途中でブレークポイントを仕掛けて、生成されたフラグメントの中身を見てみるぐらいの機転が利けばよかったのですが。
で、肝心のクラッシュした原因なのですが、メモリの使いすぎです。
そうです。ご存知、 Message from debugger: Terminated due to memory error です。
デモで使用した*.objファイルのサイズは大したことは無いのですが、ファイル読み込みから頂点列を生成するにはそこそこ時間がかかります。 タップして数秒待ってモデルが表示される、というのは見る人にとってもストレスですし、なにより発表時間を無駄に使うことになります。 そのため、起動時にデモで使用する全てのモデルを読み込みあらかじめ頂点列を作っておいて、UITableViewをタップして切り替える、という方針を取ったのですがこれが良くありませんでした。
つまり、当日の朝に接続チェックをした時点ではたまたまギリギリ動いていただけで、本番直前ではOSに「メモリ使いすぎ」と強制終了させられていたのです。
実は、当日の午前中 @noppe さんの発表内で
*.movファイルを画像のシーケンスにしてUIImageViewで表示する方法を試した
→Message from debugger: Terminated due to memory error
という箇所があり、「わはは、あるある。」などと聞いていたのです。 実際、その時の私のツイートがこちらです。
— ta_ka_tsu (@ta_ka_tsu) 2018年9月2日
そのまさに数時間後、 それをデモアプリで発表直前にやらかしたわけです。 あぁ顔から火が出るほど恥ずかしい。メモリ使用量ぐらい確認しとけよ、お前一体何年ソフトウェアエンジニアやってんだよ、と。
まぁそんなわけでもうお恥ずかしいとしか言いようが無いのですが、今後の戒めのために晒しておきます。
最後に
今年はスピーカーとして参加できました。発表準備も大変でしたが、スピーカーとして参加できて本当に良かったと思います。 去年より顔見知りの方が増えて、スピーカーディナーでも懇親会でも絶え間なく誰かと話せました。今年は3Dプログラミングをやっている人ともたくさん知り合うことができました。
また来年も参加したいと思います。
なお、懲りずにまたCfP応募するつもりです。
