The Unctuous Rants of Leif Andersen

Your Fiduciary Source for Science, Technology, Rants, and Occasional Journalism

Archive for category Linux/FLOSS

Blender GSoC Week 7 Status

Jul 11

Posted by Leif Andersen in Google, Linux/FLOSS, Programming, Technology | No Comments

Overall, I think this has been a good week.  I worked almost exclusively on the image comparison diff tester this week.  I wrote it in python, and it can actually work independent of blender (although it does assume that blender is on your system, and in your path, although that can be changed with the –blender-bin flag).  This means that the tests folder can be put in a zip, and placed in the same location as where the current regression tests (for blender 2.4x) are located on the website.
As I said last time, the general way to run the tests is by using python run.py.  You can use the -v flag to see the output of blender as it’s rendering it.  Also, it might be possible to avoid even having to download the images at all, by using the recently built –built-tests flag, which, instead of rendering tests, will render the images and store them in the known good folder.  (It uses the version of blender in your path).
Through the use of the –image flag, you can compare any blender image on your harddrive (currently assuming it’s in the right file structure), this allowed me to make other image comparison tests, that compared blend files built by pyunit based tests.  This (along with the hashcode operator I started putting together last week), means that most of the tools for building good unit tests (and regression tests in general), are almost build (I think).  Meaning that now the only missing piece of the puzzle is the one I was working on several weeks ago (without luck), which is:
  • A.  Getting the python API to work in background mode (which blender currently isn’t designed to do).
  • B.  Getting the python API to work properly in foreground mode (lots of stuff in bpy.wm crash.  (At least it did as of a week ago, do to low bandwidth caps here, I won’t’ merge until tomorrow evening (when I get home), so they may have been fixed by now)).
Although Andrea only looked at my code to determine good structure, etc.   I believe that most of the bugs have been removed.  (Although, this is python, and bad code doesn’t show up until someone tries to run it, and I haven’t made regression tests for my regression tests. ;) (at least not yet anyway, and it’s not on my radar in the near future)).
The comparator is also capable of producing animation tests.  However, this code is slightly buggier.  Also, by default, I’m not running the animation tests in the current regression suite, because it takes the running time up from 2:30, to over an hour.  I have a –animation flag, but it doesn’t work at the moment.  (Although the underlying code works, so it’s basically just a matter of plugging the code into the flag).
Finally, because the animation images make the overall file size ~240 MB (as apposed to 30 MB), they are not in the default build.  But rather, the user has two choices, they can either A:  Render Good ones, or B.  Use a hash code (and download images (or generate them) if something goes wrong).  The hash code also work in images.  However, the code for this is only half built.  The test case classes support it, but the surrounding structures don’t use it yet, this shouldn’t be more than an hours worth of work to implement it fully.
Finally, I didn’t do as much work as I would have liked in the HTML output.  Now, rather than using static CSS scripts from sphynx, I now build the CSS in the script itself.  (With the exception of images, I’m not sure how to do that as a python script…well, there is PIL, but I’d sooner put bamboo up my fingernails than make the needed images that way).  Although the output is starting to look like it’s from blender’s website.  (Although the table doesn’t quite fit).  Also, it will only generate images for single images (well, that, and animations, but it only does the first frame).  Eventually, the animations will be clickable, and you can view a separate HTML page for the entire animation, but that’s not built yet.  It shouldn’t be too hard to make, but I keep having to do one or the other thing, so the current implementation is old, and would probably cause the script to crash if used.

Overall, I think this has been a good week.  I worked almost exclusively on the image comparison diff tester this week.  I wrote it in python, and it can actually work independent of blender (although it does assume that blender is on your system, and in your path, although that can be changed with the –blender-bin flag).  This means that the tests folder can be put in a zip, and placed in the same location as where the current regression tests (for blender 2.4x) are located on the website.
As I said last time, the general way to run the tests is by using python run.py.  You can use the -v flag to see the output of blender as it’s rendering it.  Also, it might be possible to avoid even having to download the images at all, by using the recently built –built-tests flag, which, instead of rendering tests, will render the images and store them in the known good folder.  (It uses the version of blender in your path).
Through the use of the –image flag, you can compare any blender image on your harddrive (currently assuming it’s in the right file structure), this allowed me to make other image comparison tests, that compared blend files built by pyunit based tests.  This (along with the hashcode operator I started putting together last week), means that most of the tools for building good unit tests (and regression tests in general), are almost build (I think).  Meaning that now the only missing piece of the puzzle is the one I was working on several weeks ago (without luck), which is:A.  Getting the python API to work in background mode (which blender currently isn’t designed to do).B.  Getting the python API to work properly in foreground mode (lots of stuff in bpy.wm crash.  (At least it did as of a week ago, do to low bandwidth caps here, I won’t’ merge until tomorrow evening (when I get home), so they may have been fixed by now)).

