はじめて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).