Idea: Addon Manager

I was wondering today about how feasible something like this is: A system that allows you to download and install an addon with the click of a button, as well as tell you if an update is available to something you already have installed and update that with one click as well.

It would theoretically use the SVN/Git collection of trunk and contrib* addons and periodically check if an update to those already in Blender is available. Additionally, it would fetch an external database of Addons that are not a part of trunk or contrib and show an entry for each of these just like any other addon, only instead of an ‘Enable’ check-box, you’d have a ‘Download and Install’ button.

This would fetch the addon from the server, downloading it to a temporary place, and install it for you. Simple yeah?

That much is easy, in fact it’s literally 3 lines of code. The problem with this idea is maintainability and flexibility. The whole point of it is to show a repository of addons from external sources, since trunk addons are already there and updated every release, and contrib ones come with most graphicall and build bot builds – however we still have to somehow control what addons are in this repository, allowing anyone and everyone to add to it would be messy and a serious security risk (imagine you enable a cool looking addon that promises a one-click character rig, only to find its a piece of malware with a keylogger).

Someone has to maintain this repository personally, which leaves the question  of how best to do this with minimal regular effort? You could update it only once a week perhaps, but you still need a way to automatically go through the database of scripts and find out which has a newer version available. This means that for each addon you’ll need some custom method of checking for new versions, some developers will update the same file on a server, while others might increment a number and leave the old file in place (auto_tile_size_release_03.py for example)

(mockup)

(mockup)

I’m not the first to have this idea. Campbell wrote a primitive one a while ago, and Gaia Clary apparently as well. They encountered the same problems. The script itself is trivial, the maintainability is not.

I don’t often like to publicize these mad ideas of mine, they don’t normally lead to much, but this time I’d like to ask if you have any suggestions for me – how can I do this simply and only have maybe 20 minutes work per week on maintaining a database of addons? Should I store the addons on my own server, or rely on the original source? Perhaps only include those in the external column of the wiki page? What about asking developers to contribute to this repository and update it each time they release a new version? If so, how best would we combat low quality addons and potential security issues?

The UI mockup at the top of this post is a quick one – I’d still need to handle categories and such, and I might as well edit the existing UI instead of creating my own.

* The Trunk set of addons are those included in Blender by default, stuff like importers and the very useful ones such as Looptools and Node Efficiency Tools. The Contrib set is a collection of addons not included in the official release of Blender, but still officially approved by Blender devs and can be trusted that they’re pretty darn good.

First Successful HDR Panorama

For several months (more than a year even?) I’ve been trying on and off to find a way to create HDR panoramas. 360 degree equirectangular panoramic high dynamic range image, to use for lighting.

And recently I’ve finally had success o/

Might be because I’ve got a decent DSLR camera now, or simply that I understand the process a bit better. Either way, expect a whole bunch of these in the future, and some how-to’s (because “tutorial” is too mainstream) on how to make your own on a budget (or no budget at all).

For now, here’s my first successful one:

(preview)

(preview)

Test render using only the HDR for lighting

Test render using only the HDR for lighting

Download HDR IBL image (2048×1024 – 5.7 MB)
(Licenced CC0)

Yes this is my lounge… and yes that is a cat.

One thing this tought me is to pay more attention to white balance. I figured I could just fix that in post, but it’s not as simple as that when theres about 120 images to edit and retain their raw color depth and exif data. The image is a bit more blue than it should be, but lesson learnt!

Link Juggling Removed

From the commit logs:

(r61178 – Lukas Toenne)
Removed the automatic “link swapping” feature from the node link operator: When a link was being dragged to an already connected input, the existing links were shifted to the next free socket.

This was originally intended as a way to speed up workflow for math and mix nodes, but more often than not it just gets in the way. Most binary (or n-ary) functions are not even commutative, i.e. changing the order of sockets does not usually produce the correct result.

Also this includes the more common case where one actually wants to replace a socket, which then requires a second click to remove the shifted connection.