Although Andrea only looked at my code to determine good structure, etc.   I believe that most of the bugs have been removed.  (Although, this is python, and bad code doesn’t show up until someone tries to run it, and I haven’t made regression tests for my regression tests. ;) (at least not yet anyway, and it’s not on my radar in the near future)).
The comparator is also capable of producing animation tests.  However, this code is slightly buggier.  Also, by default, I’m not running the animation tests in the current regression suite, because it takes the running time up from 2:30, to over an hour.  I have a –animation flag, but it doesn’t work at the moment.  (Although the underlying code works, so it’s basically just a matter of plugging the code into the flag).

Finally, because the animation images make the overall file size ~240 MB (as apposed to 30 MB), they are not in the default build.  But rather, the user has two choices, they can either A:  Render Good ones, or B.  Use a hash code (and download images (or generate them) if something goes wrong).  The hash code also work in images.  However, the code for this is only half built.  The test case classes support it, but the surrounding structures don’t use it yet, this shouldn’t be more than an hours worth of work to implement it fully.

Finally, I didn’t do as much work as I would have liked in the HTML output.  Now, rather than using static CSS scripts from sphynx, I now build the CSS in the script itself.  (With the exception of images, I’m not sure how to do that as a python script…well, there is PIL, but I’d sooner put bamboo up my fingernails than make the needed images that way).  Although the output is starting to look like it’s from blender’s website.  (Although the table doesn’t quite fit).  Also, it will only generate images for single images (well, that, and animations, but it only does the first frame).  Eventually, the animations will be clickable, and you can view a separate HTML page for the entire animation, but that’s not built yet.  It shouldn’t be too hard to make, but I keep having to do one or the other thing, so the current implementation is old, and would probably cause the script to crash if used.

Tags: , , ,

Blender GSoC Week 6 Status

Jul 11

Posted by Leif Andersen in Google, Linux/FLOSS, Programming, Technology | No Comments

I’ll try to make this short, as it’s late here.
Even though I got sick this week (it turned out to be just a cold/flu), and went out of town (and still am), I believe that this week has been one of the most productive weeks so far.
This week started off with me implementing some of the GUI features I worked with last week, which is to say I started making the image diff tests into an operator.  (Previously they had been baked into the tests directly).  They could be run from a Tests dropdown menu, although there was non feedback outside of the console, leading the user to believe blender had frozen while the tests were running.  Andrea pointed out that this was pointless, and that it should just be a script.  As such, I started implementing it in all in python 2.x.  The tests can be found in tests/render, and I put together a slight howto on how to run them: http://wiki.blender.org/index.php/User:LeifAndersen/GSoC2010/Howto
Render Tests
The current set of render tests requires PIL, and python 2.x. In order to run them, inside the blender source directory, look in: tests/render. There, you should find a collection of files. While the absolute path of those files doesn’t matter (aka, you could move the tests/render folder anywhere, and it would do just fine), those files must be kept in the same relationship to each other. If blender is already in your system path, just go into the folder, and run python run.py, and the script will take it’s course. If blender is not in your current path, open up run.py, and change the BLENDER_BIN variable to you blender binary, and than run python run.py. You can view the results in the console, otherwise you can see a list of all of the results, as well as diffs, by opening index.html in your web browser.
(my most recent commits have temporarily broken this as an operator, but I will soon fix that).  There is a webpage that is outputted which allows you to easily see the difference between the renders.  In addition, the algorithm for analyzing the images is much improved.
I also moved my tests.hashcode module into an operator (bpy.ops.tests.hashcode()), or Tests->Hashcode.  Although it still only gives feedback in the terminal, and only takes some things into account when making the hashcode.
As far as next week goes, I am going to spend a bit of time with the webpage.  It’s not quite flush with blender’s webpage, but it’s getting closer.  But more importantly, I can see a few more options that would allow the user to get more of the raw data behind the images (which I would assume would make it debug).  Most of this I believe can be written in HTML, but some javascript may be useful.  I also plan to get animations working with these tests, and possibly bringing this back in to work with the blender operator.  I also am going to try to get a lot more feedback this week, and hope to have the tool used soon after.  I will also spend a bit of time getting the hashcode operator to take more into account, as well as giving more feedback to the user.  (As in feedback that’s not only just console output).  I would also work on aggregating the data in the blend file for the user to test, but blender is already capable of that.  Finally, I plan on improving the integration of Ctest and CDash, but that seems trivial to do.

