Rendering WordWars on radiators

Qarnot Blender Interface

TL;DR: Testing the private beta Python API from Qarnot

About a month ago, while keeping an eye on the Libre Software Meeting (RMLL) in Beauvais and watching the news about WordWars spread on some blogs and magazine, I stumbled on a video presentation about open source software tools for animators and Blender 3D rendering using Qarnot (in french). And I was struck.

Qarnot Computing is a high performance computing service provider, which means they can do a lot of complex calculations, super fast, using a large amount of computers. This service, of course, is not new. For example, 3D content creators often use these external services, also called “render farms”. Some 3D renderings require a lot of computing power in case of complex scenes, long movies or highly detailed realistic simulations. And by externalizing that work to a large amount of processing power, this can be done at a fraction of the time necessary compared to what it would require on a single machine.

Where Qarnot stands out from its competitors is that instead of spending a lot of money on cooling and infrastructure, they decided use the excessive heat produced by those computers to maintain temperatures in private houses and buildings. So, instead of having one giant warehouse with thousands of computers that needs to be constantly refrigerated, they have installed a network of “radiators”, made of the same computers, in hundreds of private interiors. So no more energy is required to cool down the computers, the heat is used to make a home comfortable and no more horrible window-less farms either, the infrastructure is distributed across a city. Using this approach, they claim to have reduced the carbon footprint of such services by 78%. And I could not be more happy to test this on my own projects.

The next cool thing about Qarnot is that they provide rendering services for Blender. The Blender Foundation uses them for their latests open movie projects. They offer some free credits to test their services. And they are cheap too. All these were so many good reasons to give them a try.

My WordWars project uses Blender to render the daily war news from The New York Times into a movie that looks like the intro scene from StarWars. So every day, a new Blender file is generated and rendered. On my home machine, it takes about 1h30 to render but on my dedicated server, it takes up to 8 hours. And I’m running this project from the server because I want to keep my home computer for other things and its also not constantly up or connected. The server, well, is up 24/7. So I decided to contact Qarnot.

I needed to get in touch with them, because so far, the only way to launch a rendering using their system is via a web interface. It’s really practical for a one time project, but having a file that automatically updates every day needs a different approach. I do want to keep things automated. So I asked if they had any API, any way to interact with the rendering farm via scripts. And as a response, I was happy to get invited to test their Python API, still in private beta.

They provided me with the necessary Python files, documentation, and a small, but feature complete, example that I could start with. It took me a while to figure out how to operate it correctly though. Maybe because I never interacted with a render farm before or maybe also because I got a bit confused with some of the parameters and the limitations of the private beta.

One thing that I found confusing was the ‘framecount’ parameter. The ‘advanced_range’ indicates which part of the movie you want to render but I did not understand, at first, how this related (or not) with ‘framecount’. ‘framecount’ is also named ‘frame_nbr’ in another function (‘create_task’) and that also puzzled me for a while as what this variable really represented. After testing different approaches, I understood ‘framecount’ as being the maximum number of frames that you want to process at the same time (the whole point of speeding the process of rendering). I say maximum, because it “feels” different depending on the amount of processing power available for the task. And in the end, the whole range of frames you want to render will be rendered, it might just take more time.

As this is still private beta, I could only get access to some of their processing power and was limited in storage space for the resulting renderings (limitations that you don’t have normally). So in the end, I could only run portions of my project − 300 frames per task − and that would take around 10 minutes to process (rendering the whole clip would take a little more than an hour using this method). So I’ll keep all these as tests for now and wait for the public release, which they should announce by the end of this year. Testing the same render (full power) using their web interface, the whole clip was rendered in less than 10 minutes. And the cost for the service would be around 0.75€ for that particular case.

So using Qarnot, I could be delivering a WordWars video clip, 10 minutes after the news have come out, at an affordable cost of less than a euro and without feeling guilty by double heating the planet.

I’m also guessing that, since the Python API they provided runs under Python 3.4, you could also expect a Qarnot-plugin that will integrate directly in Blender interface. And if they are not the ones to create this, someone will do it for sure.

