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

[Thomas Dinges]

Hi,
resending this, to use proper topic name and also copy report in here:
(Copy of 
http://wiki.blender.org/index.php/User:DingTo/GSoC_2013/Weekly_Reports/Week1)

= Week 1 =

== Pre work ==
I started early with my GSoC, therefore I already finished some tasks 
before.
* Blackbody to RGB converter, to convert temperatures to a color. This 
node is inside my branch. I still have to figure out a problem with 
temperatures between 800 and 804 Kelvin, the lookup table does crazy 
stuff there. Example render: http://www.pasteall.org/pic/show.php?id=53582

* Toon Shader: The toon closure is finished and already in Trunk, it 
will be part of the Blender 2.68 release. Example render: 
http://www.pasteall.org/pic/show.php?id=51970

* Additionally, I added a Wavelength to RGB converter (in trunk as 
well), which can be uses to create interesting effects or simply to find 
the right color, by using a real world unit. Here a nice render by 
mfoxdogg: http://www.pasteall.org/pic/show.php?id=53746

== What I did this week ==
* I started working on the Vector Transform node, to convert vectors and 
points between Object/World and Camera space. I added the UI and DNA/RNA 
code for it, the Cycles integration still needs to be done.

As I am mostly done with my Nodes, I spend some time on other Cycles tasks:
* Non-Progressive integrator has been enabled on GPU inside my branch. 
How this works out remains to be seen, it's probably not a good idea to 
bring this into trunk anytime soon, as it makes the GPU kernel about 2x 
as huge. Nevertheless, the Non-Progressive integrator has its strengths 
and if that works good on GPU (in my tests on a Geforce 540M it did), we 
should check on how we can get this feature into trunk. One idea would 
be to compile 2x kernels per architecture, Progressive and 
Non-Progressive integrator. We could split kernel_path.h into 
kernel_path_progressive.h and kernel_path_non_progressive.h and compile 
2 entry points for the GPU.

* GPUs could only handle 95 textures and 5 HDR (float) image textures. 
This is a limitation of older Fermi cards, we have only 128 textures 
available there. For new Kepler cards though (sm_30 and sm_35), the new 
limit is 256 textures, so I increased the limit a bit for these 
architectures. We can now use 145 byte images and 5 float images (so 150 
in total). This could be increased to about 200 if needed. It would be 
interesting to know if the change works on Kepler GPUs, I don't have 
such a card to test.

== Next week ==
As I started earlier, I already have some things done, so I am good in 
time. I'd like to focus on exam preparation next week and maybe the week 
after. This has been discussed with my mentor Stuart. Nevertheless, I am 
confident to find some time to add some things during this time too, 
let's see.

== Questions ==
No specifics at the moment, I started looking into BVH code and shader 
code for the "per object motion blur" and "ray depth" feature, but still 
have to read more code in order to understand the architecture well.

-- 
Thomas Dinges
Blender Developer, Artist and Musician

www.dingto.org