I’ll try to make this short, as it’s late here.
Even though I got sick this week (it turned out to be just a cold/flu), and went out of town (and still am), I believe that this week has been one of the most productive weeks so far.
This week started off with me implementing some of the GUI features I worked with last week, which is to say I started making the image diff tests into an operator.  (Previously they had been baked into the tests directly).  They could be run from a Tests dropdown menu, although there was non feedback outside of the console, leading the user to believe blender had frozen while the tests were running.  Andrea pointed out that this was pointless, and that it should just be a script.  As such, I started implementing it in all in python 2.x.  The tests can be found in tests/render, and I put together a slight howto on how to run them: http://wiki.blender.org/index.php/User:LeifAndersen/GSoC2010/Howto
Render TestsThe current set of render tests requires PIL, and python 2.x. In order to run them, inside the blender source directory, look in: tests/render. There, you should find a collection of files. While the absolute path of those files doesn’t matter (aka, you could move the tests/render folder anywhere, and it would do just fine), those files must be kept in the same relationship to each other. If blender is already in your system path, just go into the folder, and run python run.py, and the script will take it’s course. If blender is not in your current path, open up run.py, and change the BLENDER_BIN variable to you blender binary, and than run python run.py. You can view the results in the console, otherwise you can see a list of all of the results, as well as diffs, by opening index.html in your web browser.
(my most recent commits have temporarily broken this as an operator, but I will soon fix that).  There is a webpage that is outputted which allows you to easily see the difference between the renders.  In addition, the algorithm for analyzing the images is much improved.
I also moved my tests.hashcode module into an operator (bpy.ops.tests.hashcode()), or Tests->Hashcode.  Although it still only gives feedback in the terminal, and only takes some things into account when making the hashcode.
As far as next week goes, I am going to spend a bit of time with the webpage.  It’s not quite flush with blender’s webpage, but it’s getting closer.  But more importantly, I can see a few more options that would allow the user to get more of the raw data behind the images (which I would assume would make it debug).  Most of this I believe can be written in HTML, but some javascript may be useful.  I also plan to get animations working with these tests, and possibly bringing this back in to work with the blender operator.  I also am going to try to get a lot more feedback this week, and hope to have the tool used soon after.  I will also spend a bit of time getting the hashcode operator to take more into account, as well as giving more feedback to the user.  (As in feedback that’s not only just console output).  I would also work on aggregating the data in the blend file for the user to test, but blender is already capable of that.  Finally, I plan on improving the integration of Ctest and CDash, but that seems trivial to do.

Tags: , , ,

Blender GSoC Week 5 Status

Jul 11

Posted by Leif Andersen in Google, Linux/FLOSS, Programming, Technology | No Comments

This week has been one of my better weeks.  As usual, there were a few bumps this week, but not too many.
This week dealt with two things:
1.  Image comparison
2.  UI, and thus wrapping unit tests in operators to insert into the UI.
Per Matt Estela’s recommendation, I tried incorporating Perceptual Image Diff http://pdiff.sourceforge.net/ into the tests to compare images.  The pre-compiled binaries work fine, however, compiling from source presents a bit of a problem, even with all of the listed dependencies installed, it complains that several printf stamens are not declared.  I emailed the developer and am waiting for a response.  This isn’t my main priority.  However, I will keep using PIL until such time as a tool like this works.
Getting tests in blender’s UI represents some challenges that do not exist when using CTest as a testing platform.  First of all, I thought a lot about render tests.  If we use blender’s current set of regression tests that blender has, it shouldn’t be very difficult to create a tool that allows a developer to render a blend file, and than compare it to another image file, and than write another tool to run all of the tests.  The problem is that putting this into the GUI, which requires python 3.  And on top of that, developing a good UI for this sort of thing can also be a bit tricky.  Fortunately though, it still is trivial to wrap up unit tests inside an operator, so ultimately, running the tests won’t be too big of a deal, as apposed to setting them up.  I also toyed with writing the operators required in C, although this isn’t as good of an idea as writing it in python, where we could simply give developers a template file to use for their tests, but it may still prove useful.
Next week should be interesting.  Starting on Wed.  and going to the end of the week after that, I’ll be out of town.  With that being said, I won’t be out of communication, but rather, I’ll probably be spending less time on IRC.  (I’ll still try to attend the usual Sunday meeting, as well as spending an hour or so online though).  I will respond to emails as usual, albeit probably a bit slower.   I’ll post an email specifically about this to this list in case this portion of the review is missed.  I still have more UI stuff planned next week, but mainly merging the UI and rendering algorithms into one fluid tool, at which point I’ll start automating it.

