sf3d
いそがしくて二ヶ月程、更新を休んでしまったがこおkでやめては3日坊主ならぬ3ヶ月坊主なので更新します。
sf3dとは以前紹介したSFMLに存在しない3Dレンダリングを行うことができるライブラリで、下記のURLがそのライブラリのgoogleグループのURLである。
https://code.google.com/p/sf3d/
使い方はまださして調べていないのでなんとも言いがたいが、sfmlのフォーラムに上がっていたコードを読む限りでが、主にシングルトンパターンを用いて作成されているようであった。
命名ルールはSFMLとは違いメンバ関数は全て大文字から始まっているようで、そのあたりを合わせていないのが少し残念なところである。
まだ、実際に使ってみたわけではないので、感想というものは挙げられないが、そのうち触ってみたいとは思う。
注意点としてはライブラリをビルドするためのMakefileやConfigrueスクリプトは無いので、自分で作成する必要がありそうだ。
よくわからん
Arch Linuxはよくわからん。
先日、よく説明を見ずに眠気眼でEnterキーを連打して依存関係を吹き飛ばしたraspberry piにArch Linuxを突っ込んでみた。
そう、Arch Linuxといえばなんでもかんでも最新版がバイナリでリポジトリにはいってて、「アップデートしたら動かなくなっただと。。。2,3日待って"pacman -Syu"すれば動くだろ」とか言いそうなあれである。
個人的には最新版をビルドする手間をかけずに試せるというのは好みではあるが、2,3日使えんのは致命的なのであまり使いたくないやつではあるが、raspbian上でglibc、gcc、clangのビルドをしようものなら、2,3日とは言わず1週間以上掛かりそうなので、その辺りは妥協してArch Linuxを使うことにした。
実際に使ってみるとCUIでしか使わないという事もあってか特に困ること無くパッケージを追加しようと思ったのだが、早速問題が発生した。
なんとgccのバージョンが4.7.2ではないか。
自前でビルドしようかと悩みつつ他のboostやらsambaやらを追加、設定を行った。
その後なんとなく、pacman -Syuを叩いてみるとあら不思議、gcc 4.8.2がリポジトリに追加されているではないか。
これはラッキーと思いそのままアップデート。
その後とりあえず、無線LANを使えるようにしようとペチペチしていると何回試してもwpa_supplicantでエラーが出て接続できない。
何かオカシイと思ってrebootしてみると、sshガガガな状況に…
いや、sshd_configを弄ってからsshdを再起動してもrootでログインできたりと色々おかしかったから何かあるなとは思ったけども。。。
しかたなく、ディスプレイに接続して見てみると、何かよくわからないエラーをはいてbootできないようだったので諦めてもう一度フォーマットしてからOSを書き込むことに。
第2ラウンドは1回目に忘れていたパーティションの拡張を先に行う事に。
参考は
トマト農家のロボット創り Robot creation by tomato farmer: An installation Arch Linux ARM on Raspberry Pi. (archlinux-hf-2013-07-22.img)
とりあえず、パーティションを切り直したら起動させてパッケージのインストール。
今度は前回とは違って先に無線LANの設定に。
ごくごく普通にwpa_passphraseから、wpa_supplicant。
第1ラウンドの時の苦労が嘘のように1発で通ってしまった。
何がダメだったのかよくわからないのが本来なら不味いところだが、マジで良くわからんのでとりあえずOKってことにして、続行。
sambaとsshの設定もして、快適Raspi Lifeを過ごせる事に。
だが、ここで終わらんのがArchさんというか私。。。
なぜかmakeが通らん。
何か未知のWarningが出てて何か時間がかかりすぎているということしかわからん。
とりあえずこれが土日の成果である。。。悲しい。。
Ogre3D
先週はFSMLというライブラリの話を書いた気がしたので今回はその続きとしてOgre3Dについて書く。
Ogre3DはDirect3DとOpenGLのラッパライブラリである。
先週紹介したFSMLとの違いは主に4つ。
1つ目は、先の軽い説明にあったようにOpenGLだけでなく、Direct3Dも使える点。
2つ目は、3Dの描画にも対応している点
3つ目は、描画にのみ特化しているためサウンドやネットワーク、ファイルIOなどの機能が実装されていない点
4つ目は、動作環境がWindows、それもMinGWもしくはVisualStudio
となっているらしいが、cmakeでエラーがでているお陰で未だにコンパイルできておらず1度も使っていないので、正直感想という感想も思いつかない。
API Documentを見た限りでは、SceneNodeやEntityというクラスが見えたので、ゲーム等を作る時に重宝しそうなクラスはいくつか見受けられた。
しかし、何度もいうようであるが、まだ1度も使っていないのでなんとも言いがたい。
師走というだけあって今月は非常に多忙で、帰宅してからPCをつけて自分の趣味を楽しむ時間もろくにないので、おそらく使用体験は来月になるのであろう。とか言っても、未だにノートPCに突っ込んだSUSEのもろもろの設定すら終わっていないのに言えたものでもないのだが。。。
SFMLがいい感じ
SFMLというOpenGLのラッパライブラリがすごく使いやすくていい感じだったのでそのまとめ。
SFMLとはSimple and Fast Multimedia Libraryの略で、マルチプラットフォームで利用できるだけでなく、C++やJAVAといったコンパイル言語だけでなく、RubyやPythonなどのスクリプト言語でも使用することができるライブラリである。
さて、どこがいい感じかと一言でまとめると簡単という所である。
一般的にというか、DirectXとOpenGLを触った経験での話だが、描画系ライブラリを扱うには莫大な量の学習コストがかかる。人によって差は大きくあるだろうが、私の場合ただ三角形を描画して、回転させるというプログラムを理解するのに2週間以上、かかった記憶がある。さらに言うなら、DirectX11を利用するには、COMコンポネートの知識は必須なので、そちらの方の勉強にも時間を割かなければならないので学習コストはさらに増加してしまう。
ここまできてやっと色々な物を描画できるぞ、と言いたいところだが、最近の描画ライブラリではパフォーマンスの関係で、固定パイプラインを利用した描画系を推奨していないため、基本的にシェーダプログラムを自分で勉強しなければならないわけで更に学習コストが増加してしまう。
これらの事を勉強している間に何かスクリプト言語を1つ覚えれそうなものだ。
それに比べて、SFMLはいい感じであった。
用意されている機能として、描画系の他にGUI系などもはいっているため、Cで書かれたGLUTを使う必要はない。
それに付け加え、たったの50行程度で、適当な画像ファイルをテクスチャにした、正方形を回転させることができた。
しかしながら、SFMLにも当然だが欠点がある。
このライブラリは3Dの描画には非対応なのである。
個人的にはわざわざ描画ライブラリを使うからには何かしらの3Dを使うことを目的としているので、非常に残念に思う。
ディスク容量との戦い
Linuxをインストールしようと思ったがディスク容量が足らん。
そもそもなぜこういう事になったかというと、Windowsをクリーンインストールしたら、今まで使ってたライブラリを全部ビルドし直す羽目になってめんどくさいという事である。
そんな事でいちいち面倒とか言うなよと思うかもしれないが、私の場合Cygwin内のgcc、QtCreatorと共に突っ込まれたMinGW内のgcc、MSVCの3コンパイラで少なくともOpenCVとboostの2つのライブラリをビルドしなければならない。正直言って面倒だが、やらねば、色々と都合が悪いのである。
そこで、Linux系OSをデュアルブートすればgccでのコンパイルの必要がなくなるのではと思ったが、現実は甘くなかった。
そう、ディスク容量が足りないのである。
まず、HDDの容量自体旧世代のノートPCであるが故、もとから小さく80GBしかない。そこにWindowsを突っ込んで、VS2013とCygwin、QtCreatorを突っ込んだだけで、なんと残り40GB。そこから今後なにから突っ込むことを考慮すると半分位は残しておきたい。そうなるとLinuxを突っ込める領域は20GBしかない。
いやいや、20GBもあれば軽量Linuxな余裕じゃないかと言われると辛いところだが、私はLinux初心者であり、あまり多くのディストリビューションを知らないので、できればUbuntuみたいな初心者でも安心みたいなLinuxを使いたい。だが、当のUbuntu13.04を突っ込んでいるPCのHDDの使用容量を見てみるとSwap領域抜きで18GBを使用していた。20GB割り当てるとした時の実に90%である。さらにインストールするPCのメモリの搭載量的に、Swap領域として、少なくとも2GB位欲しいので、ちょうど20GBとなる。
これは、不味い。
何かいい方法はないかと1週間考えたのだが思いつかなかったので、とりあえず、知ってるディストロを突っ込んで行こうと思い早速足りるかわからないUbuntuをインストール。
サイズは大丈夫そうなので、試運転中。
もう少し使ったら感想を…
OpenCV2.4.7…知らない子ですね
知らない内にOpenCV2.4.7がリリースされていた。
知らないと思ったら、それはそうだ。なにせデスマ&ノートPCが一時使えない状態にあったのだから。
それはそうと、更新内容としては
- OpenCLへの新規最適化の追加とバグの修正など
- CUDAでのバグの修正
- Android NDKの最新版への対応
- その他のバグの修正
らしい。
OpenCLって何だったかなと思って調べてみると多種多様なデバイス(GPUとかCPU)を利用した並列計算を共通のAPIで扱うことができるらしい。CUDAとOpenCLどちらのほうが早いのか気になる所だが、あまりホイホイやってると他の環境でコンパイルするときに面倒なので、需要があれば今度試すことに。
とりあえず、その他のバグの中にWindows版でのコンパイルエラーが含まれているのかがすごく気になったのでとりあえずダウンロードして来ることに。
いつも通りcmakeしてからプロジェクトファイルを開いてビルド。。。
結論から言うと直ってません。
少なくとも私の環境(VS2013 EE)では。
とりあえずエラー内容の確認
- maxはstdのメンバではありません
- {に対応する}がありません
だ。
1つ目は"opencv/sources/3rdparty/openexr/IlmImf/ImfHeader.h"に"#include
もしこれでmaxは~のエラーがでるならそのファイルにも"#include
2つ目は自分では良くわからなかったのでOpenCVのWebForumから、、、
http://answers.opencv.org/question/18934/errors-building-opencv-246-with-visual-studio-2013/
GitHubのpull requestでは178行目になっていますが、自分の環境では184行目を
obj.info()->addParam<FeatureDetector>(obj, "detector", obj.detector, false, 0, 0);
に変更。
これでコンパイルできるはずです。
さてさて、ソースコードを編集してコンパイルしたのでちゃんと動くかどうかテストついでに昔書いた適当なコードをコンパイルしてみることに。
エラー処理は省いてあるのでそこはご注意ください。
#include <string> #include <opencv2/opencv.hpp> #include <Windows.h> int main(int argc,char** argv) { auto&& src = cv::imread(argv[1]); if (src.empty()) { return -1; } cv::cvtColor(src, src, CV_BGR2GRAY); cv::threshold(src, src, 120, 255, CV_THRESH_BINARY); cv::namedWindow("main"); for (int i = 0; i < 360; ++i) { cv::Mat img; auto&& rot_mat = cv::getRotationMatrix2D(cv::Point(src.cols / 2, src.rows / 2), i, 1.0); cv::warpAffine(src, img, rot_mat, src.size()); cv::imshow("main", img); auto c = cv::waitKey(); switch (c) { case VK_RETURN: break; case VK_ESCAPE: return 0; default: --i; } } return 0; }