I want to thank them for allowing me to test this and the patience they took to respond to the many questions I had. I also wish them success as this is truly an inspiring way to create a computing company.

Ma collection de portables timbrés

Instagram de laptops avec autocollants

Dans tous les brols que je peux alimenter sur le web, il y a entre autre, ce compte Instagram, démarré à Leipzig il y a un peu plus d’un an. J’y collectionne, au gré de mes balades, des couvertures de portables couverts d’autocollants, une pratique assez répandues chez les bidouilleurs informatiques.

On a déjà comparé le mien à une planche de skateboard. J’y vois surtout l’envie de personnaliser un objet de masse dont la couleur dévie rarement de la palette chatoyante d’un ciel du plat pays. C’est peut-être aussi une forme de tatouage tribal, de rite de démystification de la machine, ou le besoin d’apposer son tag, sa marque, celle de ses chouchous, de balancer un slogan et d’y donner une plastique qui peut-être découragerait un voleur.

Un grand doigt dans l’oeil d’Instagram, royaume de la jolie photo, pour m’avoir obligé à créer un compte alors que je voulais juste accéder à ses données.

Et comme le dit Wily:

Collaborative tools for designers − part 5 : Adobe Creative Cloud

Adobe Creative Cloud App

Episode 5 already. Damn, so many collaborative tools for designers. Yes. And this post is about the one everybody talks about, but what they are actually referring to is something else: Adobe Creative Cloud. Let me rephrase that. When you tell people you are trying out Adobe’s cloud, they think you are using Photoshop or something. They don’t picture that what you are actually studying is the file hosting and syncing with Adobe’s servers. You know, the thing that works like Dropbox. Well, unless I’ve badly searched in the giant list of Adobe’s applications, the only tool they advertise doing collaboration and versioning, is Adobe Creative Cloud. Yes, the syncing app with the “real” cloud. No, not Photoshop. Your files, on their computer. You get it.

And don’t tell me it’s called Adobe Version Cue. Has anyone ever used this? I tried. A long time ago. And did not manage to make versions of my files with it. So I abandoned. And so did Adobe.

As I flew away from Adobe products since the first Creative Suite versions, I really thought that people were actually using the “cloud” services from Adobe, so I was surprised to hear none of my friends were actually using the 2Go of “free” hosting offered with their subscription. So to complete this review, I asked some friends if they wanted to test it. Sébastien Monnoye, teacher and designer, who also had never pushed files on the Creative Cloud before, answered the call and we started sharing folders together and explore the tool.

AdobeCC Hello World

One thing for sure, and you guessed it, is that it treats Adobe’s file format very well. The rest, not that much. You can, of course, see a preview of .psd and .ai files in the browser. But you can also break down that preview by turning on and off the individual layers for those files. Neat. With a click of a button you can extract certain elements from a .psd or a vector file and add them to a library of assets. These libraries are accessible right from inside Photoshop or Illustrator. So you could just drag and drop from those into a new design. It really speeds up the reuse of certain elements you might have made in your previous projects. (They also propose to buy and download existing libraries of assets. But I did not look into that too much or how you could submit your own designs.) And lastly, for all the elements in a design that you can select, they show you what are the CSS rules you need to write to have that same element behave the same way in a web page. Kind of nice. Especially for positioning.

Positioning from Adobe Creative Cloud

So, for every (adobe) file you upload, you can see some meta data, quickly access the major colors present in the design, leave comments for collaborators, extract assets, share the design on Behance and see the previous versions of the file. But don’t expect a reliable versioning system here. After 10 days, old versions are trashed.

After 10 days, we delete the past versions from the servers. If you know a version is going to be important, we suggest you make a copy of the current file you’re working on and save it with a new name. Then restore the original file back to the revision you care about. This way both copies become their own unique file that won’t be deleted automatically.

10 days is… ridiculous. And the solution proposed here kills all the benefits of using a versioning system. So let’s call this a short term memory backup, shall we. Nothing more. Why would you want to come back to a previous version of a design after 10 days, right?

