2018年10月26日金曜日

「Ray Tracing in One Weekend」をやってみて

最近レイトレやc++、OpenGLなどを触り始めました。
前回ではembreeを触ったのですが、今回はPeter Shirley氏のRay Tracing in One Weekendについて書いていこうかと思います。
日本語訳はここ
githubはここ
pdfをココ最近配布されたのですが、url忘れました。
*2019/3/10追記
pdfは ここ

技術的な解説は他の方がたくさんされていらっしゃって、非常にわかりやすいので、
レイトレ自体の解説は省き、環境構築、注意事項についてのお話です。

 

環境構築について

私はDebianで開発しています。
理由は以下のとおりです。
1.Linuxは開発環境としてぶっ壊しと再生が楽
2.VisualStudioが重すぎてヤダ
3.他の開発を考えるとクソ楽
の3つです。

1と3は似たような感じなのでまとめますが、私はEmacsをプログラミングをする際に使っています。また、freeglutやglfwを触ったりもしています。そして、gitを頻繁に使っています。
Windows環境下ですとソフトウェアのダウンロードがめんどくさいからです。
今回では特別なライブラリが必要ではないのですが、最低必要なエディタにコンパイラ、gitをインストールするはめになります。

2ですが、私の環境におけるEmacs、g++、gdbなどなどその他諸々を制覇した素晴らしいIDEです。ですが、その分重い。後、Windowsでしか起動できないはず。
叩いて3sくらいで開かないとやる気なくしてしまうところがあるからです。
*2019/3/10追記
ウィンドウにツリーとか表示して邪魔。
自動で{}を縮めてくれるのはいいんですけど。
コード一気にみたい。

注意事項

私自身あるあるでググったら出てくるオチ(embreeで地雷を踏む)なのですが、 Chapter8でsphere.hのclassにmaterial *mat_ptrを入れなければなりません。
後、MAXFLOATでダメならば、FLT_MAXにすると走ります。

感想

多分ほぼ初めてc++とレイトレを触ったのに近い感じの私ですが、レイトレはどのように実装されて、c++でどのように書かれているのか少しわかりました。
この一冊では球体しか出すことができませんが、レイトレの基礎を触りだけ簡単に理解できる気がします。
CGの基礎をきちんと実装も含めて書いてあるので気になるなぁというお方はエディタとコンパイラさえあればできるのでされてみるのはいかがかなぁと思います。
macOSやLinuxをお使いの方は何もせずできると言っても過言ではないくらい依存ライブラリがありません。
今現在、私は床井教授が出されているOpenGLのをしているので先になると思うのですが、この次のものもチャレンジしてみようかと思うところです。

2018年6月11日月曜日

embreeの入門に挫折

CGを観察する方向ばかりでしたのですが、開発方面のtipsとして久しぶりの投稿です。

初心者が書いているので、あまり参考にしないでください。

後述にもある通り、グラフィックプログラミング(?)は最近始めました。


2018/6/12 追記:libmmd.dllについて 
2018/9/14 追記:libmmd.dllについて

あくまでもチラチラ見て「ほぉ、そんなもんか、触るか」程度の前段階として考えてください。 embreeというのはintelが作ったOSSのCPUのレイトレです。

最近openGLやレイトレの技術の興味を持っているのでいろいろ触ったりしています。
openGLは和歌山大学、床井教授の GLUTによる「手抜き」OpenGL入門
レイトレーシングはPeter Shirley教授のRay Tracing in One Weekend (Ray Tracing Minibooks Book 1)を和訳した週末レイトレーシング
を途中までしています。
なんか途中ってなぁとは思います。やっている途中でglfwの新しいバージョンが出ましたし。
中身がどうなっているのか知りたい感じなので、写経になっているものをしています。
理論はいろいろ乗ってますけど、実際の計算はどのようにプログラムするかってあんまりわからない気がしますし。あとヘッダーの嵐で理解が危ういですし。

レイトレの基礎の基礎を知るならば週末レイトレーシングはいいと思います、a-mくらいまでは今のところ流し見では説明してくれています。
ヘッダーを書くので初心者の理解としては非常にいいと思います。
只今segment faultで投げ出している。

embreeを参考にしたサイトはembree入門です。
ですが、これをそのまま書くとだめなんですよね。
ver3に上がってAPIの刷新がされています。

私がそれに伴って書いたソースコードは

