_projective plugings are available in mitsuba3.5 instead of _reparam plugins

I wrote my problem about _reparam plugins in Mitsuba3 here two days ago. 

https://geblog3.blogspot.com/2024/02/mitsuba3-removed-reparameterizations.html

After that, I realized that I had read the stable version tutorial but installed the latest version of the library. The difference confused me. 

While _reparam is still available in the stable library whose version is 3.4.1, new plugins were introduced in the latest version 3.5.0 instead of _reparam. Those were projective plugins. In addition, the latest tutorial already described it. 

https://mitsuba.readthedocs.io/en/latest/src/inverse_rendering/projective_sampling_integrators.html

Thanks to this tutorial, I solved my problem. The plugins adjust shapes to the desired ones. 

mitsuba3 removed reparameterizations

I wrote a program for retargeting shapes using a reparameterization plugin in Mitsuba3, but the program did not work. I only knew that a line using the reparameterization plugin had stopped the program, but I did not understand what the problem was because the program was written along with the official tutorial. 

At first, I had not wondered if the official tutorial was old. But a day later, I wondered again it was real. Later, I found a page. The official tutorial was old.  

https://github.com/mitsuba-renderer/mitsuba3/pull/997

According to this, "Reparameterizations were completely removed from the codebase." OK, goodbye. 

Now, I have to reconsider what I use for retargeting shapes. 

----------------

The problem was solved with _projective plugins. https://geblog3.blogspot.com/2024/02/projective-plugings-are-available-in.html

libtorchでis_avaiable()がFalseを返すのを直したときのこと

Windowsで機械学習で有名なpytorchのc++ apiであるlibtorchを使い始めたが、たびたび？？？となることにぶつかる。

直近で当たったのが、ライブラリのバージョンやドライバーなどちゃんと整えたうえで、CUDAの利用が可否か問う関数、

torch::cuda::is_available()

で、0,falseが返ってきて、なぜか使えないと判定されたことである。

念のために、pythonで、

import torch

torch.cuda.is_avaiable()

を投げると、Trueで返ってくる。

つまり、torch的にも計算機の環境としてはCUDAが整っているのに、Libtorchを通した時におかしいという状態である。

考えてみると、これはDLLが別のものを指している可能性があって、Libtorchのフォルダ内のdllを先に参照できていないことが示唆される。

ということで、システム環境変数のPathを見てみると、libtorch/libが通っていないので、先頭に追加した。

結果、ちゃんと1, Trueが返ってきて、かつ、

device_type = torch::kCUDA;

torch::Device device(device_type);

model->to(device);

cout << "Is module CUDA? " << model->parameters()[0].is_cuda() << endl;

によって、GPUへの転送もうまくいっていることを確認できた。

PCAのコード

 毎回書き直すので、基本的なPCAを計算するコードを載せておこう。前も載せた気がするけど、ま、いいや。

c++でライブラリにEigenを使っている。

実験として、2次元10個のデータのmatのPCAを計算する。

とりあえず、ランダムのデータにする。

Eigen::MatrixXd mat(10, 2);

for (int i = 0; i < mat.rows(); i++) {

for (int k = 0; k < mat.cols(); k++) {

mat(i, k) = (double)(rand() % 100) / 10. + 50.*(double)k;

}

}

本編は以下で、PCAを使って2次元を1次元にプロジェクションする。

Eigen::MatrixXd aligned = mat.rowwise() - mat.colwise().mean();

Eigen::JacobiSVD<Eigen::MatrixXd> svd(aligned, Eigen::ComputeThinV);

Eigen::MatrixXd W = svd.matrixV().leftCols(1);

//これが主成分方向の内積の集合のベクトル

Eigen::MatrixXd dot_on_plane = aligned * W;

Eigen::MatrixXd projected_one = dot_on_plane * W.transpose();

Eigen::MatrixXd projected = projected_one.rowwise() + mat.colwise().mean();

スマホ立て作った

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

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

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

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

それがこれ。

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

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

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

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

何かと話題になる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を引数で忘れないように。

CGALで形状の近似が実装されてたというメモ

 https://doc.cgal.org/latest/Surface_mesh_approximation/index.html#Chapter_Triangulated_Surface_Mesh_Approximation

figure 74.10が結構理想的

DTP操作のために、プログラム組んでたら、単位でハマった

ファブリケーションの研究しているとどうしてもフォーマット関係でハマります。

