My first week as a SoCer is coming to an end. I’ve been added to a couple of SoC-related mailing lists; those gave me the opportunity to really feel the international breadth of this program.
I’ve also had some exchanges with my mentor, Kent Mein. In particular, he reminded me that I should take care of external testers, should there be any. He’s right. In practice this means that maybe I should not delegate the light conversion/generation step to an external script, which would prove cumbersome to use for other people, and code that in C straight away instead. Originally I planned to do that later on as it is conceptually very simple but potentially longish to code; additionally, I would like to experiment a bit on different ways to do that, and Python would be way more flexible in this. We’ll see.
My own branch was created as well, and I finally have commit rights for Blender! Isn’t that cool? Far less cool was the horrendous breakage of Subclipse after a dry run of an svn merge command. There was no way to recover from it, and I had to disable Subclipse altogether. I don’t mind using svn from the command line, but this provided yet some more ground to question Eclipse CDT as a development environment. More on this in a future post.
Meanwhile, I started writing some code to test if my high-level design is viable. My hope is that the lightcuts project should eventually have only two entry points:
- an initialization routine, that generates point lights and builds the three required trees out of them (one for omni lights, one for directional lights, one for oriented lights)
- a “gimme the lights” routine that returns a different set of point lights per pixel/sample
Until now, I successfully created a fake step 1 that for each light in the scene creates another one, with random color and 1 unit displacement. This is a test image I kind of like:
Only the white lights were present in the scene.
Step 2 is a different story. Right now, the light list is iterated directly at various points in the code. My original plan was to add a lightcuts_get_light_list() API before each iteration, but on second thought, that’s not a good idea: I would have to allocate an actual list for each pixel/sample only to retain compatibility with existing code. The only other solution I can think of right now is to provide a sort of “iterator interface” to the lights list, along the lines of a get_next_light() method. In this case we trade an allocation overhead for a call overhead, so it could be worth to look for an other alternative.