#include 
#include 
#include 
#include 
#define inf     1e30f
struct Vertex { float x, y, z; };
struct Triangle { int v0, v1, v2; };

int main(void)
{
 /* デバイスを作成 */
 RTCDevice device = rtcNewDevice(NULL);
 /* シーンを作成 */
 RTCScene scene = rtcNewScene(device);

 /* ここでこの後いろいろな処理を行う */
 /* .... */
 
 /* 3角形ジオメトリを作成 */
 RTCGeometry mesh = rtcNewGeometry(device, RTC_GEOMETRY_TYPE_TRIANGLE);
 /*頂点の設定*/
 Vertex* vertices = (Vertex*) rtcSetNewGeometryBuffer(mesh,RTC_BUFFER_TYPE_VERTEX, 0, RTC_FORMAT_FLOAT3, sizeof(Vertex), 4);
 vertices[0].x = 10; vertices[0].y = 10; vertices[0].z = 0; // 点Aの座標
 vertices[1].x = 10; vertices[1].y = -10; vertices[1].z = 0; // 点Bの座標
 vertices[2].x = -10; vertices[2].y = 10; vertices[2].z = 0; // 点Cの座標
 vertices[3].x = -10; vertices[3].y = -10; vertices[3].z = 0; // 点Dの座標
 
 /*面の設定(用意?)*/
 int tri = 0;
 Triangle* triangles = (Triangle*)rtcSetNewGeometryBuffer(mesh, RTC_BUFFER_TYPE_INDEX, 0, RTC_FORMAT_UINT3, sizeof(Triangle), 2);
 triangles[tri].v0 = 0; triangles[tri].v1 = 1; triangles[tri].v2 = 3; tri++; // 三角形ABD
 triangles[tri].v0 = 1; triangles[tri].v1 = 2; triangles[tri].v2 = 3; tri++; // 三角形BCD

 unsigned int geomID = rtcAttachGeometry(scene, mesh);


 /*ジオメトリの削除*/
 rtcReleaseGeometry(mesh);

 /* シーンへ登録 */
 rtcCommitGeometry(mesh);

 /*/*レイ交差の初期化*/
 RTCIntersectContext context;
 rtcInitIntersectContext(&context);
 RTCHit rtchit;
 rtchit.geomID = RTC_INVALID_GEOMETRY_ID;

 /* レイを生成する */
 RTCRay rtcray;
 /* レイの始点 */
 rtcray.org_x = 0.0;  // x
 rtcray.org_y = 0.0;  // y
 rtcray.org_z = 20.0; // z
 /* レイの方向 */
 rtcray.dir_x = 0.0;  // x
 rtcray.dir_y = 0.0;  // y
 rtcray.dir_z = -1.0;  // z
 /* 交差判定する範囲を指定 */
 rtcray.tnear = 0.0f;     // 範囲の始点
 rtcray.tfar = inf;  // 範囲の終点.交差判定後には交差点までの距離が格納される.
 rtcray.time = 0;

 /* 交差判定 */
 RTCRayHit ray;
 rtcIntersect1(scene, &context, &ray);
 if (rtchit.geomID == RTC_INVALID_GEOMETRY_ID)
 {
  /* 交差点が見つからなかった場合 */
  std::cout << "Reject." << std::endl;
 }
 else
 {
  /* 交差点が見つかった場合 */
   std::cout << "Intersect" << std::endl;
  
 }
 
 /* シーンを削除 */
 rtcReleaseScene(scene);
 /* デバイスを削除 */
 rtcReleaseDevice(device);
 system("pause");
 return 0;
}
}
です。 

 躓いているのが、「レイと三角形との交差判定」なんですよね。
 RTCHitで判定すると思うのですが、初期化したデータがそのまま受け継がれているんですよね。


 プログラムの解説なのですが、
引用元の最初に当たる、初期化と終了処理は


#include 
#include 
#include 

int main(void)
{
 /* デバイスを作成 */
 RTCDevice device = rtcNewDevice(NULL);
 /* シーンを作成 */
 RTCScene scene = rtcNewScene(device);

 /* シーンを削除 */
 rtcReleaseScene(scene);
 /* デバイスを削除 */
 rtcReleaseDevice(device);
 return 0;
}
 
シーンの作成にあたり、embree2と違って、deviceの選択のみです。
embree3では他はシーンの品質の左右のみのようです。


