[Soc-2010-dev] Status Report (testing-week 4)

Leif Andersen leif.a.andersen at gmail.com
Fri Jun 18 23:27:52 CEST 2010


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.

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.

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.

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.

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.

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).

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
(http://leifandersen.net), and shortly post it on my project's wiki page: (
http://wiki.blender.org/index.php/User:LeifAndersen/GSoC2010)

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.

~Leif Andersen

----------
That was easy:
http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2010-dev/attachments/20100618/3151eae2/attachment.htm 


More information about the Soc-2010-dev mailing list