Lx=d: SundayResearch

Here is my Japanese translation, part 1/3. Robust Monte Carlo Methods for Light Transport Simulation 光輸送シミュレーションのためのロバストなモンテカルロ法 著者(Author): Eric Veach Translated by Lx=d HY  本学位論文の目標は光輸送問題を解くための 1. 汎用，かつ 2. ロバストなアルゴリズムを開発することである．1 の汎用性という目標を達成するために，我々は Monte Carlo 法に注目した．なぜなら，現時点では Monte Carlo 法のみが，実世界にあるさまざまな表面幾何物体(surface geometry)，反射モデル(reflection models), そして光学的効果を扱うことができるからである．2 のアルゴリズムがロバストとは，できる限り考えられるさまざまな入力に対して，破綻することなく，十分な精度の結果が得られるアルゴリズム，つまり入力に対して出力が頑健なアルゴリズムという意味でロバスト(頑健)という．本学位論文で，我々は本質的で重要な結果を得ることができた．すなわち，新しい理論モデルと統計モデルの構築を行い，新しいレンダリングアルゴリズムを開発することができたのである．一方で論文中で，本手法ではいったい何ができないのか --- 光輸送問題を解くための手法の持つ限界 --- に対する議論も行なっている． これまでに光輸送問題に関して多数の研究がなされてきたが，現存する手法には，依然として大きな限界が存在している．現存の手法は，通常入力モデルに大きな制限を課しており，この制限が成立するとして最適化を行なっている．したがって，この制限から外れた入力を扱う際には膨大なリソースを必要とする傾向がある．たとえば，入力シーン中には間接照明があまりないと仮定していたり，シーン中に存在する面の多くが拡散面であるなどという仮定をしている．そのため，この仮定を満たさないシーンが入力される場合，たとえば，間接照明の効果が大きいシーンや，拡散面でない物体で構成されているシーンをレンダリングしようとすると，時間がかかりすぎたり，メモリ消費が大きすぎるということがしばしば起こる．しかし，間接照明があるとい

Here is the (bijectional) Japanese translation, part 3. Robust Monte Carlo Methods for Light Transport Simulation 光輸送シミュレーションのためのロバストなモンテカルロ法 著者(Author): Eric Veach Translated by Lx=d HY 1.1.2 輸送モデルに関する仮定 光輸送アルゴリズムは全ての光の振舞いをシミュレートするのではない．なぜなら，ほとんどの応用でそれは必要でないからである．(脚注: 厳密に言えばそれは可能ですらない．なぜなら全ての物理学が知られているわけではないからだ．しかし，光と物体の相互作用は物理学が提供できるものとしては最上のものの一つである．そして実質的に全ての観測される現象はすばらしい精度で予測できる．[Feynman 1985] コンピュータグラフィックスの目的としては我々はこれらの法則が完全に理解されていると仮定してよい．) グラフィックスの立場に立つと，物理学の光学は一つの可能性のメニューとしてはもっとも良いものとして考えられる．各応用に対して，我々はどの光学的効果が重要かを決め，そしてそれをシミュレートできるアルゴリズムを選ぶ． 我々の論文においては，我々は一般的に幾何光学モデルを仮定する．光は表面からのみ放射され，拡散され，吸収される．そして，これらの面の間では光は直進する．したがって，雲や煙のような participate 物体(吸収・拡散を行う物体)，あるいは屈折率が連続的に変化する物体(たとえば，熱せられた気体)は許可しない．我々はまた，波長や量子力学的効果に依存する(たとえば回折や蛍光)光学効果のほとんどを無視する．特に，我々は光線間の相互作用の可能性，すなわち，光は完全に非干渉であることを仮定する． 通常の環境では，我々が無視した効果はそんなに重要ではない．幾何光学は我々が目にする周辺のものをほとんど全て適切に，高い精度でモデル化する．このため，実質的に全てのグラフィックスでの光輸送アルゴリズムはここでの仮定と同様の仮定を行っている．この章の後ほどで，可能性のあった他の選択肢に関して調査することにする(1.5 と 1.6 節参照)． この後，より日本語と