次に三角形の作成なのですが、tutorialsのtrianglesをパクり参考にしましたので、構造体になっています。
ジオメトリの名前をmeshにしているのはgeomIDとRAYHitのgeomIDで使いたかったからです。



struct Vertex { float x, y, z; };
struct Triangle { int v0, v1, v2; };

 /* 3角形ジオメトリを作成 */
 RTCGeometry mesh = rtcNewGeometry(device, RTC_GEOMETRY_TYPE_TRIANGLE);
 /*頂点の設定*/
 Vertex* vertices = (Vertex*) rtcSetNewGeometryBuffer(mesh,RTC_BUFFER_TYPE_VERTEX, 0, RTC_FORMAT_FLOAT3, sizeof(Vertex), 4);
 vertices[0].x = 10; vertices[0].y = 10; vertices[0].z = 0; // 点Aの座標
 vertices[1].x = 10; vertices[1].y = -10; vertices[1].z = 0; // 点Bの座標
 vertices[2].x = -10; vertices[2].y = 10; vertices[2].z = 0; // 点Cの座標
 vertices[3].x = -10; vertices[3].y = -10; vertices[3].z = 0; // 点Dの座標
 
 /*面の設定(用意?)*/
 int tri = 0;
 Triangle* triangles = (Triangle*)rtcSetNewGeometryBuffer(mesh, RTC_BUFFER_TYPE_INDEX, 0, RTC_FORMAT_UINT3, sizeof(Triangle), 2);
 triangles[tri].v0 = 0; triangles[tri].v1 = 1; triangles[tri].v2 = 3; tri++; // 三角形ABD
 triangles[tri].v0 = 1; triangles[tri].v1 = 2; triangles[tri].v2 = 3; tri++; // 三角形BCD

 unsigned int geomID = rtcAttachGeometry(scene, mesh);


 /*ジオメトリの削除*/
 rtcReleaseGeometry(mesh);

 /* シーンへ登録 */
 rtcCommitGeometry(mesh);

ジオメトリの作成にあたって、引数でジオメトリのタイプを設定し、
ジオメトリに対して、頂点や面の数、場所を書き込んでいます。


レイの送受なのですが、
embree3ではembree2のRTCRayの役割がRTCrayとRTCHitに変わっています。
私はここのRTCHitの扱いがわかりませんでした。


    /*レイ交差の初期化*/
 RTCIntersectContext context;
 rtcInitIntersectContext(&context);
 RTCHit rtchit;
 rtchit.geomID = RTC_INVALID_GEOMETRY_ID;

 /* レイを生成する */
 RTCRay rtcray;
 /* レイの始点 */
 rtcray.org_x = 0.0;  // x
 rtcray.org_y = 0.0;  // y
 rtcray.org_z = 20.0; // z
 /* レイの方向 */
 rtcray.dir_x = 0.0;  // x
 rtcray.dir_y = 0.0;  // y
 rtcray.dir_z = -1.0;  // z
 /* 交差判定する範囲を指定 */
 rtcray.tnear = 0.0f;     // 範囲の始点
 rtcray.tfar = inf;  // 範囲の終点.交差判定後には交差点までの距離が格納される.
 rtcray.time = 0;

レイの生成に関しては全く変わっていないです。
RTCHitを後述のifなどで使うにあたり、初期化しなくてはならないのですが、何をどうしているのかいろいろ見てもさっぱりでした。