This week has been one of my better weeks.  As usual, there were a few bumps this week, but not too many.
This week dealt with two things:1.  Image comparison2.  UI, and thus wrapping unit tests in operators to insert into the UI.
Per Matt Estela’s recommendation, I tried incorporating Perceptual Image Diff http://pdiff.sourceforge.net/ into the tests to compare images.  The pre-compiled binaries work fine, however, compiling from source presents a bit of a problem, even with all of the listed dependencies installed, it complains that several printf stamens are not declared.  I emailed the developer and am waiting for a response.  This isn’t my main priority.  However, I will keep using PIL until such time as a tool like this works.
Getting tests in blender’s UI represents some challenges that do not exist when using CTest as a testing platform.  First of all, I thought a lot about render tests.  If we use blender’s current set of regression tests that blender has, it shouldn’t be very difficult to create a tool that allows a developer to render a blend file, and than compare it to another image file, and than write another tool to run all of the tests.  The problem is that putting this into the GUI, which requires python 3.  And on top of that, developing a good UI for this sort of thing can also be a bit tricky.  Fortunately though, it still is trivial to wrap up unit tests inside an operator, so ultimately, running the tests won’t be too big of a deal, as apposed to setting them up.  I also toyed with writing the operators required in C, although this isn’t as good of an idea as writing it in python, where we could simply give developers a template file to use for their tests, but it may still prove useful.
Next week should be interesting.  Starting on Wed.  and going to the end of the week after that, I’ll be out of town.  With that being said, I won’t be out of communication, but rather, I’ll probably be spending less time on IRC.  (I’ll still try to attend the usual Sunday meeting, as well as spending an hour or so online though).  I will respond to emails as usual, albeit probably a bit slower.   I’ll post an email specifically about this to this list in case this portion of the review is missed.  I still have more UI stuff planned next week, but mainly merging the UI and rendering algorithms into one fluid tool, at which point I’ll start automating it.

Tags: , ,

Blender and Google Summer of Code (GSoC), Month One Review

Jun 21

Posted by Leif Andersen in Google, Linux/FLOSS, Programming, Technology | No Comments

It’s been almost a month since the official start date of Google Summer of Code, and, per Andrea’s recommendation, now is a good time for a month in review.  This won’t go into great detail, I will leave the weekly reviews for that.

So, just a brief checklist of what has happened:

  1. Project Started
  2. Gtest set up
  3. Pyunit setup
  4. tests module created
  5. Hashtests and image comparison tests built
  6. Learned a lot about how the Blender codebase works
  7. Made some hacks and bug reports with the Blender codebase
  8. Initial work on GUI panel for tests (originally dropped, but recently brought back into the foreground)
  9. CMake now using CTest and CDash to report the project

Read the rest of this entry »

Tags: , , ,

Blender GSoC Week 4 Status

Jun 18

Posted by Leif Andersen in Google, Linux/FLOSS, Programming, Technology | No Comments

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.

Read the rest of this entry »

Tags: , , , ,

Blender-GSoC-Week 3 Status

Jun 13

Posted by Leif Andersen in Linux/FLOSS, Programming, Technology | No Comments

As mentioned last week, this week consisted mainly of debugging parts of blender. As such, I believe that the amount of actual deliverables I produced this week is much less than it has been the first two weeks. With that being said though, I believe that I have learned more about the blender codebase than the other weeks, by quite a bit. I also found several tricks for the python API that weren’t documented in the API documentation, which should eventually make the tests much cleaner.