今回はDTPで扱うような、ベクター形式の画像の単位でハマりました。プログラムで印刷前提に、ベクター形式を出力しようというモチベーション自体があまりないので、情報も少なく、意図を手繰るような感じで、実験してわかったことをメモっていきます。

ここでの目標はベクター形式の画像をラスター画像と同じソフトで扱いたいというものです。

ベクター形式で画像を出力すること自体は実は簡単でした。svgというフォーマットを使えば、テキスト出力だけで、画像が出せます。文だけ読むと意味わからないのだけれど、テキストデータが、解釈されて、ベクター形式の画像として扱えるフォーマットがsvgです。ルールについては、ほかのページに任せるとして、fstreamなどのファイル出力で実現可能なのは確認済みです。ストリームで出力するとき、数値はダブルクォーテーションを入れる必要があるのですが、このとき\"として、ダブルクォーテーションを出力することだけ覚えておけばOKです。

出力された画像の長さの単位が、イラストレーターとかで開くと、ポイントという単位として扱われます。このポイントという単位は、フォントとかでしか見ないので、具体的に何ミリメートルかなんて考えることがありませんが、私はラスター画像と一緒に使いたいので、単位の換算を知る必要があります。ラスター画像の単位はmmやinchで指定はできますが、基本的には、dpiかppiを使います。dpiはdots per inch でppiはpixels per inchです。dotsはインクの粒で、pixelsは画像の粒であるピクセルです。ラスター画像では、ピクセルで色を指定するので出力を考えるとppiを単位とすることが多いです。例えば、ppiで300と指定すると、1inch=25.4mmに、300個のピクセルを並べるという、ことになります。このppiに、ベクター形式内の1という単位を無理やり合わせるにはどうしたら良いかを考えます。

ベクター形式での1という単位は、先に述べたようにポイントとなります。ポイントとインチの換算は決まっていて、1inchの中に72ポイント並べられます。1inchの換算の比率さえ合えば、単位を調整できるので、ppiのほうに無理矢理ベクター形式の1をあわせるなら、xをppiの数値とすると、72/xを係数として、ベクターの数値に掛けてやればOKとなります。具体的には、300ppiの画像に合わせるためには、ベクター形式の1を72/300かけたものでぴったり解像度が合うようになります。

具体例を挙げると、svg形式で、1ピクセル分を1×1の正方形で表現すると、300dpiの1ピクセルと合わせるには、72/300×72/300の正方形とすると、ぴったりあうということです。

終わり

はじめてmitsuba 2使ってみたことを記事にしてみたけど

とある投稿に向けて、私の手法との比較画像を作る過程で、いやー最適化してーなぁ、と思ったのだけど、ほぼ手付かずで、そのまま数週間たって、某上司から「アドベントカレンダーって企画しってる？」と聞かれて、知らなかったけど、イキり負けしたくなかったので、「んー、聞いたことあるかなぁ」とか言ってたら、話が進んで、冒頭の最適化の記事を書くことが決まってしまいました。

どうやらアドベントカレンダーってのは、もとは25日までの日めくりカレンダーだったのだけど、qiitaという謎サイトが技術屋が12月1日から25日まで、毎日更新の記事を書くイベントに仕立てたらしく、上の会話のアドベントカレンダーは、元の意味のアドベントカレンダーではなかったということです。

どうせなら、今やらなきゃいけないことを書こうと思い、Mitsuba 2という神を使うことを書いてみました。

で、できたページがこれ。

https://qiita.com/dw_sakurai/items/08888526d70672a2c402

本当はボリュームレンダリングまで書くつもりでしたが、書くのがだるいし、時間もゆとりがあるわけではないので、途中でやめました。無理。

それでも、多少、読む人がいるかな、と思っていたら全然人気がないらしく、なんじゃい、という感じです。

まぁ、よくよく考えたらMitsuba 2に興味ある人は英語読めるし、コードも読めるし、なんでもできるので、こんなページに興味持つわけないな、と気づいて、「あっちゃぁ、やっちまったなぁ」という気分です。

CGAL5.1でボロノイ図の頂点を参照する関数

Delaunay_triangulation_3をTriangulationとし、入力点群pを母点として、それらに対応したボロノイ領域の頂点を返すコードのメモ。

incident_cellsではなく、finite_incident_cellsでトラバースしないと、仮想のボロノイ領域まで参照してしまい、思い通りにならない。

