[Soc-2013-dev] Weekly report #9 Cycles nodes

[Tycho Tatitscheff]

Hi,

i wonder if there is a way in your shader to draw the solar disk too.
If we could sync the solar disk with the main sun lamp (for instance using this http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/3D_interaction/Sun_Position), it would be perfect.

I dont look your code in details but martinsh ubris glsl code draw the sollar disk http://pastebin.com/c5g7TuiC

Cheers
Tycho

________________________________
 De : Thomas Dinges <blender at dingto.org>
À : Blender GSoC 2013 <soc-2013-dev at blender.org> 
Envoyé le : Samedi 17 août 2013 0h23
Objet : [Soc-2013-dev] Weekly report #9 Cycles nodes
 

Hi,
here my week 9 report: 
http://wiki.blender.org/index.php/User:DingTo/GSoC_2013/Weekly_Reports/Week9

Best to read it in the wiki, as there are lot of links.

= Week 9 =

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

* Commited some motion blur code to my branch (r59183). 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.

Best regards,
Thomas

-- 
Thomas Dinges
Blender Developer, Artist and Musician

www.dingto.org

_______________________________________________
Soc-2013-dev mailing list
Soc-2013-dev at blender.org
http://lists.blender.org/mailman/listinfo/soc-2013-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2013-dev/attachments/20130821/cd324f90/attachment.htm