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.

This post is mainly about using the Shrinkwrap modifier for modelling, which is below, but there's also a quick update on some of my projects right at the end.

Before I started the 'Heartbreaker' project I probably wouldn't have said that the Shrinkwrap modifier is one of my favourite modifiers in Blender (not that anyone had actually asked me, or likely ever would). Maybe in the top 10, but only just. I would probably have gone for one of the classics, like the Subsurf or Mirror, you just can't go wrong with those two. However, that's all changed. If anyone ever asks me*, I will say my new favourite modifier, at least regarding modelling - which is what I'm doing most of the time - is the Shrinkwrap. It has become my go-to, problem solving, reliable friend.

*Which they wont.

No, I am not. A valid question (the second one), thank you (me) for asking. In its simplest form, the Shrinkwrap modifier is tasked with snapping the current object onto the surface of another object. It also has the ability to only snap specific vertices if you specify a vertex group.

Here we see a simple subdivided plane being shrinkwrapped to the surface of a sphere:

I think the Shrinkwrap modifier was probably first created as a retopology tool, the snapping allowing you to easily create new, low-poly geometry, over your high-res model, without having to constantly think about manual snapping. Considering this, I'm not sure that 'Shrinkwrap' is actually the best name for it; maybe 'Snap' would have been better. The Snap modifier has a ring to it. But then, who am I to start renaming things? Sure, I was technically the best renamer in the area of Greater London in the years 1993 - 1998*, but I have no official certification for that, so I'll leave actual naming and any subsequent renaming to those that do.

*I retired from the gruelling world of competitive renaming undefeated and vowed never to return, due to the physical stress it caused my body.

It's not so much that retopology fits into hard surface modelling it's more that some hard-surface modelling scenarios and retopology share some common needs. Also, please stop asking if I'm insane.

There are two scenarios that can be very time-consuming when modelling:

1. You have several meshes that all need to conform to the same profile (meaning surface curvature).
2. You need to edit or add additional details to a curved surface.

This is very similar to what retopology requires and these two problems both happen to be the Shrinkwrap modifier's strength: conforming vertices to a specific surface.

Please don't be so demanding. I've got some examples from 'Heartbreaker', the project I just literally won't shut up about.

The 'Heartbreaker' Iron Man suit has a tendency to have many separate panels that all conform to the same profile. Below, on the left, is the forearm, which is made of many pieces. They all have the same bulge and crease going through them, which would be time consuming to model manually. Instead, I built one continuous surface to describe the surface I want my mesh to conform to, shown on the right. All the pieces on the left conform to the profile of the mesh on the right (the Shrinkwrap target):

Heartbreaker also has many examples of detailing cut into curved panels. Cutting into curved surfaces is notoriously difficult as any sharpening edge loops on those details end up causing undesirable pinching, particularly at corners. It's also very difficult to perfectly maintain a curved surface while adding in new geometry.

Here, the head remains perfectly curved despite having cut details into it, thanks to good ol' Shrinkwrap:

Here is a wider view of the top of the head on the left, with its Shrinkwrap counterpart on the right:

The 'eyebrows' in the above image were excluded from the Shrinkwrap by adding all vertices apart from the eyebrow to a vertex group and selecting it on the Shrinkwrap modifier.

1. Model a simple mesh that describes the curvature you want your mesh(es) to follow*.
   
2. Add a Shrinkwrap modifier to the mesh(es) you want to conform to your Shrinkwrap object.
3. Select the Shrinkwrap object as the 'Target' on the Shrinkwrap modifier.
4. If you only want to Shrinkwrap part of your mesh, then create a vertex group that contains all the vertices you want to effect and select that vertex group on the modifier.
5. If you want, repeat the previous steps to add multiple Shrinkwraps.

*If I've already started modelling something, but decide I need a Shrinkwrap, I will sometimes duplicate the object I'm modelling, simplify it, and use it as the Shrinkwrap object.

I also like to change the 'Maximum Draw Type' to 'Wire' in the 'Display' panel of the 'Object' tab in the 'Properties Editor' for the Shrinkwrap object so you can see the object you are modelling as well (shown below). Also, you may find it useful to turn on 'Draw All Edges', also in the 'Display' panel and 'Optimal  Display', on the Surbsurf modifier, if you're using one.

Sometimes, creating a good enough Shrinkwrap object would be as complicated as modelling the original object, so not only will I sometimes use several Shrinkwrap objects (instead of one big one), but some of those Shrinkwrap objects have Shrinkwrap modifiers themselves. It's like needing to build scaffolding to be able to build more complicated scaffolding to be able to build the final object.

Here, for example, is the chest piece from Heartbreaker. It's probably the single most complicated piece in the whole suit, shown with all 9 of it's Shrinkwrap objects:

The key to this is vertex groups. Each Shrinkwrap object above is responsible for only part of the mesh.

Despite the unrivalled awesomeness of the Shrinkwrap modifier, it does have a problem, but it can be worked around quite easily.

When you're moving the vertices of an object that is Shrinkwrapped, what you're seeing is the vertices moving along the surface of the Shrinkwrap object. What's actually happening is that you're moving the vertices in 3D space. This causes the Shrinkwrap modifier to sometimes have a hard time determining which part of the surface the vertices should be on if the vertices are actually very far away from it in 3D space (which can happen when editing the mesh). The vertices will snap to the surface, but might not move smoothly. A quick fix for this is to press the 'Copy' button on the Shrinkwrap modifier to create a duplicate and then press 'Apply' on the copy. You have now applied the effects of the modifier and the vertices are now close to the surface again, allowing smooth movement.

The same 'Copy' and 'Apply' process also needs to be done if you find loop-cut-and-slide, vertex-sliding or other modelling tools start to position vertices weirdly. For example, with vertex-sliding, the vertices will slide dependant on where they are in 3D space, which isn't necessarily where they visually appear to be.

One other thing is that the Shrinkwrap modifier should probably be before any Subsurf modifiers you might have on the object. If you have a Subsurf first then you're giving the Shrinkwrap more vertices to play with than actually exist. This will only be problematic if you want to eventually apply all the Shrinkwraps on the object though.

You may think using this technique only applies to specific objects or tasks, but I have found myself using it on many projects and I now can't do without it, so give it a try and let me know how it goes.

As a reward for getting to the end of this post (if you just scrolled all the way down without reading DO NOT LOOK BELOW AT THE REWARD, IT IS NOT FOR YOU), here is the entire 'Heartbreaker' suit with all 113 of it's glorious Shrinkwrap guides:

Embrace the Shrinkwrap modifier, love it, cuddle it, hold it at night, whisper sweet nothings into its ear and thank the gods it exists.

I haven't got much done regarding 'Heartbreaker' so no update on that, other than I'm now working on fixing the upper-back, which I think is the last major part to be redone.

A quick update on 'Selective-Unhide', my unhiding add-on, is that it now supports not just Object Mode, but also Armature Edit Mode and Armature Pose Mode for hidden bones and bone groups and Mesh Edit Mode for hidden vertices:

Still a few things to do on it, I think, but they're relatively minor.


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.