Anyway, now on to the weird parts.

You know unix’s philosophy: everything is a file. Well, in the Adobe cloud, everything is an image. And if it’s not, it’s a blob. So yes, any .doc or plain .txt file is rendered as an image… Making it − if not unreadable, at least − unusable. HTML, CSS and Javascript are blobs. No way to see what’s inside them from the web interface. No versioning either (sorry, short term memory backup) for those. I’m not making this up. This is super strange. Adobe has a long list of tools related to web design, but displaying code in a web interface and versioning it, why would you want that, right?

AdobeCC file viewer

In the little application you install on your desktop, you get real-time notifications when a collaborator leaves a comment, but they don’t tell you which file has changed and who did the changes. So apart from the comments, the app is just there to do the syncing and let you access the Adobe market for apps, fonts, stock photos and assets libraries. You can also see a preview of what’s trending on Behance. (Mmmh actually, there is a way to see which files have changed, but good luck on finding where that is. Tip: it’s not in the notification window.) So to sum it up, this is more like a market place for the Adobe products than a tool to communicate and collaborate, as I thought it could be.

I’ve only tested graphic files. More tests could be made with InDesign files, Premiere, After Effects or Flash. But I’m kind of focusing from a web designer point of view. So I also tested some other file types: .odf (Libre Office), .xcf (Gimp) and .py (Python) and unsurprisingly, they are all treated as blobs. With SVG, it’s a special case.  They all are rendered correctly, but the features you can have with them are very different if you have saved them from Illustrator or from Inkscape, for example. The latter having the less feature, of course.

To wrap up, I’d say that the tool to extract assets is really a nice productivity improvement, but the syncing and collaborative features are behind what Dropbox is proposing. And since Dropbox just acquired Pixelapse, they really aim at offering an even better experience to designers, if they are not the tool of choice in that field already. Adobe is forcing its tool on everybody, of course, because you need that little app to install the Photoshop and others, but they need to polish it a lot more to get the designers to give them their files. And I don’t think that the “Publish on Behance” button is really a key here. But lets see how that evolves over time.

Collaborative tools for designers: part 4

TL;DR: Tools I will not review and why.

Three weeks ago, I started a series of publications regarding tools that encourage collaborative practices for designers and that use some form of versioning at their core. You can read the previous chapters and especially the first one to understand what I’m looking for (links to part 2 and part 3). In this fourth episode, I’m just going to list tools I will not review thoroughly but that I felt I should mention because they exist (or existed) for certain reasons. If you have experience with some of them, I’d certainly be happy to hear about it.


Used by blockbuster media companies (such as Rockstar Games or Disney, for example), it’s a complete project, team, assets, source control management solution aimed at very large studios with hundreds or thousands employees and its apparently great at handling large (sets of) media files (at least, that’s how it was once presented to me). The licensing fee are relative to that description. It’s worth noting that the latest presentation of Perforce Helix mentions the integration of Git for the developers in the team. Maybe worth watching is this video showing how to handle their image diff tool.


Although, like Pixelapse, I had them on my watch list, I never took the time to dig deep into their product. And unfortunately, as I understand it from the description on their website, the company went bankrupt 6 months ago. Too bad, when you see Kelly Sutton present their product just 2 years ago, it looked very interesting. Their “wormhole” tool (at 6:00) is really a nice approach to get “what changed and when” in an image.


I hesitated for a while. Should I review this tool or not. They call themselves “The world’s leading prototyping, collaboration & workflow platform“, and looking at their client portfolio, they surely can pretend to this, I guess. But they focus mainly on screen based media and interactivity, or so it seems. and their level of version control is no better than Dropbox or similar. So the designers targeted here are “application” designers, UX/UI designers,… and I’m looking for a a less opinionated tool. Anyway. If you want to get a quick glance at what this tool does, here’s a quick introductory video. Certainly a great tool to review designs, manage projects & teams and test user experience. Not what I’m looking for atm.

Visual Culture