This week I started working with tests for operators as apposed to directly with data. The first problem I ran into was the immutability of bpy.context. I was resorting to hacks to change the context, which only was working some of the time. Thus, I went to GTest, giving it more time than I had planned on this week (a little over a day), because the C-API calls took in a bContext, rather than having it be implicit. However, I never managed to get the linking right, any probes I put into the kernel or operators itself would result with many errors, even for functions that seemed to only allocate space, thus I never got a bContext made.

Fortunately ideasman42 pointed out to me that I could pass in a dictionary, and the operators would use that instead of the value in bpy.context. I haven’t gotten it to work in all of the situations I’ve tried (yet), but many have worked, and it does seem promising. However, that only solves some of the tests, it still would be valuable to run tests using bpy.context, or some other type of implicit context, for better code coverage.

One thing that I really didn’t expect this week, was that most of the bugs I was trying to debug this week, were ones that I found. I was planning on looking for bugs on projects.blender.org, and I did find a few, but when I started building python scripts to test them, I found many more simple problems that I had to deal with first, which took most of my time.

My plans for next week:

My first order of business is to get several operators in bpy.ops.wm (mostly found in the windowmanager folder), working in the python console, and in a script (both when blender has a visible, and no visible window). Currently, I’m working on bpy.ops.wm.read_homefile(), and I’ve made some progress. However, the problem is that the bContext that is passed into it has several null elements in the console, which is expected to be non-null for windowmanager operations. Once I’ve finished that, I will finish my setup.py test, and proceed to use that as my setup method, at which point most of my tests module will become superfluous, and I may take some time dealing with that. In fact, I could likely get rid of it, with the one exception of me using it’s hashcode function. I may also read in a pre-built empty file, rather than the default .b.blend file, which could possibly break the tests if the default was changed, which would be very bad. Finally, as a side project, I’m going to start reading up on how the python API’s documentation is made (I know it’s using sphinx, but I don’t know how it works, yet), and I’ll see what I can do to start helping minddrones with that.

Tags: , ,

Blender-GSoC-Week 2 Status

Jun 5

Posted by Leif Andersen in Linux/FLOSS, Programming, Technology | No Comments

Overall, this week went okay. It didn’t speed up unfortunately, but at least it didn’t slow down either (I think). Several things happened this week:

1. The biggest thing is that I believe I now have enough of a framework set up to begin non-trivial tests, which I began to do today, at least in the sense that I started tracing actual bugs, so far to no success.

Read the rest of this entry »

Tags: ,

Open Source Alternatives to GMail

May 28

Posted by Leif Andersen in Google, Linux/FLOSS, Technology | No Comments

The following is a thread about my email woes I have posted to the ubuntu forums, I will update it with a solution if I find one, you can fie the thread here: http://ubuntuforums.org/showthread.php?p=9374207#post9374207

I’ve been thinking for the past few days, everyone’s been complaining about facebook, and my opinion has been: “it’s your fault for trusting some random company on the internet with all of your private information, don’t put information on the internet you don’t mind the rest of the world seeing”.

And then I got to thinking, what about Google, no one ever talks about that, and the amount of data we’re giving Google for email. I then think that it’s not a big problem, because you’re emailing people anyway, so it shouldn’t really matter, after all, they could always go publish your mail…so it’s just better to not say anything that could be incriminating over email as well. Also, I’m sending unencrypted messages, so it’s still technically wide open.

But then I start realizing that it’s still a bad thing. True, while no one at Google is reading my email (I think), who says that they will always be the ‘good guys’, which is to say, just like how everyone trusted facebook, and their motivations changed, nothing is preventing google from changing it’s opinions. And, even if Google keeps it’s slogan, and never does become ‘evil’, they could still get subpoenaed, etc. etc. In short, I’m saying I shouldn’t trust this thing with the cloud.

So, this lead me to think, what is there out there besides GMail? Sure, there is clients like evolution or thunderbird, but they fail short. In particular, they don’t really have threaded conversations. Most of the other things I need (tags, filters, multiple email addresses), either come built in, or a solution can easily be hacked, but I haven’t found any way to thread emails, and with the way I use email, I really need conversation threading. Also, it would be nice if I could hide quotes by default…but I think there’s a solution to do that.