Here is the (bijectional) Japanese translation, part 2. Robust Monte Carlo Methods for Light Transport Simulation 光輸送シミュレーションのためのロバストなモンテカルロ法 著者(Author): Eric Veach Translated by Lx=d HY 1.1 光輸送問題 コンピュータグラフィクスの世界においては光輸送シミュレーションは人工的な世界，かつ納得できる世界を作成することを助ける道具である．我々には形状や表面の散乱属性を含む環境についての記述が与えられている．また我々には光源の記述，どの画像が生成されるかというための視点も与えられている．光輸送アルゴリズムはその後，写実的で正確な画像を生成するためにこの世界の物理をシミュレートする． 1.1.1.なぜ光輸送は重要なのか 光輸送アルゴリズムの大きな目標の一つは，写実的な仮想環境モデルを人が効率的に生成することを助けることである．たとえば，コンピュータアニメーションでは現時点ではよりリアルな光源をデザインすることに多大な努力が払われている．主な問題は，プロダクションで利用されている(スキャンラインやレイトレーシングなど)のアルゴリズムは間接光をシミュレートする能力がない．つまりライトが置かれた時点で間接光が自動的に有効になることはない．そのかわり，それらの効果は注意深く置かれた光源によって模造されなくてはならない．もし，我々がロバストな光輸送アルゴリズムを自動で計算することができるなら，光源設置の仕事はより簡単になる． 光輸送シミュレーションのその他の応用は予測可能なモデリングである．つまり実際に製作する前に物体の外見を予測したいという欲求である．この考えは建築や，製品デザインの分野では明らかである．これらの応用では結果は客観的に正確であり，かつ，見た目も良いものであることが重要である． 最後にグラフィックスの分野での光輸送の技術の発展は，結局物理と工学に置いてもより広い手法の発展に寄与する可能性が高い．1.6節は，これらの可能性についてくわしく議論している． もしロバストな光輸送アルゴリズムがみつかったならば，広く利用されることは確実である．これは一

Here is the (bijectional) Japanese translation, part 1. Robust Monte Carlo Methods for Light Transport Simulation 光輸送シミュレーションのためのロバストなモンテカルロ法 著者(Author): Eric Veach Translated by Lx=d HY Introduction 本学位論文の目標は光輸送問題を解くためのロバストで汎用のアルゴリズムを開発することである．汎用性という目的を達成するために，我々は Monte Carlo 法に着目した．現在の所，Monte Carlo 法を用いた方法のみが，実世界で起こる広範囲の表面幾何物体(surface geometry)，反射モデル(reflection models), そして光学的効果を扱うことが可能なためである．ロバストなアルゴリズムという意味は，可能な限り広範囲の入力に対して十分許容できる精度での出力が得られるということである．本学位論文では，我々はこの目標に向かって本質的な進歩を得た．すなわち，新しい理論モデル，統計モデル，そして，レンダリングアルゴリズムを開発した．我々は本手法では何ができないのか --- 光輸送問題を解くためのそれぞれの手法の持つ限界 --- に対しても議論を行なった． これまでに多数の研究がなされたにも関わらず，現存の光輸送問題の解法の能力には大きな限界が依然としてある．現存の手法は，入力モデルのクラスに対して大きな制限をしており，その制限の下での最適化を行なっている．この制限から外れた入力を扱う際には膨大なリソースを必要とする傾向がある．たとえば，間接照明に強く依存するシーンや，多くの表面が拡散面ではない(non-diffuse)シーンにおいて，しばしばこの問題が表面化する．しかしこのような例は特に異常な例というわけではない．実際にはこのような例を解きたい(たとえば建築の分野など)ということはよくあることである． 光輸送問題を解くアルゴリズムが広く利用されるためには，あまり壊れやすくない(less fragile)ような手法を開発することが重要である．レンダリングアルゴリズムは現実にあるものに近いモデルを用いて許容できる時間内で解を出す必要がある．そして出力される

