The Unctuous Rants of Leif Andersen

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

Posts Tagged linux

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: , ,

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: , , ,

VLMC, a Preliminary Look

Jan 3

Posted by Leif Andersen in Linux/FLOSS, Technology | 1 Comment

I recently talked about VLMC, or VideoLAN Movie Creator, a movie creator based on VLC, or VideoLAN Client, one of the better media players in existence.  I talked about how it might be the movie maker for Ubuntu Linux, you can read more about it here.  Since then, I have had a chance to test drive VLMC, in order to give you a review of it.  Keep in mind, this is just a preliminary review, many features, layouts, and bugs, will change.  If you want to install VLMC for yourself, be prepared, while it is certainly doable, be prepared, it’s not an easy thing to do, that is, unless you enjoy doing this sort of thing, or have already compiled VLC from source.  Also, it is possible that I may have just gotten a bad build of VLMC, as when code is in such a young stage, bugs come and go very rapidly, and this YouTube video obviously has not had the same problems with it that I had.
Read the rest of this entry »

Tags: , , ,

VLMC, the Video Editor for Ubuntu?

Dec 24

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

The VLMC logoFor ages, ubuntu has been hurt by the lack of video editors.  Several years back, when cranky Ubuntu Forum goers were complaining about the lack of video editing software, I was always quick to point out Blender.  However, it had several problems.  First, it couldn’t capture film from a camcorder, meaning that you had to use a separate program to get the film off, I would recommend Kino.  While it worked, it still was a clunky solution, getting video in one editor, exporting it, and then importing it into blender.  The second problem was the raw power of Blender.  You would start it up, and see a 3d modelling program, not knowing that it was a 3d modelling, animation, movie sequencer, UV editor, physics simulation for particles, cloth, other soft bodies, audio editor (albeit a really bad one), game engine, and more.  Even those that stuck around long enough to get to the video sequencer, generally saw all the buttons, nobs, and switches, and ran.  And to be honest, I don’t blame them.  If I didn’t spend the time to learn blender several years back, because I wanted to do 3d modelling and animation, I would have run too. Read the rest of this entry »

Tags: , , ,

The Gadget Problem

Dec 24

Posted by Leif Andersen in Technology | 2 Comments

It has come, it has come, the time to buy new things.
Shiny, spiny, turny, clicky.
Not one, not two, not even ten to observe.
But more than one can possibly imagine, it’s absurd.
There’s phone, and there’s media players, tables, readers, and tablet phone beepers.
They have screens, they make noice, they go beep beep ring beep.
One costs a hundred, another costs two, together their price is more than Chum Choo.
You can’t have them all, but we’ll market them as such, saying this is a deal, with ten percent off.
I rush around amazon, ebay, and froogle, to find that my pocket book just can’t hold to its GET FREE IPODS NOW, CLICK HERE!!!
I don’t want them all, I don’t even want half.
I just want to run free linux apps.
I don’t need to make phone calls, but ubiquitous internet is nice.
There’s netbooks, and notebooks, PDAs, but I still need my textbooks.
And up to now, I’ve to mention, the plethora of software.
There’s android, and iPhone, Memo, Rockbox, WebOS, and too much more.
In the end, you can only have some, as there’s not that much money to be had.
But be sure, that in three months, your device, will be old and bland.

Tags: , , , ,