2018-11-12
2018-11-04
Colaboratryで作ったphythonコードをローカルのJupyter Notebookで動かそうとしてハマったときのメモ。
■ Windows10でTensorflowとKerasをインストールしようとしてハマった話 
pip install tensorflow
でインストールしたtensorflowが「ダイナミック リンク ライブラリ (DLL) 初期化ルーチンの実行に失敗しました。」というエラーで動かず、
conda install tensorflow
で動いた。
たぶん vs2015_runtime: 14.0.25123-0 --> 14.0.25420-0 が入ったおかげかも。
こういう罠にはまらないのでColaboratoryは便利。
■ mnistのサンプルで TypeError: softmax() got an unexpected keyword argument ‘axis’というエラーが出る 
model.add(Dense(10, activation='softmax'))
を実行すると、kerasがバージョン2.1.6だとエラーが出るらしい。2.1.3に戻すとそのまま通る
pip install keras==2.1.3
■ Deep learningで画像認識⑦〜Kerasで畳み込みニューラルネットワーク 
Kerasでは、「ImageDataGenerator」というクラスが用意されており、元画像に移動、回転、拡大・縮小、反転などの人為的な操作を加えることによって、画像数を増やすことができます
2018-06-30 
フォトグラメトリの実験として、iPhoneで撮った動画を3DF Zephyrで3D化したものをUnityでVR表示してみた。デフォルト設定でそのまま変換しただけでも予想以上に高精度で形状の破綻も少なく、まつ毛くらいの細かさまでちゃんと識別できるくらいに再現できてる
今回は一分半くらいの動画から500枚を切り出して加工したんだけど、このくらいの枚数があれば十分っぽい。写真だとシャッター音で目が覚めることもあるし、枚数を取るのも大変なので動画からの切り出しでどこまでできるか気になってた。切り出した画像に多少ボケたものが混ざっててもあまり問題はないっぽい
子供のスケール感は時間がたつと忘れてしまいそうなので、今のうちに3D化して保存しておいて、後でVRで比較できるようにしておきたくて、これまでも定期的にいろんな角度からの写真だけ撮り溜めてたけど、写真を大量に撮るより動画のほうがだいぶ楽なので今後は気軽に撮れそう。欠点は寝てるときしか撮れないことか
VRが当たり前になったら、適当に撮った動画をサーバに送って3D化してVRで見る、みたいなサービスも当たり前になったりするのかな。周りからぐるぐる撮るだけでいいので「ちょっとめんどくさいパノラマ写真」くらいの感覚で3D空間を切り取って保存したりできそう。
静止画で見てもぱっと見で写真と区別がつかないくらいの品質のものが、そのままくるくる回せるのは結構なインパクトが。フォトグラメトリも4年前に試してた時より色々進歩してる。Houdiniが使えるようになったおかげで後処理もかなりやりやすくなった
2018-05-03
最近は子供が昼寝から起きたら作業中断になるので昼間はほぼ何もできない…
■ [Houdini]プリミティブ端のエッジを除去して中のラインだけ残す 
convertLineを参考に。
int n[] = neighbours(1, @ptnum);
foreach(int pt; n){
int e0 = inpointgroup(1, "edge", @ptnum);
int e1 = inpointgroup(1, "edge", pt);
if( (e0==0 || e1==0) && pt<@ptnum){
int pr = addprim(geoself(), "polyline");
addvertex(geoself(), pr, @ptnum);
addvertex(geoself(), pr, pt);
}
}
追記：上記だとまずいパターンがあった。単純なvoronoiであれば問題ないが、複数の分割が重なって、エッジの中央に他のポリゴンの点があるなど、共有されない頂点で割られている時にうまく動かない
そういう形状の時は、いったん綺麗な形のポリゴンになるように前処理してやる必要がある
- scatter→voronoifractureだと裏面ポリゴンが生まれるケースが多いので、deleteで裏面を削除してから作業開始
- エッジが共有されていない時には、groupのunshared Edgesがうまく動かないので、fuseで連結した後にcleanで重複したラインやポリゴンを削除してから実行する必要がある
追記２：さらにまずいパターンを発見。エッジが共有されていない分割だと、Group SOPのエッジ検出がポリゴンの内側にエッジがあるとみなしてしまっておかしくなる
対策として、ConvertLineしたラインの向きベクトルを微小にしたものから計算した、左右斜め前両方のポジションでレイキャストしてどちらかが抜けてたら弾く、という処理にしてみた。
float delta = 0.01;
int pn0 = primpoint(0,@primnum,0);
int pn1 = primpoint(0,@primnum,1);
vector p0 = point(0,"P",pn0);
vector p1 = point(0,"P",pn1);
vector dirVec = normalize(p1-p0) * delta;
vector crossVec = dirVec;
crossVec.x = dirVec.z;
crossVec.z = dirVec.x;
vector chkPos = p0;
chkPos.y = delta;
vector chkDir = {0,-1,0};
vector cp0 = chkPos+(dirVec+crossVec);
vector cp1 = chkPos+(dirVec-crossVec);
vector retPos;
float retU, retV;
int ck_l = intersect(1, cp0, chkDir, retPos, retU, retV);
int ck_r = intersect(1, cp1, chkDir, retPos, retU, retV);
if( ck_l == -1 || ck_r == -1){
removeprim(geoself(), @primnum, 0);
}
余りに鋭角なポリゴンだと検出点に引っかからない可能性はあるが、それ以外はたぶんこれでほぼどんな形状になっても大丈夫？
■ [Houdini]polyExpand2Dで失敗するケースへの対策 
上記で作ったLineをpolyExpand2Dでポリゴン化しようとすると、重複したラインがある為にそのままでは失敗する。
intersectionStichで交点で分割することで、長いポリゴンの辺になっていて、間に点のある重複したラインを分割できる
実用的な複雑な形状だと、intersectionStichしても失敗するケースがある。
その時は、intersectionStich → fuse → intersectionStich とつなぐことで、polyExpand2Dが成功するようになる
これで、ブロック内を任意のポリゴンで分割したときに、間にできる道をpolyExpand2Dで作ることができるようになる…
2019/07/15追記
fuse->intersectionStich->fuse で中点を消すパターン、cleanで綺麗になるケースもありそう。要検証
外周のエッジのみ消す方法は、traianglete2d(凸型限定)->clean->groupでエッジ抽出
したものを、groupTransfarでプリミティブに転送(このとき、include only Elements Entirely.... をONしないと余分に転送される)してblastすれば消える
2018-05-02
■ [Houdini]プリミティブ内の最長ラインを検索 
先端になるpoint配列を生成してインデクスをbasePtNumのattributeに詰めて、findshortestpathのStart PointsとEnd Pointsを、
`point("../pointwrangle3/",detail("../foreach_count1/","iteration",0),"basePtNum",0)`
みたいな形でインデクスを二重ループで取り出した。
findshortestpathのStart PointsとEnd Pointsは文字列なので `` で括る必要があったが、よく見たら Output Pathsに「Fron any start ton any end」って項目があったので、もしかして頂点番号リストを文字列で渡せば二重ループはいらない？要検証。
元ネタ：
https://twitter.com/veltman/status/973570650429206528
https://bl.ocks.org/veltman/403f95aee728d4a043b142c52c113f82
2018-04-07
■ メモ： 
ボリュームレンダリング
- 球体のフォグボリュームを計算
- http://www.iquilezles.org/www/articles/spheredensity/spheredensity.htm
- 濃度マップをインポスタで360度分用意して回転に対応
- 低解像度2Dバッファに重なっているボリュームのインデクスのリストを生成して、レンダリング時にその数だけ合成
ビルボードレイマーチ
2017-11-04
■ [SH17A] Tiny Clouds 
#define T texture(iChannel0,(s*p.zw+ceil(s*p.x))/2e2).y/(s+=s)*4.
void mainImage(out vec4 O,vec2 x){
vec4 p,d=vec4(.8,0,x/iResolution.y-.8),c=vec4(.6,.7,d);
O=c-d.w;
for(float f,s,t=2e2+sin(dot(x,x));--t>0.;p=.05*t*d)
p.xz+=iTime,
s=2.,
f=p.w+1.-T-T-T-T,
f<0.?O+=(O-1.-f*c.zyxw)*f*.4:O;
}
これだけのソースで雲が描画できてる
■ 『UnityのWebGL出力に簡単に無料でグローバルランキングを実装できる仕組みを考えてみた』 
- https://qiita.com/divideby_zero/items/50897a2695aa04bfeb69 … ランキングにGoogleスプレッドシートを使う方法はこちらを参考にした。読み書きに約2秒かかるけど、簡単な手続きで使えるのでとても便利
2000年代のゲーム開発だとわりと大規模なタイトルでもまともなユーザーテストはほとんど行っておらず、ゲームバランスもディレクターの経験とカンで調整されることが多くて、詳細なプレイログが自動で取れるようになって以降もこの手のデータ分析はわりと最近まで軽視されがちだったような印象が
最近は自動収集したログを開発に使用する事例も増えてるけど、この手の手法は個人製作など小規模な開発でもかなり有効じゃないかと思う。小規模だとテストプレイをお願いするのも難しくなるので、テスト規模が小さくて遠隔でやることも増えるため、数少ない収集データを詳細に分析する意義は増えそうな
リトライ回数とタイムの相関グラフを出してみた。70回で2分半、150回で2分20秒、250回で2分10秒、2分の壁を切るには400回と、タイムが減るにつれて必要なリトライ回数が指数的に増えていってるのがわかる。
プレイ時間とタイムの相関グラフも出してみた。2分20秒を出すのに必要なプレイ時間は30分で、2分10秒で2時間、2分の壁を切るには5時間と、こちらも経過プレイ時間が指数的に伸びているというわかりやすい結果に。
2017-11-03 
Tofu Racer、気が付いたら累計プレイ人数が1000人を超えてたので、ログに記録されてる情報を集計してみてる。今回はサーバにGoogleスプレッドシートを使用してるのでいろんな数字を簡単に確認できて楽しい
プレイ時間については、トップ10に入るような人は大抵5時間以上遊んでくれているが、中にはたったの110分で２分の壁を越えてトップ10に入っている人も。一番長く遊んでくれている人は20時間近くも遊んで頂いてて、本当に感謝です！
1100人の延べプレイ時間は約315時間。今回のゲームは製作時間が60時間くらいだったので、開発時間をプレイ時間が上回った。個人製作のゲームは大抵「開発にかかった時間＞合計の遊んでもらえた時間」になって赤字になりがちなところなので、今回は大幅な黒字になってとても嬉しい
全体のプレイ時間を平均すると1人30分くらいになるけど、トップ10人の合計だけで全体の３分の１に相当する90時間になり、プレイ時間を多い順に並べたグラフを見ると、わりと綺麗な曲線で減っていってるのがわかる
ゲームを起動したけど一度もゴールに到達しなかった人は1100人中600人。約54%の人がゴールする前に遊ぶのをやめている。これはクラッシュ時のペナルティが大きすぎたせいかも。反省。
ゴールに到達しなかった人の中で一番プレイ時間の長かった人は、1時間以上かけて300回もリトライしながら、一度もゴールせずに諦めてた。大変申し訳ない感じ。
操作方法をログで確認したら、トップ5に入る人は皆キーボードでプレイしていて、パッドは使用していない。これはかなり予想外の結果…。シビアなアクセルワークは必要ないゲームとはいえ、アナログ操作できるパッドのほうがタイム的には有利だと思ってたので。
視点については、トップ10に入っている人のほどんどは車が見える後方視点ではなく、ドライバー視点でプレイしていた。シミュレーション寄りのゲームだとドライバー視点のほうが遊びやすいと思ってるので、こちらは納得の結果に。
2017-10-22
■ [Houdini]OSM+Houdini 
houdini game dev toolのopen street mapでニューヨークを取り込んでFBX出力したものを、UnityでGoogle Mapの衛星画像と合わせてみた。OSMの道路データも加工できると面白そうなんだけど、そっちは簡単にはいかなそう
Yoshiaki Higa @YoshiakiHiga 10月21日
道路はラインポリゴンで読み込まれるのできれいに作ろうとしたら難しそうですね。自分も色々やってますがなかなか上手くいってないです。地図画像のスクショとって画像からジオメトリ生成するのがきれいにできそうです。（多分）
いただいたアドバイスを元に、地図の画像から道路の色を抜き出してポリゴン化してみた。
画像解像度より細かくしたGridにUVを割り当てて画像を転写して、Wrangleで色の白いところだけを残して頂点を削り、fuseしてから、Groupで端のエッジをグループ化。Groupでエッジを残す方法は以下の通り。
この後は、dissplveで端のエッジグループ以外を削除。ここでfuseしてないといるエッジまで消える？この辺トラブってた。
最後にresampleで適当に削ってるけど、ここももっといいやり方ありそう
2017-10-14 
とはいえ一応挙動のほうも遊んでくれた方には想定してた感じで楽しんでもらえてるようでよかった。Unityだとこういうのが思いついたときにさくっと作れるのはとても助かる。昔はゲームエンジン否定派だったけどこれを経験するともう戻れない…
物理シミュのおかげでいろんな現象が自然に再現されたのは面白かった。ヒルクライムでハンドルを切っても全然曲がらず一瞬バグかと思ったけど実際もそうなるらしいし、重力の影響で登りと下りの加速度の違いも自動的に生まれてて、このへん全然調整してないのにそれなりにバランスが生まれるのは楽しい
あと、何も特別な実装をしてないのにロケットスタートが勝手にいい感じの挙動になってたのも驚いた。スタート前にアクセルをふかしすぎると摩擦円を超えてスリップするし、アクセルONの時間が短すぎると加速が鈍くなる。こういうのが何もしなくてもうまく動くのはシミュレーションならではか。
タイヤの摩擦円の縁で滑り始める直前の所ちょっとだけグリップ力が向上する領域を作ると、タイヤが地面を噛む感じでちょっと粘り気が出るような印象の挙動になったのも面白かった。現実のグリップ力の遷移もそういうものらしいけど、詳細なデータが見つからなかったので目分量で適当にグラフを作った
前後左右の荷重移動もばねの硬さとダンパーはForzaの摩擦円を見ながらそれっぽくなるような適当な値に設定。少し左右の揺れが大きすぎる気がするけど、これは実車ではばね以外の色んな機構で吸収されてるのかも。ちょっと極端なくらいのほうが面白いかと思って放置した
しばらく前から一歩二歩はいはいで動くことがあったけど、今日完全にはいはいをマスター。
最近の週末は子供からの遊んでくれ要求と奥さんからの子供の面倒を見てくれ要求に答えてたら気がついたら1日が終わってる感じが。
2017-10-13 
Tofu Racer、作ってた期間は3週間くらいだけど何もしてない日もあるので、作業時間は1日平均4時間×14日くらい。作業の内訳は挙動の調整とコース選定に約1週間、効果音の追加が3日間で、ランキングとUIがおおむね4日間くらい。
タイヤ関連や衝突の効果音だけで丸三日くらいの作業量になった。４輪それぞれで荷重と速度に合わせてスリップ音+加速/ブレーキ音をピッチを変えつつ鳴らして、エンジン音に加えて速度が上がったときの走行ノイズも付与。衝突音も衝撃ごとに5種類鳴らし分けてる。
SEの調整には結構時間がかかったけど、音が入るだけでタイヤの状態が感覚的にわかるようになって一気に走りやすくなった印象が。ハンドルやコントローラー振動のフィードバックもないので、このゲームでは効果音は車の状態を知る重要な手掛かりになってる
昔同じようなものを自前のエンジンで作ったときには数か月～年単位の時間がかかってたところが3週間でちゃんとゲームっぽく遊べるものになるあたりはUnityって便利だなぁ、とあらためて思う。絵、物理、音が何もしなくてもすぐ使い始められるのはすごく有難い
あと今回タイムアタックが楽しめてる理由の9割以上はアセットストアで購入したコースのおかげ。いくつか試した中でも抜群によくできてた。左右に連続するコーナーに高速セクションもあり、微妙な凹凸もいい仕事をしてくれててほんと素晴らしいコース
https://www.assetstore.unity3d.com/jp/#!/content/70655 …
挙動を調整してたときのテストコースはHoudiniで適当に作った道っぽいポリゴンとかジャンプ台とかが平面の上に置いてるだけの殺風景な状態だったので、こんな状態のものをリリースしても誰も遊んでもらえなかっただろうなぁと思うとAssetStoreってほんと素晴らしい
2017-10-11 
https://twitter.com/Nao_u_/status/918110664287141890
今日のTofu Racer、ダウンヒルの一位と二位が1分49秒63でぴったり同タイムに。小数点2桁では足りなかったか…とサーバの記録を調べたら、どちらも1分49秒6336。記録されてる限界の4桁まで一致してて、本当に同一フレームでゴールしたらしい。こんなことってあるんだなぁ…。
2017-10-09 
ダウンヒル、ヒルクライムともにyamagutisizuwoさんに一位を奪われた。
特にダウンヒルは挙動の作り始めから2週間走ってやっと出たタイムだったのに。理屈では２分切れそうに思ってたけどまさか公開数時間であっさりと達成してしまうとは…。どんなラインで走ってるかリプレイが見たい
現在ダウンヒルで最速の1'54.75のリプレイ動画、すべてのコーナーで迷いなくスムーズに荷重移動されててほんとすごい。第二チェックポイント直前の高速区間では130km/h超えてる。こんなタイムが出るとは想定してなかった…
ヒルクライムも一度減速するとその後伸び悩むし、荷重のかかり方も違うので下りとはまた違った難しさがあるのにこの動画はすごく丁寧に走っててこちらもすごい。ダウンヒルの伸びしろを考えると、もしかしてヒルクライムでも２分切れたりするのかな…
今月に入って離乳食が1日に2回になった結果、液状だったうんちが固形に近くなり、匂いもヨーグルトのような芳香だったものが人間のものに近くなってきた。ずりばいが上手になり、呼べばこちらに来るようになった。寝たきりだった頃から考えるとすごい進歩。移動範囲が増えたので気をつけることも色々増える。
2017-10-08
■ Tofu Racer 
https://twitter.com/Nao_u_/status/1081388036812791809
Unityで４輪の荷重と摩擦円をシミュレーションしたレースゲームを作ってみました。ブラウザで遊べて、インターネットランキングに対応しています。
今回のは自分にとっての理想のレースゲーム挙動を目指して作ってた。シミュレーション的な荷重移動の重要性と昔のアーケードゲームのような気持ちいいコーナリングの両立を目標としてパラメータを調整してて、おおむねイメージしてたような動きが実現できたように思う
初期の頃は市販車の挙動を参考にしてたのでグリップ走行でしか曲がれない状態だったけど、セガラリー風に後輪が流れるほうが楽しいのでそっち方向に寄せて調整。この手の挙動を楽しく感じるのが自分だけだったら嫌だなぁ、と思ってたけど想定よりたくさんの人にタイムアタックしてもらえてとても嬉しい
実車再現のシミュレーションだと開発者が狙う「面白い挙動とコーナーの組み合わせ」で固定したタイムアタックがやりづらいのは最近のレースゲームが失ったものの一つではないかと。セガラリー２面や３面中盤の舗装路の挙動とコースの組み合わせが絶妙で気持ちいい、みたいなのはリアル系では難しい
セガラリーはこれまでで一番たくさん遊んだレースゲームなのであの挙動が体に染みついているんだけど、荷重移動がちょっと固く感じるのと、アクセルオフ時の減速が激しいところは気になってた。あと舗装路でもかなりタイヤが滑る印象があるけど、実際のラリーでもあのくらい滑るものなんだろうか？
2017-10-04
■ 
ランキングのめどが立ったので、残りを仕上げる作業に入る。
タイトルとﾗﾝｷﾝｸﾞ画面の分離、開始前のカウントダウン、ゴール表示の繊維を実装。
あとひっくり返った時に自動で復帰する機能と、開始前のカメラ演出も追加。
あとゴール後とリザルトが入れば最低限のシーケンスは通る。
これで残り作業の大きいのはランキングの送受信と、ボイスとクラッシュ音、UIの整理か。