During the freelance work that I've been working on for the last couple of months I had to do a lot of long renders of animations. When I'm doing a really long render I tend to use the command line to do a 'background' render so that Blender's UI doesn't have to be visible (which apparently saves a bit of memory), and as with most things recently, that caused me to write an another add-on...

Before I get onto the add-on I'll take you through the manual rendering process I used to do. To do a 'background' render (more commonly referred to as a 'command line' render) you open up a Command Prompt (or something similar for non-Windows users), navigate to the Blender installation directory and use something like this:

To break things down, that's:

• 'blender' to run Blender.
• '-b' (which stands for 'background') to make blender run without the UI
• The path to the blend file
• '-a' to tell blender that you want to render an animation
  

If I want to render multiple files then I would create a Windows Batch file with the following commands (I've simplified the paths just so they would fit on the page nicely):

• 'CALL' which opens a program, followed by the path to blender executable to specify blender is the program I want to open
  
• '-s' and then a frame number, specifying the frame to start rendering from
• '-e' and then a frame number, this time pointing to where blender will render to
• '-a' as before, to specify that we're rendering an animation

I would then just double click the Batch file, which would automatically open a command prompt and start rendering.

To navigate to Blender's folder and open a command prompt or to create a batch file with the updated filepaths and parameters each time I wanted to render became a bit time-consuming - I wasn't even doing that many renders at that point - so I decided it might be worthwhile (and fun) to create an add-on with a UI to handle this for me. 

Out of the primordial code came:

Features:

• Can render multiple files
• Option to hibernate after rendering
• Ability to re-order batch render jobs
• Can generate batch jobs by specifying a directory of blend files
• Launches a Command Prompt window as a separate process to carry out the rendering, so blender can be closed once rendering has begun.

 

It's available to download from Github, here. One caveat is that at the minute it's still Windows only.

The 'readme' over on Github is quite extensive (and if I say so myself, quite excellently formatted) so head over there if you want to know how to use every little feature, and given the amount of time it took to create that 'readme', I really suggest you do.

'Batch Render Tools' also has a small secondary panel which serves as a shortcut for opening a Command Prompt in the Blender installation directory, which I also find quite useful:

Having got a bit of feedback regarding the fact the add-on is only compatible with Windows, I decided to try and invest a little more time into getting it working on other OSs by way of 'virtual machines' - a way of installing another OS and run it like you would a program, instead of having to install it on another partition. This task is what's known as a 'time sink'. That is to say, it swallowed up the time I threw at it and I got very little in return.

Linux wasn't too bad, I installed Ubuntu in VirtualBox without too many issues, got it running and very quickly found the code needed to make the add-on compatible on the OS. Hurrah. Hurrahing aside though - for one can only Hurrah so much before people start to stare -  that left me with OS X.

There would be no 'hurrahing' now. The time of 'hurrahing' had well and truly passed, which made me wish I'd made a bigger deal of that first 'hurrah'. I'd have cherished it if I'd realised that the lack of 'hurrahing would be so notable later on, in the post-hurrah, OS X era*. I was battling with a 'Hackintosh' - it's name entirely appropriate given the endless problems and workarounds needed just to get it running - and after several hours I was no closer to finding the correct Python code to replicate the functionality the other OSs had so readily offered me.

*I've said 'hurrah' too many times now. It doesn't really look like a word and I can't tell if I'm spelling it right, nor what it really means. Was 'hurrah' ever a word? Should 'hurrahs' be pronounced like 'hummous'. Is 'hummous' a word or is it 'hummus'? Do they mean the same thing? Have I just described time in terms of pre and post-chickpea-based dip? We'll literally never know, but at least I've distracted myself from talking about the god-awful virtual machines.

Eventually I gave up, but since then, because of the amount of time that has passed between sharing the add-on and this blog post being published, I have had someone contact me regarding the issue and offer a solution, so when I get a minute (read 'hours' and 'motivation') I'll attempt to adjust the add-on to also work for Linux and OS X.

If you can, avoid virtual machines. I would say "avoid them like the plague", but thinking about it, I'd rather take my chances with 'the plague'.


Ray.

P.S. I will concede that perhaps having only 5 sentences on 'hummous' is hardly a "Wonderful World of Hummous" as the title suggests, but ultimately I prize appealing alliteration over accuracy.

I've been working on a freelance project for the past couple of months, hence the radio silence. That work is finished for the minute, so I decided to use this week to finish up a few small projects before settling back in to regular work. One of those small projects was good, the other...

1. Identify a problem.
   
2. Make something that fixes the problem.
3. Realise you were wrong when you first identified the problem. There is no problem. The only problem is You.
4. Delete all evidence that you ever tried to solve the problem.
5. Write a blog post about it, nullifying point '4'.

While this is an excellent recipe for mild embarrassment and moderate time-wasting, if you really want to excel at 'Making things no one needs™' you will also need to post your solution to social media, first, lamenting the original problem and then again when you have 'solved' the problem. Writing a blog post about the ordeal is optional, but somewhat cathartic.

Said problem was that there didn't seem to be a way to select all the keyframes for a given channel in the Graph Editor in Blender:

But poor naive Past-Ray was missing something, but it would be a few weeks later until he found this out:

Of course, by that stage I had already completed the script, promoted it on Twitter and given myself a good ol' pat on the back for being so clever. Suffice to say, the script has now been relegated to a new folder called 'Obsolete Scripts'.

You have now got to the end of 'Making things no one needs™' and should be able to make things that no one needs all by yourself. Feel free to refer to this handy guide if you ever feel like you're in danger of making something useful.

It's a shame really, Blender used to be known for it's hidden features and tools that were only accessible by an obscure shortcut and I had been glad at the thought that those days were over, often frowning upon those outside the Blender community who still thought this was the case. "But everything is accessible through a menu!" I would mentally shout at them. Apparently not.

Maybe I should be looking at this slightly differently. Maybe it's because hidden features are so uncommon that brought about this whole event. Had I been used to features not being in menus I might have dug a little deeper into the user preferences and hot-keys to find it. Not being able to find it in an obvious place, to me, was a sign that it couldn't exist. Perhaps, just by chance, I have come across one of the few remaining hidden features. Here's hoping.

As for the second, slightly more successful script, 'Batch Render Tools', whose usefulness flies in the face of this guide, I think that deserves a blog post of its own as it requires a bit more of an explanation.


Ray.

It's been 4 weeks since I last wrote here, leaving The Internet to descend into madness as it tries to comprehend a world without regular blog posts from me. "When will the literary drought end?", The Internet cries into the dark. "When?!", it cries again, worried that no-one heard the first time. Fear not, I have heard you. The drought/darkness (delete as appropriate) is over. I have returned, albeit briefly, to quench your thirst for ramblings, quenches and of course, thirsts, or my name's not Ray 'The Thirst-Quencher' Mairlot*.

*I will continue to proclaim that is my name up to, but not beyond, the point of being asked to prove it.

While once my time was abundant, now, my time is taken up by (and I'm happy to say, will continue to be taken up by) freelance, but I did manage to steal a few hours away to work on a small script at the weekend. Or one of the weekends. I forget which one and it's not really important to telling you what I worked on. What I'm trying to say is, it's an extraneous detail that doesn't deserve to be expanded on. Let's just say a weekend and be done with it. Embrace the ambiguity.

The script I made is currently a standalone script, but if it proves to be worthwhile it will be packaged up to be part of Animated Render Border (my add-on on the Blender Market), upgrading it to its third and probably, final version. What always improves something? More of that thing! In this case, that means more render borders, ie, being able to set multiple regions of the image to render, instead of just one.

My test was successful as the image below shows; two borders are set using a temporary UI and then rendered into one image:

There are a few hurdles before I can say it will be definitely released, such as trying this out on larger scenes. Essentially, the script renders the frame twice and then*** combines the results, so if a frame takes a long time to build the BVH or do some volume pre-processing then any time saved by doing a border render might be lost by having to do this pre-processing twice.

***30th April! I remembered, that's when I made the script. Thank goodness. Anyone who was worried about the lack of detail before can now calmly recede from the depths of ambiguity, back into the comfort of specificity.

When will I get to work on it again? I don't know. Will I probably start another experimental script before finishing this one? Yes, it's more than likely. But, for now, it's back to having no time, which is really no complaint at all, because I can attest to the fact that getting paid to do something you enjoy is far better than not getting paid.

And with that, perhaps somewhat abruptly, the end.

Ray.

In my last post I noticed that the forearm models looked a little less than perfect. The forearms were one of the first parts of the model I made and originally I really wanted to make sure they conformed to the reference images I had. Coming back to them now, I think I made them conform a bit too much. Even though they appeared to fit the references, they were a weird shape when viewed from the top. I thought it would be better to reshape them to something more logical even if they didn't match the reference images as well:

As it turns out, having updated the models to a better shape, they do still manage to fit the reference images somehow. It makes sense that the more logical shape is the correct shape, so it's reassuring that the references seem to confirm that.

I have a slight worry that this project is a bit like 'Painting the Forth Bridge', in that once I finish one part enough time will have passed that another part will seem outdated or messy enough to need re-doing. I don't intend to redo a lot more of it, though I think some of the chest panels need refining.

I actually have some freelance work over the next few weeks; I'm not sure how much of my time it will take up, but it likely means less work done on this project for a while.

Such is life.

Ray.

Despite promising to cover some of the modelling processes I use for the 'Heartbreaker' project, I'm just doing a short post today. Hard surface modelling techniques can wait until I have time (and/or inclination) to do a proper write up.

In my ongoing modelling odyssey* the Heartbreaker project continues, today with the 'finishing' of the head. I say 'finishing' as there are still a few things to do, like a few interior panels that lie behind the exterior panels, but essentially I have finished the main modelling.

Below is the comparison between the old head and the new one. Basically every piece was taken back to a basic stage to be rebuilt or just finished according to some better (or what I believe to be better) reference images.

*Arguably comparable in terms of epicness to The Odyssey by Homer. Not that Homer, the other one, the non-doughnut eating one. Maybe that's unfair. Who am I to say Homer didn't like doughnuts? Maybe he loved them. Maybe referencing different Homers by their doughnut preference was ill-advised and I simply should have been more specific, or, in reality, maybe there aren't as many similarities between this modelling project and an 8th century, ancient Greek poem as I thought...

Below is a still of the new version of the head as well as the back:

I hope you liked the title of this post: 'Making Headway'. It was a pun, because this post has been about the head I've been modelling and because of the progress or 'headway' I've been making. Puns really do give us the best of both worlds: they're fun and informative.

Ray.

'Heartbreaker' isn't the main thing I'm going to be talking about today. I did do some work on it (as I do every week); it was an update on the head, and I wanted to finish that update before showing a 'before and after' comparison, so until that's fully finished, I'll just show the newer version of the bicep which I also worked on:

What I'm mainly going to talk about is an add-on I released last week. What I find can often happen (ok, fairly rarely) is that you suddenly realise that you've had a workflow problem for a while, but you've just got used to it and have learned to work with it instead of looking for a solution. This is what I realised had happened with hide and unhide. When I work on 'Heartbreaker' I generally end up isolating part of the suit, like the head, in order to focus only on that. To do that I use 'Local view'. I also use hide and unhide, the built in blender commands (H and Alt+H respectively). I use them a lot.

I was hiding a lot of objects and then wanting to bring back one specific object. Of course, that's not really an option unless you're using the outliner, so unhiding would unhide everything, most of which I would then immediately re-hide. I tried to think of a solution to that. How could I visualise hidden objects and be able to selectively unhide them? Would a panel work? A menu? And who in their right mind has the time to answer all these rhetorical questions?

With the near unbearable slew of self-questioning dealt with, I managed to find time to come up with 'Selective Unhide', which replaces the default Alt+H behaviour:

With the add-on installed (freely* available from here) pressing Alt + H now shows the menu in the image above.

*This isn't an asterisk to say that actually, no, it isn't free, but instead it's to simply highlight how kind and selfless it is to give something away for free. So, yes, it is free, but be sure to send me a mental or actual note of thanks every time you use it. Although, if you use it a lot maybe you could just consolidate all the thank yous (actual or mental) into a weekly digest. Obviously I want to receive your praise, I just don't want to be swamped by praise. Maybe I'm overthinking the whole 'praise' thing, I just think that it's important to receive praise in moderation. I don't want to overdo it and get too big headed from all the inevitable praise headed my way.

Let's go through each of the menu items:

Unhide all objects - This is the old behaviour - it shows any object that is hidden.

UnHide all by type - Despite the odd, mid-word capitalisation, this groups all hidden objects by object type, like 'Mesh', 'Camera' or 'Curves', for example. Clicking on an object type will unhide all objects of that type. Maybe you have a light setup you want to keep hidden, but want to reveal all your meshes.

Search - This is what I seem to be using most. It allows you to search for any hidden object or group and reveal that item. This allows you to quickly find a specific object, the downside being that it relies on well named objects. I try to see the up-side of things, so I'm going to say it's an advantage that it relies on well named objects as it means I have been forced to start renaming all objects that have some numerical variant of the name 'Cube'.

Hidden Groups - If an object is hidden and is in a group, then the name of the group is listed here. Clicking it restores all hidden objects in that group. So if you found you were constantly unhiding and hiding the same objects, group them, and this will help with that.

Hidden objects by type - Similar to 'Unhide all by type', this groups all the hidden objects by their object type. The difference this time is that clicking on an object type will then show a sub-menu listing all the hidden objects of that type that you can unhide.

Someone on Twitter suggested I that the menu should also work for bones in Edit mode and Pose mode. I agreed, so it now works in Edit mode, showing hidden bones and hidden bone groups, though I haven't yet implemented this for Pose mode.

Next week I'll hopefully be showing the updated head of 'Heartbreaker' and I might go over hard-surface techniques I use a lot.

Well there we go. Another week, another blog post, another set of anomalous asterisks and atrocious alliteration.


Ray.