コピペです。交差判定は説明書を見て書き換えた形です。

 /* 交差判定 */
 RTCRayHit ray;
 rtcIntersect1(scene, &context, &ray);
 if (rtchit.geomID == RTC_INVALID_GEOMETRY_ID)
 {
  /* 交差点が見つからなかった場合 */
  std::cout << "Reject." << std::endl;
 }
 else
 {
  /* 交差点が見つかった場合 */
   std::cout << "Intersect" << std::endl;
  

上記のプログラムを実行した場合、普通にRejectと出ますが、
レイの交差初期化で
 rtchit.geomID = geomID;
とした場合、Intersectと出ます。

わからないなりに適当に書いてしまった缶はありますが、embree3を触ろうかなぁと思っている方の気持ちを押すだけの手助けになれば幸いです。
技術的な視点はないので、気になった方は各自でググってください。もうギブ。

それにしても、意外と奈良先端技術大学院大学って近いんですね、クソ遠いかと思っていたのですが、そうでもなかったです。

参考
embree入門
embree公式
説明書


追記:libmmd.dllがないためエラーが出る場合
私の環境ではでました。
検索すると、c4dの例が多いみたいです。
検索した結果ではMSのVS再配布パッケージをインストールすれば解消することが多いようですが、ダメな場合は、intelのc++再配布パッケージをダウンロードすると解消すると思います。
嫌ならば、Embree Example Rendererからlibmmd.dllだけ取り込んでぶっこむのもありかもしれません、保証はしません、ご了承ください。 

コメント欄にてうしおさんがlibmmd.dllについて述べられています。
ありがとうございます。
3.10 3.21alphaなどを使うと良いそうです。

githubの存在をすっかり忘れてました...どこからdlするのかって話になりますね...。

2018年6月8日金曜日

VR Zoneにて


前に似たような記事では、今はなきジョイポリスでSIMVRの「BLASTxBLAST」(その時の記事)で体験しました。





今回はVR Zone Umedaで「アーガイルシフト」というVRシネマティックアトラクションを体験しました。


内容はVRを用いた体感型映画みたいな感じですね。
何かしら敵機体破壊の操作方法が言われますが、まぁそういうアクションはあって意味がないような感じですね。

ロボットのコックピットに乗って、隣に可愛いアシスタントがいて、 動きを感じながら空中を速く爽快に進んでいくっていうのは、まぁ~すごい、良い、好き、かっこいい、ロマンです。

ガンダムの戦場の絆とか体験したことがない(ガンダム勢怖い)ですので、比較はできませんが、xに240度位、yに140度位でUIが浮かんでいて、足があるっていうのが臨場感ありまくりでした。

ただ、7mで1000円は高く、コンテンツ自体面白くて短く感じてしまうのは難点ですね。
また、トロッコ式でほぼなにもしないので、何度も体験したくなる感じは低いですねぇ...。
 
個人的には2000円30mで箱庭を自由に闊歩して、ジョイスティックで移動と照準を合わした攻撃で基地制圧とかがあって、スコアアタックなると数回はプレイすると思いました。
BLASTxBLASTの操作のViveコントローラーは流石にパスで、重くて死ぬ。
作るの死ぬほど面倒そうです、デバックとかヤバそう。

やはり、前のSIMVRと同じでかなりViveの画像の粗さ、網目状のやつが気になりますね...。
これはHMDの使用で仕方がないので、Vive Proか世代交代の時期に期待ですかね。

VR Osakaができれば、ユーザーの自由度が高い
マリオカート アーケードグランプリVR
VR-ATシミュレーター 装甲騎兵ボトムズ バトリング野郎
をやってみたいですね、マリカ以外全く原作知りませんが。

百聞は一見にしかずですので、機会があれば触ってみると価値観は変わりますね。
上でなんだかんだ言っておきながらすごく楽しかったですw 
続きプレイしたいですわ...Steamで...。

2018年5月12日土曜日

映画「READY PLAYER ONE」を「一人の開発者」として見た感想

先程、MX4DでREADY PLAYER ONEを見てきました。
3100円って普通の映画の倍近くなので高いですね。
交通費などコミコミすると約4700円普段の3倍ほどですw
そういう装置なので納得ですが、デップー2は普通に字幕で行きます()

そうとはいえ、あれはすごい迫力でした、そういう感想はgoogle+で。

開発者(?)、どっちかというと今の立場は研究者に近いかもしれないですが。
それを踏まえて、
1.xRに関する未来について
2.このxRを実現するための描画構築について
3.この映画のCGについて
書いていこうかと思います。


1.xRに関する未来について

このREADY PLAYER ONEはゲームとして、xRの未来として書かれているなぁと思いました。
今のゲームでは、おおよそが個々のゲームが個々のネットワークサーバでおおよそ個々のアバターを使っており、 その枠の中でのプレイとなります。SIEならPS系のみ、MSはXBOXのみ、VIVEコンテンツはVIVEのみって感じで。
ですが、この映画のゲームプラットフォーム、OASISという一つの中で色んなゲームがあり、目的は自由、全てでアバターを使いませせる。しかも、会社を問わずして(カプコン制作、ストリートファイターの春麗、blizzard制作OverWacthのトレーサーなど)、キャラクターが集まる。
そんな何でもありな世界を構築するのかと思います。
VR機材やPCの都合上VR Chatを入れていないですが、今まさにVR Chatがそういう世界なのかなぁと思います、版権的に不味いやつもありますが。
個人的には角川とニコニコがVR Chat系に力を入れているので、角川が自社保有コンテンツのキャラを売るなんて世界が来るのは案外早いのではないかなぁと思います。

ゲームとしては「READY PLAYER ONE」だけに各々がPALYER 1であり、誰かのPLAYER 2であるように思いました。MMORPGなんかそうですけども。
デベロッパーとして、開発に苦難しながらも生み出して、ゲームを作ったことに誇りを持っており、開発者であることに誇りを持ち、組み込むこと、最後のイースターエッグでの開発者としての亡霊はすごく思いというものが伝わりました。

xRの機材に関しては現実味がありすぎてなぁと思います。
これは機材さえ整えれば今にでも起こりそうな気がします。
性能の良いPCが必須で、5万は超えるHMDも必須で、歩行器とかボディグローブとかその他諸々で、この映画が描いたであろう「VRの民主化」には現時点では遠い気がしますが。
個人的にはソードアートオンラインとかOverLordとかその他諸々みたいに実際に体を動かさないものが来るべきであろうと思いますが、ソファーに上がって乱闘は流石にまずいです。
これに関しては人間の五感を司る神経をどう扱うかですね。

そして、リアルとバーチャルの境ですね。
映画に登場する人々はバーチャルに多くのものを持ち込んでいる。
それだけではダメだと最後の方で主人公は述べます。
私もそれはそう思います。
楽園追放のDEVAの住人と違い、我々はまだ肉体を持っている。
だからこそ、肉体を持つものとしてのリアル、理不尽さと便利さ、楽しみを知っておくべきだと思います。

2.このxRを実現するための描画構築について

もしもこういうものを実現するとなれば、描画処理が非常に厳しいと思いました。
まず、数多のアバターセットがある上に、ユーザーが作り出すことができる。
これはポリゴンモデルは自由なことにシェーダー、テクスチャ諸々自由です。
しかも、それがネットワーク越しに毎度やってくる。
これはかなりのネットワークの帯域が必要であること以外にも、 それを格納する容量をどうするかというのも大事です。
また、描画が自由だからこそ機器ごとの最適化はどうするか、大量のモデル描画が発生した際に基準は距離かモデルの負荷ごとか、処理はLODをかけるかそれとも削除するか、そもそもに最低品質のアバターで構成するか色々問題があると思います。
また、モデル破壊にかかるシーンなどのVFXはサーバで処理したものを画像で送るか、それともP2Pでレンダリングし必要な部分のみ画像を受け取るか、そもそもにすべてレンダリングするか色々あると思います。
そして、GIなどはシーンが決めるのかどうかですね。
結構この映画ではリアル系だけでしたので、モデルの制限がありそうです。
あの人が好きそうなモデルは化物になりそうです。
ゲーム単発というよりもエンジン拡張とDCCを組み込んだプラットフォームって感じですね。

3.この映画のCGについて

本音を言うとゲームらしさを出すためかしてリアルでもなく、セルシェーディングでもない、微妙な質感です。
ゲームだからこそゲームらしさが大事なのかも知れないです。
ですが、やはり大勢のモデルが描画されるシーンはすごかったですし、キャラクターの動きがゲームらしさと人間そのものの動きの中間を取っている感じで雰囲気としては非常に良いですね。
ドローンなどの合成はきっちりとしたCGでした。
こういうのが見る側の意識の違いを生ませるのかも知れないです。

以上が私が見て思った技術的な方面で思ったことでした。



個人的に関係ないことを言うと、1980年代の内容が多い気がしました()
ブレードランナーとかバック・トゥ・ザ・フューチャーなどを見て思うのですが、 あの時代の急成長な未来を描いた映画とかアニメとか結構出ていましたね。
アタリとかぶっちゃけ私の周りでは普通は知らないです。
私にとって、E.T.がボロクソに捨てられたこと、はじめてイースターエッグとして、ゲームに開発者の名前をこっそり初めて入れたこと、怒れるゲーマーがキレてることくらいなイメージです。

2018年3月1日木曜日

PINE64を買ってから時間がたちました...。

今回もCG関係ではありません。 

面白いもの見つけたので、それについてこんど書くかもしれません。

PINE64 1GBを買って1ヶ月ほどたちました、購入した際の記事はこちらです。
買ってしばらくして当初の目的であったブラウジングには厳しいなという感想です。
ちょっと放っていましたが、自宅NASに使っているRaspberry Pi2ではちょっと力不足に思うようなことをしたいと思い、また触り始めました^^;
私自身あまりLINEに信用をおいていないんですよね、Zenfone2の変態機能を用いてLINEだけ別にしています、SUMSUNGとかHYUNDAIとかNAVERとかこれはなぁと思うもんです。
爆破、破壊、漏洩、いろいろあるもんですし。

そうとはいっても、一応携帯通信大手三社がライバル視するほど普及していますし、ヤラなければ余計に面倒なんですよね、リスクヘッジとか気にしている人は多分いないです。
そんなこんなで、サンドボックス環境で利用できるようにDockerを導入しようという流れです。環境ぶっ飛びましたが。

システムをPINE64で構成するにあたってどのOSが良いかというと「Arch Linux」です。
個人的な見解として、なんかArchが良いだのBSDだの言われますが、普通のPCとしてLinuxを運用するのであればDebian、Ubuntu、LinuxMint、CentOSが良いと思います。
なぜならばほとんどのLinux系ソフトウェアはパッケージ管理システムを用いますが、個別のパッケージで配布する場合はDebian系のdebとRHEL系のrpmをで配布しているところが多いです。
確かにぐぐれば出ますよね大概
また、オープンなネットにつながっているLinuxの6割以上はDebian系らしいですし。

ですが、今回の環境ではメリットになりません。
それは殆どの部分でarm64v8だとかaarch64だとかarmhfとかにPINE64は当たるため上記に述べたパッケージが利用できません。
そして、Debianではなぜか独自のリポリトジを保持したがるクソ
このせいでapt updateもupgradeも死ぬほど遅いです、クソ。
近いサーバから落とすように設定しても不具合が何故か出ました、さむわん てるみー ざ りーずん。
それに対し、Archは特定のサーバではなく、近くのサーバから落とすような思想かしてDebianよりかは速いです、そのような思想でなくても5hはかからないので圧倒的にこちらが良いです。
また、まともにLinuxとして動く中でX11も日本語入力もなにも問題が少なく動くのがArchというのもあります、開発者に優しいってのを感じます。

結論として

PINE64でLinuxの小さなコンピュータとして用いる日本語入力とX11を求める人はArchが良い! 

でした。

2018年1月28日日曜日

PINE64を買いまして。


まずはじめに、

今回はCG関係ありません。

ググってここに来たら、だいたい購入希望か困ったときの対処かと思います。

悩んだら 参考にしていただけると嬉しいですが、アドバイスは出来ません。

購入は こちら

購入を考えている方

・Android Stickなどで十分かどうか。
・目的が本当にそれで良いのか。(Raspberry PiやTinkerBoardなど他にもあります。)
・十分にトライできる根性と知識があるのか。
がこれを購入するにあたってどのマシンにするかの鍵ではないかと思います。

私の用途

・メインやサブが処理ぎりぎりになった場合のネットブラウザマシン
・環境をぶっつぶせる環境勉強用のマシンとして


結論から言うと「Arch Linux Debian ArchLinux入れるわ」です。(2018/1/28 31 2/28現在) 

何故かと言うと、ネットをするにあたって色々当たりましたが、オチがこれです。。
何故にそんなOSを選んだのかというと、勉強のためと普通にどれくらいできるのか知りたかったからです、めちゃくちゃ勉強になった気がしました()

外見は


という感じで約縦14cm、横7cmとミンティアサイズにまで押し込められたRaspberry Piと比べると少々大きいです。

スペックはARM Cortex-A53、Mali 400、DDR3、GbitEth、Raspberry Pi互換のGPIOピン(公式:PINE64.org)です。

んで、お値段は
PINE64 1GB本体 ¥2980
5V3A microUSB出力アダプター ¥700
microSDカード 16GB ¥1150
ワイヤレスキーボード&マウス ¥1822
Wifiアダプター (家にあった旧世代) ¥0
送料 ¥500
計 ¥7152でした。

なので、購入する用途が

・自宅へのVPNやSamba、CUPS、NginXなどを用いた常時起動でありつつも低パフォーマンスでもよいサーバ
・Linuxの練習機
・IoTのなんか(詳しくない)
・子供向けのマシン
・安くでTVに繋げれるマシン
といった点かと思います。
ですが、扱いが難しいので、本当の初心者はRaspberry Piの方がいいです。

ロボットなどの組み込みにおけるPINE64は

・ボード自体の大きさの問題
・積んでいるGPUが 画像処理に適していない問題
・wifiなどの無線規格が違法または合法のものは搭載すると大きくなる可能性がある問題
があるため普通にRaspberryPiを買うことをおすすめします。
コスパで画像処理以外の性能がほしいのであればありかもしれません。
ですが、基本aarch64というほぼサポートされていないCPUということをお忘れなく。

それ以外で

・本当に最低限で良くて、sshからでいいし、パワーそんなにいらない場合はNanoPi
・パワーが欲しいし、USB3.0ホストも欲しい、多少の不便は眼をつぶる場合はRock64
・安いx86_64の場合はLattepanda
かと思います。

私がこれについて困った点

まず、何故かddコマンドで出来ないという点です。
Debian Stretchという私の環境だけかもしれませんが 、ddもアクセサリにあるDiskからも出来ませんでした。
諦めて公式らしい焼くツール使いました→PINE64 Installer

そして、OpenSUSEを焼きました。
CLIから始まりました、GUIを入れようと画策します。
ググって「zypper in patterns-xfce」とか入れようとします。
ダメでした。
何度もググりまして、「pine64_config.sh」 で入れれることがわかりました。
「Problem occured during or after installation or removal of packages:
 Installation aborted by user.」って出ました。
これは「同じ名前のものがあるけど良いの~?」って聞いて自動でインストしている為勝手にNoと言ってキャンセルされるからです。
取り敢えず、viとかemacsとかでshの中身見て、必要なコマンドだけ持ってくる。
これで全部yesって答えて、ちゃんとコマンドが打てていればreboot後、GUIが出ます。

その後、wifiの有効化を図ろうとしましたが、デバイスマネージャーはないですし、ネットブラウザはない。おまけになんかzypperのGUIツールが動かない。

諦めました☆

ArchLinuxを焼きました、OpenSUSEが嘘かと思うほど全部そこそこすんなり行きました、GUIもwifiも 。
ですが、Firefoxを開くだけでも非常に固まる雰囲気がしましたし、タブちょっと開くだけですぐ1GBのRAMを使ってしまいました。
軽いoperaもaach64なのでダメでした。
また、ソフトウェアのインストールにあたってpacmanでインストールできるものとAURでインストールするものに分かれます。
そして、AURでインストールする場合はrootユーザではダメです。
普通はrootでしますからね、コメント読んでませんでした。



ここで諦めのDebianさんを使います。
使用してみるとあまり変わらない気がしました。RAMもCPUも全く使っていないのですが、フリーズする感じでした。
あまりうまく日本語環境が整っていないことを考えるとArchのほうが安定性があるように思います。
システムの容量を増やしたり、セキュリティを高めたりするためにwikiに書いてあるコマンドを忘れずに。

続いて、Androidも試しました。
起動の遅さとwifiアダプタのドライバがない(ググるとBeagleBoardで試した方のブログがありました、コンパイルすると行けるっぽいです)こと、物理ボタンとターミナルの都合によりシャットダウンが出来ないことにより断念。
以前x86_64マシンや仮想マシンでも試したことがあるのですが、 起動の遅さは全部同じです、スマフォのような常時起動をメインにしているためと考えます。

同じAndroid系列であるものの開発が終了しているRemixOSも試しました。
起動は遅くなく、シャットダウンがきちんと出来、Androidと違い、操作性は非常に良いです。
ですが、wifiが同じように対応していませんでした。
同じ使用目的で対応しているネットワークを使用するのであればありかと思います。
サポートはありませんが。

どうにでもなれとRaspberryPi向けのOSを焼こうかと思ったりしています。
Raspberry Pi3とはGPUの差以外は見受けにくいかと思います。

最後に

今回は制約上あまり良い印象ではありませんでしたが、どのOSも性能のあるマシンだと色々出来ますので、ありだと思います。
また、お遊びであったり組み込みであったりするとデバイスの仕様上、色々良いことが多いかと思います。
そして、今回は目的と合わなかったために使用しなかったOSがありますが、目的を考えるとx84_64では多分見かけないOSがあります。
FalconGateとか何それと思いましたが、 サイバーセキュリティ向けのOSでハッカーやマルウェアからデバイスを保護するものなんてありました。
1万円以下で構築できるコンピュータなので、興味があればお財布に手を突っ込んでみてはいかがかと思います。