Overall, I think this week I've started to pick up the pace, although not by too much, there's still plenty of room for lot's of improvement, but at this point everything is starting to feel like it goes into place, which makes me happy.<div>
<br></div><div>I spent a lot of time this week trying to get some of the tests to work in background mode. Unfortunately, several of the needed api calls (saving/loading/rendering/saving images), only work when in regular mode. I also had other problems with API calls not working properly even in the foreground mode, and I've done some more hacks on the codebase, and submitted some bug reports, although at this point, I've got most of the API calls I need working, albeit they're still a bit buggy. In the end, we've decided to run the tests in the forground (for now), and just run the exit blender api call at the end of the test. The largest problem with this is that if the test segfaults, blender won't quit, and the user must quit it himself. Also, it's quite annoying to have a window pop up and close over and over again while running the tests. Thus, as soon as some of the bugs I've reported are fixed, I'll be switching back to background mode.</div>
<div><br></div><div>I've also started doing some image comparison tests. I don't really have any good algorithms yet, so I'm still very open to suggestions. Currently though, I've tried several iterations of a histogram comparison. Both comparing all the color bands at the same time, and comparing them separately, the first one is quite a bit faster, although I think that's do to how I'm using the API calls.</div>
<div><br></div><div>By far, the largest problem I've run into image testing (besides there being no python API call to render an image and save it, even in foreground mode), is the fact that PIL currently only supports python 2.x. So, to compensate for this, I've split the image tests into two parts, the rendering test (and everything else that can be done in blender), and the comparing tests, which use PIL. If I need to, I suppose I could read in the files myself, and use the raw data the files bring in, but I believe that would waste time, and wouldn't be as effective as using something like PIL. The issue than becomes the lack of not being able to render anything and save it in python. To get around this, I'm currently saving to a .blend file, using the command line to render the files, although I've run into the problem of getting CTest to run multiple commands in one test, which I'm looking into. Another thing I'm thinking about doing, is getting an exec function for the image.save_as() operator to work. Oddly enough, it only works when the image screen is up (which, in my opinion, goes against blender's non-modal philosophy), or rather, when the image is in the buffer, (which only happens after the user hits f11 or f12 (+ ctrl, or whatever you set to render/show images/animations), and the problem comes because there is no python API call for it. Oddly enough, in regular mode, the invoke function also works just fine as an exec function, but in background mode, it segfaults. I've stopped it from segfaulting, but because the value is still null (do to being in the background), it's still imposable to actually save the image. (Although the 'view' is the image view). Also, the invoke function still is a bit quirky as an exec function. So, I'm thinking it might be possible (because I'm currently running the tests in the foreground anyway), to just render the images and save them in the python file, which would not only be easier (api call wise anyway), than mucking about with CMake, but make more logical sense, and allow for easy unification of the tests when PIL is supported for python 3.x.</div>
<div><br></div><div>Most of this I've done to test what appears to be rendering problems with viewing hair as 'object' or 'group'. (Which may have been solved, or proven to be a feature rather than a bug, I haven't checked the bug tracker for that particular bug for several days). But, as long as it's not a feature, it still would be useful for a regression test.</div>
<div><br></div><div>I did get a chance to look at sphinx documentation, although not very much, and not enough to get anything done. I doubt I'll get to it next week, but I still am keeping this as a back burner project. (Albeit a very back burner project, it's currently more important to me to get the python api up to snuff in background mode).</div>
<div><br></div><div>Finally, today and/or tomorrow, I plan on writing a month in review. Because I like wordpress's editor, I'll probably first put it up on my blog (<a href="http://leifandersen.net">http://leifandersen.net</a>), and shortly post it on my project's wiki page: (<a href="http://wiki.blender.org/index.php/User:LeifAndersen/GSoC2010">http://wiki.blender.org/index.php/User:LeifAndersen/GSoC2010</a>)</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div>Next week I do not plan on dealing to much with issue of background mode, except as a back burner project. I have submitted bug reports, and will be participating with them though. I may devote a few hours next week to this though. I also plan on finishing up good image comparison algorithms, and I'll put them in my tests module, however, I won't be able to use that module until PIL works on python 3.1, but it should make it easier to move the tests. Except for possible rendering problems, I still believe that hashcode based tests are more effective than render tests, so I'll probably work on that a bit. Finally, I plan on making the structure cleaner. I may remove the gtest portion altogether, as it's not needed, and just in the way, as well as possibly changing the structure of the python tests to a more logical order, rather than simply module level order. As well as finding a good place to put the CTest commands.</div>
<div><br clear="all">~Leif Andersen<br><br>----------<br>That was easy: <a href="http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton" target="_blank">http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton</a><br>
</div>