Yamyam: 1版をインポートしました

2018-06-28T20:57:24Z

1版をインポートしました

wiki>DingTo: Created page with "= Week 9 = == What I did this week == * I did some cleanup in the Cycles code this week in trunk. ({{Commit|59043}}, {{Commit|59070}}, {{Commit|59072}}...) * Commited some mot..."

2013-08-16T22:18:47Z

Created page with "= Week 9 = == What I did this week == * I did some cleanup in the Cycles code this week in trunk. ({{Commit|59043}}, {{Commit|59070}}, {{Commit|59072}}...) * Commited some mot..."

新規ページ

= Week 9 =

== What I did this week ==
* I did some cleanup in the Cycles code this week in trunk. ({{Commit|59043}}, {{Commit|59070}}, {{Commit|59072}}...)

* Commited some motion blur code to my branch. ({{Commit|59183}}). We can now enable/disable motion blur on a per object basis, inside the Properties Editor. This commit also has some basic code for the motion multiplier, but I still need to properly hook that up with the object transform matrix and shutter time.

* I did some research on a new sky model this week. Cycles (as well as Blender internal) use [http://www.cs.utah.edu/~shirley/papers/sunsky/sunsky.pdf A Practical Analytic Model for Daylight], but there is a better model available since 2012. [http://cgg.mff.cuni.cz/projects/SkylightModelling/ An Analytic Model for Full Spectral Sky-Dome Radiance]. The current Preetham model suffers from some problems especially for sunset and sunrise, which is better in the Hosek/Wilkie model. So I did some research here, to check if a inclusion would be feasible.

'''Questions and observations'''

The current model gets calculated within Cycles itself.

SVM: Pre-calculation in nodes.cpp, final evaluation in the SVM file.

OSL: Has everything in the .osl file, but as the sun_direction and turbidity is constant, it can only calculate that once and optimize it out then for the actual rendering. (OSL makes heavy use of constant folding etc.)

The new model on the other hand comes with a 66kb large dataset with values (ArHosekSkyModelData_RGB.h). (See [http://cgg.mff.cuni.cz/projects/SkylightModelling/HosekWilkie_SkylightModel_C_Source.1.4a.zip Sample code archive].)
Other engines all use this data, so I guess we need it too. But I guess we should use that to precalc the sky again, and not increase kernel size. What confuses me is that "ArHosekSkyModelState" which we need to initialize. (As we use RGB, we would start with "arhosek_rgb_skymodelstate_alloc_init").

I checked on some implementations of the new model.
* [https://github.com/githole/Skydome/blob/master/skydome.c Simple implementation] which calculates every pixel and outputs an image.
* Mitsuba renders the Sky to an HDR map internally and uses this.

So basically I would appreciate some starting points on how to approach this. Use the model data? Separate code into precalc and svm evaluation again?

== Next week ==
* Continue with the Sky feature. I would also like to spend some time documenting some of Cycles code, which is not so trivial to understand (at least for me). :)

== Questions ==
See above, regarding the new Sky model.

← 古い版	2018年6月28日 (木) 20:57時点における版
(相違点なし)

利用者:DingTo/GSoC 2013/Weekly Reports/Week9 - 版の履歴

Yamyam: 1版 をインポートしました

wiki>DingTo: Created page with "= Week 9 = == What I did this week == * I did some cleanup in the Cycles code this week in trunk. ({{Commit|59043}}, {{Commit|59070}}, {{Commit|59072}}...) * Commited some mot..."

Yamyam: 1版をインポートしました