Visual Culture is a server software developed by Open Source Publishing to visualize git repositories. Since their design practice involves doing things open and in the open, their website runs on it and allows the visitor to browse into their latest projects and how those are made. Their intention was to turn it into a general tool for designers and they opened a crowdfunding campaign to achieve that goal, but this did not received enough support. I did try to install it and see how I could use it on my own projects. With the help from Colm, Stéphanie and Eric, I passed through a couple of bugs and misunderstandings on my part. And I could see a recap’ page of what I had in my folders. Unfortunately, that’s how far I managed to go. I lack some Django knowledge to adapt the necessary bits so it would behave nicely with my projects as, at this stage, Visual Culture is still very closely knitted to (how) OSP(‘s) work.

visual culture on my repos

Come back next week for another chapter.

Collaborative tools for designers – Part 3 : Pixelapse

Reviewing tools for collaborative practices and version control for designers, this is episode III. And to my surprise, I’ve discovered Pixelapse, an online tool that promises to do just that.

Pixelapse Homepage

It’s been a while since I had found about Pixelapse, but never took the chance to study it deeper until last week. Mainly because they require to install some software that only works for Mac and Windows. And since I use Linux, well…

So I borrowed a Mac without much luck either. Pixelapse software requires Mac OSX 10.7 and higher. The Mac was running on 10.6. I know designers have usually high end machines with latest software installed. But no Linux support and only a recent OSX, that’s 2 wall hits for me before even starting. But anyway, solved this by installing a Ms Windows running in a Virtual Machine under Linux because I really wanted to see how their tool worked. A pretty big setup just to sync files and not practical in the long term, but for the love of testing, it was fun enough.

Basically, what you are installing is a synchronizing software. Just like Dropbox, it creates a special folder on your machine, where you will keep your files synchronized with their servers and with the other computers you share that folder with. The other computers could be yours or from the designers that you want to work with. Apart from that, all the features proposed by Pixelapse run in the browser. Well, not every browser. Seems they only fully support Chrome. Internet Explorer is a no go and I don’t blame them for that (I tested IE11 only). Firefox seems to work ok, except for the “image inspector”, and that’s a pretty big feature being broken for no apparent reason.

visual comparison

About the features, they have really though it through. You can see their service as being between a version control, a project management and a reviewing tool. You can define roles for each projects, invite “clients” to review your graphic files and comment on them, or have collaborators with {full|limited} permissions. They support a wide variety of file formats for preview (mostly Adobe stuff), but also open file formats and even .xcf (Gimp files), although the latter did not render text properly. Version control is basic (no concurrent versions and they don’t allow custom naming your versions, so you’re stuck with version1,2,3,…) but at least they allow you to rename and move files around without losing their history and you can flag “milestones” in your project’s history. They also allow you to visually compare files or file versions in different ways. Commenting and reviewing design seems pretty well made, Although I could not test it on an actual project or with a team as I don’t know anyone who’s using this tool.

So my overall feeling is very positive, but something is bothering me.  Apart from the fact that it’s not open source, not working on all systems and that you have to trust them with your files, why did I not hear of them more? If I had to do a comparison, I’d say this aims to be the Github for graphic designers, but why don’t I see more of us use it? As a matter of fact, I will definitely find more graphic design projects on Github than on Pixelapse. Why is that? They do allow public projects for free accounts. They encourage in their communication to do open source design projects. They feature some on their homepage. But after going through what was available publicly, I did not see much collaboration going on (Googling through the website, I found one public project with 8 participants.  But can’t figure out if there was any collaboration at all. And then this UFO, which seems to put to good use the features proposed, but I’m wondering if this was really meant to be public). I know it’s a young service (2 yo), but Internet is pretty quick to embrace a pretty good idea when it sees one. Where is it not catching up?

Pixel diff between two versions

I don’t have a definitive answer, but my feeling is that the interactivity is a little oversold and that it unfortunately still enforces the digital divide between coders and designers.