vector<vector<Point>> compute_voronoi(vector<Point> p) {

vector<vector<Point>> vor;

Triangulation T;

vector<Vertex_handle> vh;

for (int i = 0; i < p.size();i++) {

vh.push_back(T.insert(p[i]));

}

for (int i = 0; i < p.size(); i++) {

vector<Cell_handle> cells;

//T.incident_cells(vh[i], back_inserter(cells));

T.finite_incident_cells(vh[i], back_inserter(cells));

vector<Point> cell;

for (auto& cit = cells.begin(); cit != cells.end(); cit++) {

auto VP = T.dual(*cit);

cell.push_back(VP);

}

vor.push_back(cell);

}

return vor;

}

The solution is DYNAMICBASE:NO

I usually make a program from a project template of Visual Studio 2019.
I used a geometry processing library, Libigl, to make surface from implicit functions because I had used the library earlier.
All examples of the default tutorial had no problem, but some problems occurred when I execute problems I made from the project template of Visual Studio.

Unfortunately, one was the example of parameterization to make extract surfaces on UV coordinate, which I wanted to use. 

An access violation occurred about libopenblas.dll when it ran on the release mode build, while there was no error on the debug mode build.

That was an unfamiliar action of the program, and there were very few articles about this issue on the web. 

So, I checked flags of the project file, and I tried to edit them. At the time, I had understood the problem occurred around memory management, and then I focused on it.  Also, differences between both the modes point the problem location out because the debug mode did not hold this problem but the release mode did. 

From them, I found a point to repair the program. The linker option has a "base address randomization" flag. Then that was yes, this program occurred. So, the easiest solution was to change the flag to no (DYNAMICBASE:NO). 

VRST2018 最終日ほとんど参加せず

この日は、体調不良のため、一瞬だけ会場に行って、すぐに帰りました。

ハオリーの講演は9時からにも関わらず、かなりの人が聴講したとのこと。さすが。

10時から11時ごろまで会場の賞の準備を行いましたが、体から非正規ルートで水分が出るので、久保さんに仕事を引き継ぎ撤収しました。

帰り水分がないはずなのに、蕎麦屋のてんぷらのにおいが半端じゃなく不快で出そうでした。

家で風呂につかり、水飲んでは吐きを4時間ほど繰り返したあたりで、吐き気がおさまり、普通に水が飲めるようになりました。
なぜか全身が痛いです。

あとからチェアコミュニティの共有ログを見ると、VRSTは無事終わったとのことでした。非常に素晴らしい会だったと思います。

VRST2018 三日目

明日に控える表彰の準備を3時ごろまですることになり、チェアとして担当の企業セッション前にぎりぎり会場に到着しました。

某社がよく作られたプレゼンをした一方で、ぐだぐだのプレゼンをしたため、中にいる人の力の差、努力の差が露呈するかたちになりました。ぐだぐだのほうは、時間を過ぎていたので、止めましたが、もっと早くに止めれたかなぁ、と反省しました。ただ、終わるタイミングが見えないので、止めるのに躊躇しました。ま、と言っても、悪いレフリーではなかったと思います。

今日はバンケットでした。仕事が降ってきたので、あまり飲めませんでしたが、楽しい時間でした。

VRST2018 二日目

この日も後から更新をします。

急遽、9時からのオープニングで話すことになり、一瞬登壇。数時間前に言われて登壇するのは人生初で、結構クルものがありました。

その後、FFの担当でもあるため、発表者の確認と進行のために各ブースを回りました。
そんで、急にやめるとかやめてほしい（苦笑）。

FFの時間。
またチェアで登壇。
あまり接続のチェックなどはできずに登壇した人もいるので、何かトラブルかなとは思っていましたが、案の定、一時ストップがありました。
毎回、なんかありますね。
そして、自分の説明もあるのに、チェアってどういう状況？
という感じでFFを無事終了。
この時点でだいぶセッションが押してきました。

夕方あたりの企業セッションでまたチェアなので、それまで自分のブースでもろもろを準備しました。
そのとき、某Mの千葉さんがふらっときて挨拶なり、お話なりをしました。あの人めっちゃいい人です。自分も某Mに行きたい。

休憩するのも一苦労という会議が多いですが、この会議はその辺をちゃんと抑えてて素晴らしい。コーヒーの部屋がかなり充実してて、いい感じです。

時間になって、企業セッションの準備に向かったのですが、時間が押してて、まだ前のセッションでした。
少しの休憩のあと、段取り決めて、企業セッション。結構どこも引き付けるプレゼンだったので、かっこいいなと素直に思いました。
企業ってすごい。

