We're happy to announce that we have now succesfully turned a page and finished the complete update of our server back-end. It was a rather gruelling task that took nearly two weeks to finish, but it brings us many of the improvements that we talked about with Jesse at this year's Blender Conference presentation:
Nathan explains in detail:
For some longer time we've been thinking of upgrading our back-end version of BURP to the latest. For our admins it brings some very important updates and improvements for managing the sessions that are running on the farm. We had scheduled to start the upgrade of the backend on December 20th, Janus had also promised to be available if any big issues would pop up. I had already prepared the development image we use with the latest BURP code and compiling it into a WAR-package was simple enough.
Jesse started the process by kicking off a Gentoo system update. Not very long into the update a fatal compile error got our hands all sweaty, as it told us that libc was completely broken. Fortunately a rerun of the update fixed this, but it also made sure that our adrenaline levels climbed high.
After initial deployment of the latest WAR-package it became obvious that some fixes on the farm were needed, especially where our frontend communicates with BURP. Fortunately a new XMLRPC API made the changes fairly easy, although on the other hand it was a break away from the old API we had in used (created last year by Olivier Romand). It took quite a while to get all the correct parts tied into each other. To be honest it was harder than initially expected. Jesse and Janus did most of the Apache/Tomcat configuration, while I continued working on the Uploader.
Then we ran into some mysterious problems. It turns out that the long type isn't officially supported in XMLRPC, and I had to spend some time on figuring out a working solution. The first quick fix provided by Janus worked, but not in all situations, and there were still places where long was being used.
I added some missing XMLRPC API to make sure the Uploader could be updated correctly too (the improvements will be committed to bf-extensions SVN soon). Just today the final few fixes (overlooked accidently yesterday) were made, ensuring that the service is again fully up and running! So, update of BURP included updating: Gentoo, Tomcat, Apache config files, fixing BURP XMLRPC code and the glue between our frontend and BURP.
Now that the update is finished and we're back to rendering, we can start focusing our efforts on making the new functionality as accessible as possible. We are planning to do this gradually by first testing their functionality with some actual production cases. Apart from this we'll have to also give consideration to how we will grant the right to use some of the features as they are potentially resource hogs (such as OpenEXR rendering, which can take tens of megabytes of storage per finished frame).
Apart from gaining some awesome new features, we can also put more effort into enabling Cycles support on Renderfarm.fi. This is turning out to be the single most requested feature in the farm's history. We hope to run preliminary tests in January, with at least limited support by February. Full implementation, as how we see it, would be a kind of a bucket rendering method which would enable amazing Cycles renders to be done in a completely distributed fashion. Let's cross our fingers the method we're putting our money on will work out!
Finally but not at all least importantly: We wish you all a Happy and Renderful New Year 2012! :-)
The Renderfarm.fi posse for 2011: Julius, Jesse, Nathan, Janus, Eero & Davis
“When Thom decides he’d rather be awesome in space than keep dating roboticist Celia, he never imagined he was planting the seeds of Earth’s destruction. Twenty years after this tumultuous romance he has to go back to the Amsterdam scene of his breakup with Celia to save the world. But are a high-powered robotic disguise and a time traveling battle fleet enough to fix a broken heart?”
So we do, in fact, already have a script! For a month or so, actually. As always, it’s impossible to know how much of it will make it through to the final film, but it’s a good start! I was looking at David’s concept art the other day thinking, “If we make a film that looks as good as this, I’ll be more than happy.” But man- after the whole team puts 6 months of work and imagination into it? This thing is going to be even more incredible. The best thing about this project is going to be all the layers of ideas; it’s already happening.
This project was interesting in that as opposed to only developing the technology to enable the story, we were also trying to draft a story that would help develop the VFX pipeline of Blender (most obvious examples: Awesome Motion Tracking! Keying! Stuff like that) And beyond that, almost everyone had lists of stuff they wanted (or expected) to see in there: giant robots, monsters, large-scale destruction, environment augmentation, space ships full of invading aliens (or Nazis?)). My personal criteria was a bit more general. Mango would have to be fun, visually impressive, meet the targets*, and have an emotional core somewhere**. I think as long as the audience is given a simple relatable plot to hold onto, they’ll be more secure going along for the ride into the crazy world we’re creating (That was also the element for me that differentiated between an actual short film, and just an awesome tech demo) .
“But! But but but!” you say, “Mango is supposed to be ‘No Story! Maximum Impact!’” Mannn, I feel you! But you can’t have maximum impact without some sort of cohesion between shots, and you can’t have cohesion between shots without incidentally creating some sort of story! But the thing we won’t do is bog the whole thing down with a convoluted plot and exposition.
Things move swiftly onward!
* Although, it’s… uh… not gonna be 3 minutes.
** Don’t worry- Mango will not make you cry (and if it does, I am not sure how that happened?)
I’ve compiled a list of the most popular posts on BlenderNation this year. While it may miss some events, it certainly gives a good impression of 2011. Enjoy! 10: Cleaning up the Blender UI There’s no better way to get … Continue reading →
The dual-contouring remesh modifier is now in trunk. This modifier is based of code contributed to Blender by Tao Ju back in March. It implements the algorithm described in his paper “Dual Contouring of Hermite Data”.
The general purpose of the modifier is to generate a new surface that follows the same shape as the input, but with more regular topology. The output of the modifier is all quads, and they are “nice” in the sense of not getting too skinny or irregular density, which should be useful for sculpting. The modifier also has some other interesting effects, such as removing small disconnected pieces, filling holes in the mesh, and outputting blocky remeshes (as with the purple and blue Suzannes in this post.)
Big thanks to Tao Ju for his contribution!
Thanks also to users who come up with designs for the modifier’s icon, and in particular to Zafio, whose icon is now the remesh icon. And another thanks to Sergey for reviewing the code. (Blender at its best: everyone else does the hard work and I just push the big red commit button.)
Documentation and examples are on the Blender wiki, check out in particular nice example videos from Roberto Roch.