This tool is for graphic designers only, coders will not feel at home. Yes they support the viewing of some code files (HTML, CSS, JS), but without line numbering and a basic text diff tool, this is useless, even scary. Also, why not support other languages like, Ruby, Python or Bash scripting? Where is the problem with that? There are some good ideas : like having a file and a cover image at the root of your project to automatically create a nice presentation page for your public projects. But then, without a proper way to see what changed in your markdown syntax, this becomes a little awkward to use.

Designers of pixelapse

The navigation has problems also. Exploring public projects is a pain. There is no search bar. You can add tags to your project’s description, but it’s like they forgot to implement it on the backend. No way to browse based on project type or keywords. No way to see the latest activity on the site resulting in no sense of community. Seeing the public projects they feature, it feels more like Behance − or any portfolio you can name − than an “Open Design Movement”, as they want to call it.

The interface is also a drag sometimes. It’s using animations here and there and this makes it all a bit clumsy. I want my tool to be fast and to the point. Animating between a thumbnail view and a list view of my files is not something I find important or informative. I wish also that space would be used more efficiently. The whole window is used when previewing files, comparing and reviewing them. And this is a good thing. But why do I feel that so much space is lost when I’m navigating folders and projects. Why not have the full screen used also for that too? I also found myself clicking a lot − where there was no button − expecting something to happen. At other times, I was completely lost and had to go back to the main page to start again.

Too much white space?

Maybe it also tries to embrace to much. Working with clients is not the same as working within a “private” team and not close to working with strangers on open source projects. Keeping designers distant from coders is a also counter productive approach in my opinion.

The good news (or the bad news, depends on the point of view, I guess), is that Pixelapse has just been acquired by Dropbox. So it could mean that Dropbox will improve or that Pixelapse will support more operating systems. I’m guessing Dropbox is interested in the visual reviewing tools since they’ve just started introducing a commenting system for their files. As for the future of Pixelapse, Here’s what they have to say about it:

Will Pixelapse continue to operate?

Pixelapse as a standalone product will continue to be available and supported for the next year as we work towards bringing the same kinds of collaboration and workflow experiences that you’re used to in Pixelapse over to the core Dropbox product.

That just sounds to me as “good bye and thanks for all the fish”. I don’t expect Pixelapse being updated for the next year and have not seen a post on their blog or twitter since the Dropbox announcement (and that was 6 months ago).

There is a ton of good ideas in Pixelapse. But it needs polishing and a different approach  regarding their community if they really want to be the repository platform of the “open design movement”. So for me, I’ll just pass and move on.

Collaborative tools for designers – Part 2 : Dropbox

rip dropbox

Last week, I promised I would be exploring some of the tools promoted as helping designers in their revision control and collaborative process and that I would do this by comparing them to a list of benefits I extracted from my use of Git. So in this post, I’ll be reviewing the (in-?) famous Dropbox.

As a foreword, I have to tell you I don’t use their service. I was forced to have an account, when some friends and coworkers wanted to share some files with me, but I never liked the idea of having my draft files on a computer I did not own. I use some third party services to share publicly some projects, as you will find on Github, for example. But by default giving to a stranger a work in progress, some first sketches or an unpublished project, is not something I find comfortable. How good or easy the service could be.

So as a start, this rules out the use of Dropbox if you work under an NDA, have company secrets or just care about the keeping your working process to yourself or your collaborators. But let’s analyze what they offer and see how that helps designers or not.

First of, it’s an easy set up. After a necessary software install, sharing a project between collaborators is as easy as moving around a folder in a file explorer. It’s also “operating system agnostic” as it will work on Mac, Windows or Linux and even Android or iOS. And if that’s not enough, there is always the web interface to rely on. Actually, the web interface is where most features are built in. (I’m testing this from a Linux computer, but I guess it behaves similarly on other systems).

On the “workstation side”, there is not much more than moving around files, renaming them, and modifying them with your software of choice. It will then synchronize those changes automatically with all the computers you share that folder with.

On the “web side”, Dropbox offers you some form of “versioning”. Everytime you save your file, Dropbox records a change. You can go back in the history of those changes in the web interface and see who made them, from which machine. But unless you know what changes where made and when, there is not much more info given.