Does anyone know of a good alternative to gmail that will thread conversations. Preferably an open source solution. I know outlook will do it for you.

Thank You.

Update:

Okay, I just found out that evolution does have message threading, but rather than being in the preferences panel, it’s located in the View drop down menu.  Apparently Thunderbird does the same thing.
I also tried out Zimbra, and other than that it appears to be based very heavily on java, it does look like it would also do the job, in addition, it’s also really easy to configure (unlike evolution which requires you to know how email works to configure it, Zimbra’s desktop client will let you simply put in you’re credentials to any webmail based service, or to your own server, and it will set the rest up for you.  Although, it automatically downloads your mail, which could get annoying.

Okay, I just found out that evolution does have message threading, but rather than being in the preferences panel, it’s located in the View drop down menu.  Apparently Thunderbird does the same thing.
I also tried out Zimbra, and other than that it appears to be based very heavily on java, it does look like it would also do the job, in addition, it’s also really easy to configure (unlike evolution which requires you to know how email works to configure it, Zimbra’s desktop client will let you simply put in you’re credentials to any webmail based service, or to your own server, and it will set the rest up for you.  Although, it automatically downloads your mail, which could get annoying.

Tags:

Cry of Frustration: I want my Sound to Work!

Apr 23

Posted by Leif Andersen in Linux/FLOSS, Technology | 2 Comments

I just wrote up a post on the ubuntuu forums complaining about my sound…here it is in full:

I really love open source, but sometimes, it falls flat on it’s face…this is one of those times. I got a sony vaio vpc eb11ffm from best buy a few weeks back. I brought a livecd, and put it into any of the machines I was considering buying, to see how well it would run. It worked well in the vaio, except for one major flaw, the sound wasn’t working. (I found another one later after I bought it, the system wouldn’t be stable if I had compiz on it).

Anyway, the thing even comes with a version of linux on the machine, for ‘quick boot web surfing’, and the sound works in it just fine. Also, I even was able to find a fix for the sound. It’s not do to any lack of drivers, but one, just one configuration error that ubuntu makes when it’s installing. I go to report the bug, and I even provided the fix to go with it, and it was rapidly merged with another similar, but slightly different bug, and was pronounced to be fixed. I upgraded to the RC that was created today, and nope the problem is still there. And short of opening another bug report, with the same problem, I can’t think of anything to do…grr…

Yes, I know canonical says not to run 10.04 on a machine you need to be stable, but I don’t have much choice. For some reason, 8.10 won’t even boot onto the machine, and I don’t want to go back to windows.

I know you people try hard, and I thank you for it. But sometimes, I just have to rant in frustration, I want my sound to work out of the box.

Thank you for your time. And I’m sorry if this is in the wrong spot.

If you want to see the original web page, it is located here: http://ubuntuforums.org/showthread.php?p=9161218#post9161218

Good Feeling: My First (Slightly) Major Open Source Contribution

Mar 23

Posted by Leif Andersen in Linux/FLOSS, Programming, Technology | No Comments

At my local university, it is spring break.  Which means that those long awaited projects that you’ve always been meaning to do, but never had the chance to do, because of the incredibly large amount of homework which you have, can now be done.  Three weeks ago, I promised the Blender Community that I would create an OFF exporter and importer.  Mainly because I needed to learn about the blender architecture, and because it was a simple project that gets neglected.  Well, I finally got a chance to submit it, well the exporter anyway.  You can find it here.  It was an interesting experience.  While I love blender as a tool to do 3d art, I find that the python IDE, it is lacking.  However, the really sad part about that is that it is the best python IDE that I have found, as I don’t like IDLE.  Also, using the blender python library (bpy) outside of blender would be a pain to make.  At least I am able to make the code window go full screen, and I can have syntax highlighting, along with several other nifty features.  Still however, I would like it to type into the text field, even when my mouse isn’t over the python window.  While it is nice that blender only types into fields when the window is in focus for every other feature it has, that is one where the opposite effect is proffered.  I am very happy with myself, and hope that the Blender Community will accept me as a student in GSoC.

Anyway, now I get to go build the importer, along with getting to maintain this exporter as the bpy API changes, joy.  Oh well, at least I feel accomplished.

http://wiki.blender.org/index.php/BlenderDev/Blender2.5/PyAPI_Intro

Tags: , , ,