そのセッションが終わって、ポスター会場に。
光る発表が何個あって、すごいなという感じです。
デモも面白かったです。

8時ちょっと前にセッションが終わり、流れて解散になり、その日の会議は終了。
遅くはなってますが、大きな事故がなく、よかったです。

そのあとはちょっと懇親会に参加して撤収しました。

帰ったのは12時。遅すぎ。

VRST2018初日

国際会議VRST2018に、運営として参加しています。
超大変。

時間がないので、短く書きます。後で思い出せるところは埋めていきます。

午後3時に早稲田大学国際会議場に到着しました。そのあと、自社ブースに入って、某M井さんにもろもろ説明しました。が、実はこの説明は不要でした。
佐藤さんがだいたい教えてたらしい。さすが段取りの鬼　佐藤氏。彼にすべて任せておけばオールオーケーでした。

準備ほどほどに、3時半ごろ用事で外に出ました。
するとモルモン教を広めているという若いアメリカ人につかまりました。志が高いので、一頻り感動した旨を教えて、用事があるということで離れました。彼ら、熱心ですごいね。

そうそう、外に出るときに、河合さんに会いました。3年ぶりだけど全然変わってなかったです。

会場にもどり、4時半からバンナムのVR Zoneについての講演を聴きました。超おもしろい内容でした。
そして通訳の人すごいと思って、憧れました。来年あれやりたい。

その後、レセプション会場兼VR体験会場のVR Zoneに行って、もろもろの整理の仕事をしました。
その後、体験。

リアルサーキットの鬼のVR体験

つられている某久保さん

入口

自分の体験しているのは自分ではとれないのであれですが、こんな感じです。

その後、撤収。9時に出たのに、家に着いたのは11時。ほんと遠い。
ほとんど食わず飲まずだったのでただただつらい。

そして、なぜか明日の仕事をいろいろ振られるという。すごい人気者なんだな、自分。どこでも。と自分を慰める。

台湾4日目

7月1日。
この日は台湾から出て、次の場所に移動する日です。

昨夜は3時ごろまで飲んでいて、6時ごろに起床。
昨夜、I橋君と話して、何度も考えたけど、地元でそこそこで生きていこうという学生が、研究する気になるわけない。だから、I橋君が学生を研究者に育てようとするのは、時間の無駄だと思う。やめちまえ。

10時半ごろに、台南駅。

ここでジャーナカさんとお別れ。ありがとうございました。
ほんと、ジャーナカさん超人だなぁと思いました。
苦労の割に得るものが少ない気がするけど、結果は後からついてくるだろうことを願っております。

台北へ。
10時48分の電車に乗車しました。

車窓から。雲が低い。

台北駅に12時30分につきました。
歩いて、MRTTaipei main stationへ移動です。

またもコイン型のチケットを買い、構内へ。

 これが入り口。

 この黄色のところにタッチ。

 すると開く。

 車内。

 乗り換え。

 反対側は、この階段で移動する。

車内の天井に今どこかを示す情報が呈示。松山空港まであと数駅。

 松山空港に着。ちなみに、松山駅というのもあるので、間違えそうになった。情報は正確に。

本当に空港側に地下で行けそう。

動く歩道もある。店も何点か。

 国際線はこっちのほうらしい。

 地上へ。普通に地上。

気が付かないだけで、地下への道は空港の前にあった。

これは知らないと入れないです。もう少しわかりやすくできるはず。


空港内。

噂のタピオカドリンク。言葉なんてわかんなくても指さしのみで指定できました。

甘め、うまめ。食事部門では、エッグタルト、ステーキの次においしい。ドリンク部門では、マンゴージュースと同等。
次は噂の麺屋。

 うめジュース。なぜか煙い曇った味がする。うまくはない。

 牛リブラーメン。細麺も選べますが、太麺を選択。

コシ強い風のうどんみたい。すごく強い麺ではない。

 肉はやわらかった。うまみ。
ニンニクが強いので、このあと6時間以上はにんにく臭かったはず。

 出国後の風景。

 がらん。

 がらん。

 はじっこ。

 自販機がところどころにあります。

 アスパラガスを飲みましょう。

甘い飲み物。別にアスパラ感はないです。
次に豆も行きましょう。

 無言。
時間になり飛行機に乗る。
機内食。

 まぁ。まぁかな。
その後、空港で買ったライチのゼリーを開封。

こちらはおいしい。想像のライチそのもの。だれかが種のないライチと言ったが、その通りだと思いました。

飛行機を降りて以降、鼻水が出てくる。