dropbox file history
See for yourself, that list of versions is not that useful. If I did a mistake and saved over my file, I could use this to immediately revert to a previous version. But come back to that a week or a month later and who knows what’s hiding behind “version2″. If the file type is supported by Dropbox, I can see a preview by clicking on the version name in the browser. If not, I’m presented with a download button and have to open it on my computer. If somehow we could add a comment or a note with each version, that would improve this a little.

Also, there is no way to compare different versions (even if it’s a plain text file) except by viewing each independently − opening multiple browser windows − and figuring out for yourself what might have changed. Forget also about having different concurrent version of the same file. You’ll have to create different files for that and you’re back to your weird naming scheme. And if you rename your file or move it to a subfolder, your going to be losing all its history. Really? How useful is that?

So this revision system is more like a notification system of who worked on what and when, than a reliable way to store your changes as this can be wiped out by just renaming a folder. It does not help you get organized either. And I found the links in the “events” page confusing and practically useless, especially if you have a lot of files and subfolders in your main shared folder. (see screenshot below, all these files are located in different subfolders in a master folder called “libre-objet”).

dorpbox events
(For some reason, I notifies me of changes on some these files, but when I’m clicking to view the history of it, it only says “version1″. Was the file renamed at some point, or the containing folder, or because those modifications were done before the folder was shared with me,… I have no idea. But how can I trust this?)

I did appreciate though that I could get a 1:1 preview of some files like SVG, Tiff, Jpeg, png, ai or psd (I did not review all the possible files formats). That 1:1 preview also features a commenting system, where you can tag collaborators. But I did not see any tool to annotate a design for example. Maybe that’s coming… who knows.


It also shows a little thumbnail for some of those file types. That’s handy. But this is also something I get in my file explorer on my computer, so where is the added value here? Why not also have those thumbnails in the history page next to each version, or in the event page also? That would be a little more helpful.

As a conclusion, Dropbox is maybe, for most, an easy way to get a shared folder on many different machines but it can not be trusted. Neither on the conservation of files, nor on keeping a history of changes. If you don’t care about “versioning”, you’ll be better of with alternatives, such as BtSync (closed source) or SyncThing (open source) and all the other self-hosted “cloud” application suites.

I know I’m killing down here a great service for some of you. And Dropbox never pretended to be the git (or github) for designers, even if they seem to be heading in that direction somehow. But their versioning system is a joke. And I’m looking at all of this from a very particular point of view. Please, don’t hesitate to share your designer’s experience using Dropbox in the comments below, I’ll be happy to read it and it might help me understand parts I could have missed. Again, I barely use the service. And if you enjoyed this post, come back soon for part 3.

(Cover photo by Steven Caddy released under Creative Commons by-nc)

Collaborative tools for designers – Part 1

Soyuz Cockpit

Since I’ve discovered and used distributed revision control in my day to day practice, I’ve been amazed by how much it has helped me getting more organized, stop worrying about loosing files and also encouraged me to experiment more and thus try more options in my work. And I’m not even talking about how it eased the collaboration process with other designers and coders.

But one of the major drawback is to convince other people to use it. Convincing someone who codes already, or who is not afraid of typing commands in a console, was easy. But talking just pure GUI fanatics to jump into it, is a bit harder. And for a good reason. The tools needed to manipulate the usual revision control systems are mainly designed for coders. Yes, there are some GUIs (I don’t use them), but they look like a spreadsheet or a Soyuz cockpit. And that barely helps make sense when you are looking at the type of projects that graphic designers have to cope with.

So, I’ve been trying to put my head around this problem and come up with solutions. I had a first try at it with a project called “Design with Git” that I had the chance to develop at Medialab Prado, Madrid in 2013. But this was just a beginning, a short-time experiment, and although I’ve spent energy applying to other residency programs to continue on building it, I’ve yet to find a place that would allow me to dedicate some time improving this concept.

So, since this subject is not dead for me and for a lot of others, I’ve decided to start a series of blog posts, in which I would clear my head out and put into words and graphics my thoughts around this subject. And as a start, in the coming posts, I’m planning to review some available tools for “revision control” and collaboration between designers.

