スマホ立て作った

目に入るところにスマホがあると馬鹿になるので、仕事するときは、目に入らないところに置くようにしている。具体的には、部屋の入口に箱を置いて、その中にスマホを置くことにしている。

ただ、スマホは平たいので、置くと横になる。そんな状態で鳴ると振動がうるさい。見えなくても、集中力が切れるので、これはこれで馬鹿になる。

そこで、スマホを立てることで、振動の音も大きくなく、集中も途切れないだろうと予想した。単に立てるというのは、形態上不可能なので、ホルダーを作ることにした。

自重で固定されれば良いので、シンプルな形状で良いだろうと思い、なんとなく想像した形があった。それを造形し、燃える前のプリンタで出力した。

それがこれ。

で、実際に立てた様子はこれ。

ちゃんと機能した。そして、鳴ってもうるさくない。集中力もバリバリで、若干の万能感すらあるくらい。これでちょっとはマシな研究もできるだろうと信じたい。

クソ凡ミス テキストのエンコード

 本当にクソみたいなミスで一日中コードを読み直したり、リファレンスを読んだりしたので、メモ。

何かと話題になるinverse renderingですが、実装をゼロからするのは面倒なのでだいたいは既存のツールに乗っかります。そのツールでちまたで話題なのが、Mitsuba3です。これはレンダラーで、使い方は難しくないし、チュートリアルもあるので、少しの苦労で、目的のことが達成できます。

私も、皆様と同じで楽して実験するために、チュートリアルを進めていましたが、下のリンクのチュートリアルであるRadiance Field Reconstruction (NeRF-like)で、なんか見たことのないエラーがでてきました。

https://mitsuba.readthedocs.io/en/stable/src/inverse_rendering/radiance_field_reconstruction.html

チュートリアルの読み方は、文章読んで、pyファイルにコードをコピペすれば、記された通りの挙動になるはずですが、私の環境では[6]のdef sampleの引数にあるδLでエラーが出ました。

ここに「SyntaxError: Non-UTF-8 code starting with '\x83' 」とあり、読んだ通りエンコードのエラーらしく、ん？という感じでしたが、よくわからんのでググるとUTF-8でファイルを保存すると通るらしいです。簡単なことのはずですが、Visual studioではどこで操作するのかわかりにくいです。

メニューから file -> save asで表示されるウィンドウで、Saveというボタンを押さずに、その横にある逆三角形をクリックします。すると下のような選択肢がちょろっと出てきます。そこで、Save with Encodingをクリックすると、文字コードが選べるようになります。

こんなことは、やったことないと知らないので、いたるところで文字コードの設定ができていいかなと思ったりします。文字コードの選択は下のウィンドウ内でします。ここではUTF-8と書いてあるものを選びます。

デフォルト状態では、Shift-JISだったようで、その下にあるUnicode UTF-8というのを選択するだけでした。あとは保存するだけで、目的の文字コードの選択が完了です。

実行すると、このように、Radiance Field Reconstructionができました。

これから、この辺を少し触っていこうと思います。

余談ですが、エラーが出ていた[6]のdef sampleという関数を調べてみると、下のリファレンスでは、δLではなく、δが付いていないLが引数になっていて、少しだけ混乱しました。文字コードのエラーが出たあとに、試しにLで関数のオーバーロードとかしてみました。結果、全然見当違いだったので、sampleにLなんぞ無いというエラーが出て死にました。

https://mitsuba.readthedocs.io/en/stable/src/api_reference.html#mitsuba.ad.common.ADIntegrator.sample

ま、今回で、文字コードのたぐいのエラーのでかたがわかったので、同じようにハマっている人がいたら、教えることができるようになりました。

llvmでハマる

llvmを使うことがあって、とりあえずのつもりで入れたプリビルト版のllvmの参照がうまくいかず、 むーんと思って、手元でmakeしてビルドしたら動いた。環境がそんなに違うってことないはずなんだけど、どうも相性というのがあるみたいで、面倒でも手元でビルドが確実だなと思うなど。

ちなみに、llvmというのが何かいまいちわからないまま、インストールしたのだが、それを使った今ですら、これが何なのかよくわからん。プロジェクトのページを見てもわからないし、もうこれ以上は気にしないことにした。ひとつわかったのは、ビルドに時間がかかる大きめのソフトウェアであることは間違いない。

急だったけど行って良かったとは思う

朝7時台の電車に乗って、夜7時台の電車に乗って京都を往復する旅をした。

全国からある人の関係者が集まる会があり、それに参加してきた。リアルなんだけど、リアリティが認識できないというか、なんというか。

それ自体は良い、というか、そういうものと言えるけど、別に問題があって、今日は某研究会がオンラインで開催されていて、それの運営も並列しないといけなかった。と言っても、私の役割はもうほとんど終わってるが、それでも多少やることがあって、それをぎりぎりやれていなかった。

会議を実施するうえで保険みたいなものは必要なんだなと再認識した。

Blenderのico sphereってのがなかなか良い

所用でCGを描いてて、ひさしぶりにBlenderを触ってる。

基本的に彫刻でモデリングしている。

初期形状を何にするかは結構重要。

これまで、cubeかUV sphereが良いかなと思って、使っていたが、最近はico sphereがお気に入り。

初期状態でメッシュの細かさに偏りがないので、概略形状が作りやすくて、面が足りなくなってきたら細分割すればよいので、扱いが楽。

で、彫刻でモデリングしていって、形状とマテリアルだけをあらかた設定したのが、これ。

Cycleレンダー、結構すごい。これからテクスチャを作って、気持ち良くしていく。

CGAL intersectionは汎用的に作られているため、型が分からずバグるのか

接触判定のプログラムでの問題が起こった。

CGALのintersectionで三次元の三角形の接触部分の線分をとらえようと、テストコードを組んだ。それはうまくいったので、次に本プログラムに組み込んだら、なぜか接触している三角形の判定が漏れ始めた。

すると、こんな記事を見つけた。

https://stackoverflow.com/questions/32951886/wrong-inexact-intersection-between-3d-triangles-cgal/32965564#32965564

質問者も私同様に、接触判定漏れの問題を指摘している。その回答で、do_intersectしてから、intersectionを呼ぶと、型が分からず変な挙動をするとのこと。たしかに私もdo_intersectを呼んだあとなので、挙動としては同じである。

Cartesian_converterを使えば正しい呼び出しになるとのこと。

具体的な使い方は、こちらにある。

https://doc.cgal.org/latest/Kernel_23/classCGAL_1_1Cartesian__converter.html

結果、たしかにうまくいった。

私の場合、メッシュ処理のPMP::do_intersectを呼んだあとに、三角形の型Exact_predicates_inexact_constructions_kernel::Triangle_3で接触を見ようとしていたため、この問題が起こった。

この型をコンバーターを使った例の通りに変更するだけで、問題が消えた。

二つのメッシュの接触のメモ

CGALでの二つのメッシュの接触判定と結果の取得方についてのメモ

https://stackoverflow.com/questions/22900932/cgal-meshes-intersection-collision

良記事。手元で実験済みでうまくいくことも確認した。

face_descriptorのidx()はメッシュのindexで、二つのメッシュについて、pair<face_descriptor,face_descriptor>が出力の１要素となる。

vectorで出力されるので、back_inserterを引数で忘れないように。