All in all this is not a helpful feature.

I think we can all agree this is a change for the better :)

Sure there are some times where it’s useful, but it’s mostly just annoying. If you really miss it, fear not, in the next release of Node Wrangler there’ll be a feature for all you lazy bastards.

Auto Tile Size addon updated (again)

Well when I started this blog, I would never have imagined it would turn into a code blog. I guess once I started doing shading and lighting more often at work, I lost interest in doing anything like that at home and turned to a new hobby.

Anyway, I fixed the issue with Blender Internal renderer getting stuck on tile sizes meant for Cycles, so BI now get’s it’s own tile size stored separately (defaulting at +-64). I also made sure no other renderer would get stuck using the same tile sizes by simply disabling it when the scene is not using BI or Cycles. And lastly a tiny UI tweak, hiding the target size behind a settings button since unless you really know what you’re doing you probably shouldn’t touch it anyway.

[Download Auto Tile Size Addon]

I also did a fair amount of testing to make sure my old assumptions were actually correct, and turns out they are:

tile_size_stats

I tested four very different scenes in Cycles using both GPU and CPU, with different resolutions and scene content.

As you can see, CPU likes small tiles and GPU likes bigger ones – whether or not the tiles are all the same size doesn’t seem to matter as much as I thought, although it does matter on the GPU if they are drastically different, such as very thin tiles on the edge, but that’s probably because the tile has a smaller area and not really anything to do with how square it is. Still, I stick with my original logic just to avoid these corner cases.

The story with Blender Internal is a little different. Here I only tested one scene at 1080p, either because I was too lazy to try some more, because others told me the best size already, or because the results of this one test were pretty conclusive. You choose. The point is that tile sizes in BI really don’t matter all that much. The main reason why the render gets slightly slower as the tile size decreases is because it has to look too see what’s inside that tile before rendering, and thus there’s a small overhead of render time for each tile, thus the more tiles there are the longer it takes.

Lastly, one of the reasons why the render takes longer in all three cases (Cycles GPU, CPU and BI) with large tiles is mostly because there are more tiles than there are threads available. For example 512×512 tiles in a 1024×1024 image means there’s only 4 cores of your CPU renderering, the rest are doing nothing at all. This might not matter too much with GPU rendering as you can see in the first two tests, since you only have 1 or 2 tiles rendering at once anyway.

 

(Re)Introducing Node Wrangler!

01

Just one of the new features, Viewer node for Cycles materials

Version 1.0 was, lets face it, not particularly useful. In fact the only thing I still use from it occasionally is that auto-arrangement feature. However, since the Zoom-Fit function inspired Henrik Aarnio to include it in trunk with the Alt+Home key, it wasn’t completely useless at all.

In fact, I’ve secretly been working on a whole bucket-full of new features!

Get the Node Wrangler!

I’ve made a page specifically for this addon, and I’ll continue to update it as I add more features. Here’s a summary of the features as they stand right now (but check the page for the very latest):

  • Viewer node for Cycles materials (Ctrl+Shift+Click)
  • Delete unused nodes (Alt+X)
  • UV Layer nodes – add an attribute node from a list of available UV maps with the name field already filled in (Shift+A > Input > UV Maps > [map name])
  • Switch the type of one or more nodes to a related type, like a different shader (Alt+S), keeping inputs and outputs connected
  • Swap the output connections of two nodes (Alt+Shift+S)
  • Reset the compositor backdrop image zoom and position (Z)
  • Frame the selected nodes (Shift+P)
  • Reload the images of all the image nodes in the current tree (Alt+R)
  • Quickly jump to the Image Editor and view the image of the selected node. Works for textures, movie clips, environment images, render layers, viewer nodes and masks.
  • Automatically arrange the selected nodes (or all of them) in a non-overlapping linear layout (Q)

The todo list is public on GitHub, as is the changelog which is updated automatically as I commit changes and new features.

That page I mentioned earlier has a lot more info on each feature, including a gif showing their usage.