A word of warning here, maybe. I’m biased by my experiences, of course. And so far, the only version control system I’ve used extensively is Git. When I started being interested in these kind of tools, I got my hands on CVS, but then Git (and Github) quickly became the trending thing and I drank the Kool-Aid. Also, CVS needed a server, and that was too much to set up for me just to manage my own projects. I’m not a Git-guru either. I use it, almost daily, for almost all the things I produce. But I’ve not gone beyond the basics of cloning, branching, diffing, pushing and merging. When I have to do more complex tasks like going back to an older version of my files or completely erase a file from history, Stackoverflow is my friend.

So here is a list of what I find useful when using Git with my projects:

  • It allows me to view a history of changes, which files have changed and a written description about it (status / log)
  • It allows me to easily make different versions of the same project and to quickly switch between those versions (branch)
  • It allows me to work with an undefinite number of people (clone / fetch)
  • It returns precise and valuable information between the changes or different version of the project (diff)
  • It allows me to integrate the changes made by another person into my own project (merge)
  • It does not require a complex setup to start using it (init)
  • I do keep my folders tidy as I don’t have to invent complex naming formats for my files (No more Front-cover-v4a-TOPRINT2-validated.pdf)
  • It allows me to view the contributions of each participant on the project (log)
  • I’m not worried about loosing a file, erasing or writing over my previous work.
  • It eases the process of working with developers because we are sharing the same tool to keep track of the project’s advancement.

This list, I think, sums up for me what are the main benefits of using a distributed version system such as Git and these are the benefits graphic designers should get from using it also. The catch is this works well when you’re dealing with code or text files. But some points here are a little or very problematic when it comes to dealing with design files. Hopefully, there is some solutions or things that can be adapted. And I believe this is possible while keeping Git at the core of the process.

But before going further into this development, I’m planing to explore some of the tools promoted as helping designers in their revision control and collaborative process and I’ll do so using this list as a frame or a grid of evaluation.

So see you next time. (go to Part 2)

(Cover image: Soyuz cockpit by Christopher Michel under Creative Commons Attributior 2.0)

Making of “Word Wars- News from the Empire”

Sharing here my thought and tool process that brought me to create the project called “Word Wars – News from the Empire“.

Word Wars Blender Scene

I’ve been playing around for a while with Blender scripting and even organized monthly workshops about it to share the experience with other artists in a group called “Blender-Brussels“. And since the beginning of these workshop sessions, my goal was to turn one of these one day projects into a daily video generation tool.

Then last month, while preparing the class I gave to a couple of artists in New York city, I started writing a small example script that would grab some text from the web and turn it into a 3D object inside a Blender scene. And while playing around with the script, the idea to turn this into a very resource hungry news reader came to me. Basically, from then on, the rest followed.

As a Star Wars fan, I’ve always been puzzled by the countless memes and reinterpretations it has generated. It somehow reflects how Hollywood culture can really take over our imagination and even become the mythological stories of our western society. But it also portraits Hollywood’s fascination for war stories, an important part of U.S. culture in general. I can’t think of any other western country where the war hero is so present in politics and everyday life. But again, when you know that the U.S. has almost constantly been at war since it’s creation, this comes with no surprises.

So it became clear to me that I wanted to address these subjects in a simple and buzzworthy manner. Following the path of the YES MEN, I chose The New York Times as my only source of war news.

Practically, the whole project consists of a prepared Blender scene, with a starry night (I’ll come back to that later), some placeholder for the texts, a modified Star Wars logo and the “Main Title Theme” music by John Williams.

Then I have two Python scripts. One that fetches the RSS feeds from the NYT and filters the news searching for war related keywords. If at least one article is found, it will add the text to the scene and modify the animation keyframes (because I do always want to have the text start at a certain time and vanish into the infinite emptyness at another particular time also) to fit with the music. The first script finishes by rendering the clip. The second script takes care of the uploading to Youtube, adding the title and filling the description.

