今週は色々とマーカーの向きを検出する方法を実験してましたが、 なかなかうまくいきませんでした。 うまくいかなかった例 ・マーカーの内側を四角ではなく、5角形（SDカードみたいに、4角形の角の一つを切り落としたもの）にしてみた 期待：内側の輪郭点のうち、隣り合う輪郭点との距離を計算し、2点間の距離が最短になれば、その2点が切り落とされた角になるはず。 結果：角の落とし方が足りない場合、カメラとの距離があると4角形と認識されてしまった。また、角を落としすぎた場合は2点間の距離がほかの4辺と似たような値になってしまい、安定しなかった。 ・5角形を再び利用。 期待：輪郭点間の距離ではなく、2組の輪郭点が成す直線が並行であれば、その輪郭点が基準点となるはず。（図形の赤い線） 結果：これも上記と同じく、誤判定が多く失敗。 いいマーカーの形は無いかな～とマーカー検出のネタを探してみると、 四角か丸のマー

はじめに 土日は久しぶりに一般参加者としてOcufesに参加してきました。そのため出展側で参加するいつものOcuFesよりも多く他の方のアプリを体験することができました。盛況だったので残念ながら全てのコンテンツを体験することはできませんでしたが、酔い対策もフレームレートも十分なコンテンツ、スマートフォンなので時々フレームレートが落ちるが許容範囲なコンテンツ、このご時世にOculus ReadyどころかGPUを搭載していないノートで展示しているコンテンツなど、色々体験しましたが、一つ気になったのがフレームレートは足りているのにカクカクするコンテンツです。「フレームレートが足りているのにカクカクするってどういうこっちゃ」と思われる方が多いと思いますので、以下で解説していきます。 描画のフレームレートと物理のフレームレート UnityのMonoBehaviourにはUpdate(LateUpda

アプリ自体のコーディング見積もりのみに注力してしまうと忘れがちで、たまにつらい目に遭うので、必要に応じて追加していく予定。 アプリ仕様 仕様はそもそも決まっているか 「仕様は決まっている。動かない」「移植なのでこれ以上はありません」と言ったな。 それは嘘だ。 既に仕様がガッチリ確定していることはありえない。要求仕様（必要機能リスト）がある程度固まっているならばまだ良い方で、「今から仕様を一緒に考えていきましょう」「アイディアレベルです」まで様々。 その他にも、GCM/FCM等のアプリ外サービスと連携する場合、遅延コスト等どの程度許容できるかも事前に確定させる。特にプッシュ系サービスでは、ありえないレベル（全端末遅延1秒以内必須、とか）を既定路線に含めないように留意する。 改修か、新規開発か これは見積もりの前提として大きな影響力をもつ。 テクノロジーや設計の自由度・柔軟性をある程度コントロ