Eric Veach's doctor dissertation -- Robust monte carlo methods for light transport simulation -- is famous of its great contents, its clarity, and its completeness. Some of my friends recommended me the paper and this time I decided to read it. Basically, it is not necessary to add any annotation to this paper, but, there are some difficult part for the person who is not a specialist of rendering technique, like myself. Therefore, I would put some notes for myself. What is the Eric Veach's paper Computer graphics less cares about the physically correctness since the computation cost is very high. They rather concentrated to generate nice images which looks like real for human perception, but, not necessary to physically correct. However, if you want to a reality, simulating it is the straghtforward way and no cheating. This paper explain a method that tries to achieve physical correctness and robustness. I think this is a great paper. How to get the paper Download it from h

Long time, I thought an expression ``The last but not least'' was special, but recently, I finally connect this with a small cultural thing. In English, an important thing comes first. Therefore, it is 'not least'. In Japanese, the last one could the most important thing. ``Tori'' is the last one and the most important one -- it is Shin'uchi. If you said, ``Zenza'' means one before, that is usually less important. I miss this assumption. This is a kind of cultural thing, but this is a superficial thing for me. As far as I know, any culture prioritize the issues, and the first one or the last one is the most important. Some think this is big issue, but, I thought it was just picked one of them. For example, in Japanese grade system, five is the best if it is five degrees. If someone gets all one, that's bad. All five is the good one. This is not the case in Germany. Or in USA, if the grade is ABC, then A is better. Mathematics usually didn't c

This is a follow up of the 3-19's C++ riddle. Note: this article assumes the reader has some knowledge about C++ language. There was a question about the last C++ riddle: Is this standard defined behaviour or depending on the environment? The last blog, I am a bit uncertain on the pitfall 4, Pitfall 4. This pointer is implicitly converted to boolean type． this is standard or not. So, I tried gcc4, icc9, and VisualStudio2008. If it is not a compiler bug, this is environment dependent. Visual Studio 2008 a.obj : error LNK2019: unresolved external symbol "class std::basic_string>char, struct="" char_traits=""<>char<<,class std::allocator>char < __cdecl middle(void)" (?middle@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) refer enced in function _main a.exe : fatal error LNK1120: 1 unresolved externals --- icc9 a.cc(6): remark #1419: external declaration in primary source file std::string middle(); --- gcc4 a.cc

When I want to write my name in English/German document, there are several ways to do that, and it is confusing. For example, 村上春樹 can be written as 1. Murakami Haruki 2. Haruki Murakami 3. Haruki MURAKAMI 4. Murakami, Haruki. For me, when I wrote my name in Latin characters, it has already been not quite my name (my mother can not read it) and the pronunciation has already been altered. (Usually people call me man-cow or something in Japanese. But, that's ok. I cannot pronounce others.) Therefore, I consider that it is just an approximation of my name, and I don't think further. Maybe one reason is that my name has different writing way, but the same pronunciation. (E.g., Japanese name Hiroshi is written in 宏，浩，弘， 洋.... These are all Hiroshi, but all have different meaning. When I wrote my name in Latin character, then it already lost some meanings. Maybe this is related I am not so eager to think how to write my name. A movie title 'Sen to Chihiro no Kamikakushi'

This is the solution of the last blog. Notice: You need C++ language knowledge to read this article. First, I checked up that what does the string's default constructor do. But, it constructs a empty string instead of '1'. Next, I put break points at all the constructors from my debugger. But, I cannot hit any breakpoint. If I changed the middle()'s line as following, std::string prefix("->"), middle(""), postfix("<-"); I got the expected result: Hi:-><- A hint is that the middle() is like this. std::string middle(); Can you see now? So what kind of C++ pitfall I jumped in? 1. This is not a definition of the string object middle, but, it is a declaration of a function middle that returns string. 2. Therefore, middle in the cout like is a function pointer. 3. When a function is declared, there should be a valid function pointer regardless the implementation. (Otherwise, linker failed and we can not have an executable.)

Notice: You need C++ language knowledge to read this article. My colleague sometimes gives me a C++ quiz. This is one of such quiz by Peter. What is the output of the following C++ program. #include <iostream> #include <string> int main() { std::string prefix("->"), middle(), postfix("<-"); std::cout << "Hi:" << prefix << middle << postfix << std::endl; return 0; } The result is the following. Hi:->1<- There is '1' in the middle. Why this happens? Before I give you the explanation, I will give you some time. Enjoy! To be continued.