To get the feeling right, I studied carefully the original intro from the first Star wars movie. The dedicated wikpedia page helped me also figure out some of the things, but in the end, I took some creative liberties that maybe only a hard core Star Wars fan would notice.

The original font used by Lucas is the “News Gothic” by american author Morris Fuller Benton. But since I’m a big fan of open source fonts, I preferred to use “News Cycle” by Nathan Willis, also an american author and − full disclosure − a good friend. The font is similar to News Gothic and fitted perfectly for the job. Using it, I was also happy to promote his excellent work in the open font world.

For the logo, I downloaded the svg version of it from Wikipedia and searched for amateur SW fonts for the missing characters (O&D). In the end, I found myself redrawing almost all of it, point by point, in Inkscape, until I reached the desired look.


For the music score, it quickly was out of question that I would try to find a replacement for the original score by John Williams. First, it’s so iconic − the music is a meme in itself − that it would be pointless to find a remix or a different version of it. I really wanted to keep close as much as possible to the real feel of a Star Wars intro, and well, can’t do without John and the brass from the London Symphonic Orchestra. Second, if you worry about copyright issues, there is two arguments that made me stick by this choice. One is that, since I was uploading to Youtube, I knew they would let me use the music but would also certainly pay the necessary royalties to John for me. Then, if anyone still complained, I could certainly make a case, with all the clips and remixes you can find online, that the song could be considered as public domain. (I know that last argument is a bit too far fetched, but there should be a case like this in copyright laws.)

Then for the star field background, I wanted to pay my respects to those fans scrutinizing every official Star Wars trailer looking for a detail or a key that would unlock a piece or a new character from the coming movie. So I searched for the real star field that you can see from earth and found it from Paul Bourke’s page, luckily in a very high resolution. Since there was no license mentioned on the page, I contacted him by mail. Here’s his response:

No license … go wild.
Acknowledgements welcome.

I could not be happier. Adding this little detail, that until now I (guess) was the only one who could see it, for me, really tied the whole project together. It’s subconscious to the viewer, but s/he is watching those flying vanishing news from earth.

After all this, I polished the scripts a little, moved it all to a small dedicated server, cried a little when I saw the difference in rendering times between the server and my desktop, reworked the scene to pre-render the parts that never change, gained a couple of hours, then patiently waited 20 days (for 20 videos to be generated) before releasing it to the public.

For those interested, you can download the project files from this repository. Feel free to use and modify as this project is released under a Free Art license and let me know if you make anything of it.

And while I was writing this post, Youtube announced me the latest video, “Episode XXVII”:

“moDernisT” et le fantôme du MP3


moDernisT” a été créé en récupérant les sons et images perdus lors de la compression en mp3 et mp4. La bande sonore est composée par Ryan Maguire à partir des pertes dues à la compression du morceau “Tom’s Diner”, de Suzanne Vega. Ce morceau n’a pas été choisi par hasard puisqu’on appellera plus tard son interprète “la mère du mp3“. En effet, Karlheinz Brandenburg, l’inventeur du mp3, a utilisé ce morceau comme référence pour paramétrer son algorithme.

La vidéo a été réalisée selon le même principe par Takahiro Suzuki en réponse à la piste audio, mais à partir des pertes d’image du clip en compression mp4. Les deux fonctionnant donc comme des “fantômes” de leur versions originales compressées.

Les petit(e)s malin(e)s auront noté que la version présentée dans ce clip Vimeo est compressée également. C’est pourquoi Ryan Maguire propose d’acheter le morceau non-compressé au prix que tu veux.

The Ghost in the MP3

Merci à Vinz pour la découverte.

Dessiner contre une fourmi


Un petit jeu de dessin avec l’aide involontaire d’une fourmi. J’ai tendance à penser que c’est un petit peu cruel, mais en même temps mon esprit pétille à cette possibilité créative.

Quando il limite è soltanto una questione mentale :)

Posted by Blogo on Saturday, June 27, 2015

Si la vidéo ne s’affiche pas, le lien vers la video est ici.

Via Milady Renoir.