■ [unity][作業履歴]箱に弾が当たった場所から8分木で再帰的に分割してみる破壊挙動の実験 
箱に弾が当たった場所から8分木で再帰的に分割してみる破壊挙動の実験。派手に砕け散ってくれるとちょっと楽しい。
このやり方で地面まで全部再帰的に破壊して掘り下げたりできないものかと期待してたけど、画面に見えてる数個の箱を半壊させるだけでも激しく処理落ちしてる。破壊の絵面としては箱のサイズがもう半分くらい小さいものイメージしてたんだけど、個数が爆発的に増えてしまうので無理っぽかった
穴の中を掘り進むくらいの物量を出したいなら、Mincraftみたいなボクセルでやらないとやっぱり無茶かな。その場合、壊れた箱の当たり判定とかをどう処理するのかが悩ましいところだけど
■ 八分木破壊テストのWindows版 
八分木破壊テストのWindows版の実行ファイルをアップロードしてみた。かなり重いので注意。こういうのを思いついたときに数十行スクリプトを書くだけでさくっと試せるのは、Unityのいいところだなぁと思う
今回みたいな自分自身を再帰的に複製するような用途であれば、Prefavを作る必要はなくてそのまま自分をコピーして縮小するだけでいいんだな、と作ってて気づいた。再帰的に8分割し続けるとインスタンスの個数が爆発的に増えてとんでもないことになってしまったけど
こんな感じの再帰的な複製を組み合わせて何か面白い事ができたりしないかな、とか。ゲームエンジンを使ってるとメモリ消費量とかを気にせずに無尽蔵に使える気分で考えられるので、なんだか気が楽。オブジェクト数が万単位になるとさすがに処理がついて来なくなるので、無限の早さのCPUが欲しい
■ メモリの概念がない言語の世界 
h.omae@pigeon6
メモリの概念がない言語の世界からすると、メモリなんか枯渇する方が悪いって考えるだろう。実際、搭載メモリが今の10000倍くらいになったら、大体の実装ではメモリが枯渇しなくなり、メモリ管理は意味を失う。
h.omae@pigeon6
なので、あと10000倍くらいは割とすぐ来るだろうという事、人間側が扱える情報量や解像度には限界がある事、今僕が16GB搭載のパソコンで相当やんちゃしてもメモリ使い切らない事を合わせると、その位の増加度でターンオーバーしそうだな、と
以前作った過去の自分のリプレイと協力するゲーム(http://t.co/e9KbZXVr)のリプレイデータはメモリ消費を気にせず毎フレームすべての情報を生のまま覚える富豪的な実装でも普通に動いてくれたのですごく楽だった。富豪といっても数MB程度なので大した贅沢じゃないかもだけど
次の世代のゲーム機でGB単位のメモリが普通に使えるようになるなら、せっかくの増えたメモリをテクスチャの解像度を増やすだけじゃなくもっと面白い使い方を考えてみるのもいいんじゃないかという気がしてきた
@KidTak MSXのBASICを触ってた頃から見たら無限に思えるくらいに速度は上がってるはずですが、CPUは数倍のオーダーでしか早くならないのにプログラムはループ回数や表示個数をちょっと書き換えるだけで簡単に数万倍の処理を要求できてしまうので、無限はずっと遠い世界の話ですね
■ 「動画 露出」で検索したら 
デジカメなどの露出補正の仕組みを調べようとしていろいろ検索してるときに、そういえば動画を撮る時の露出補正ってどうやってるんだろう？と疑問に思って「動画 露出」で検索したら、さっきまでの検索結果とはあまりに趣の違う予想外の内容が大量に出てきて人間の業の深さを思い知らされた
■ 光源は必ず面積を持っている 
以前IBLを試してたときに、点光源や平行光源はこの世界にはない仮想的な存在で、現実の光源は必ず面積を持っている事と、よく使う点光源の距離減衰の式は光を受ける位置から見た光源の面積が、光源との距離の２乗に比例して小さくなっていくことからが出てきてるんだ、と認識できたのを今思い出した
IBLでは面積を持たない光源は表現できないので、平行光源を表現したいのであれば、有限の解像度の中に太陽くらいの面積を持つ発光体をレンダリングする必要がある。拡散反射で使う光は、そうやって書かれたIBLの法線方向の半球分の値を全て積算したものになる、って解釈でいいのかな
この辺の理解があやふやな状態でもなんとなく光源計算のシェーダーとかが書けてしまうのは良くないなぁ、と思った。まだちゃんと理解できていない事がすごくたくさん残ってそう。こういう分野についてどこかにわかりやすくまとまった解説とかがあったりしないかな
