Capturefinery is live on the Dynamo Package Manager!

(If you're asking yourself "what's Capturefinery?" then I suggest reading these posts first. TL;DR: Capturefinery is a tool for capturing screenshots of the various runs in a Refinery study and compiling them into animated GIFs for sharing via social media or including in customer presentations.)

Firstly, a huge thank you to my partner in crime – and the first (so far only?) user of Capturefinery – Simon Breslav. He's been kicking the tyres and giving very helpful feedback that has steered the development of this package. He very kindly tells me he likes it a lot – I hope you all will, too.

Anyway, firstly a quick rundown on the changes since last time. One of the big changes was the introduction of a progress bar, so you can tell how many runs have been captured, and how many are left to complete. This wouldn't have been possible when capturing the graphics via the screen – as the images would contain the progress bar – but when we shifted to accessing Dynamo's graphics directly this suddenly got put back on the table. Which also meant we could add a "cancel" button, rather than the inelegant approach of looking for the Escape key to be pressed.Progress

Once a capture is completed, the user now has the option to copy the path to the results folder to the clipboard, which should save a fair amount of needless hard-drive searching.

Message at the end

The next big change – and this was very much inspired by Simon's feedback – was the addition of image sorting based on the various parameters (whether inputs or outputs). Which means you can sort based on a particular goal or perhaps on a number of different input parameters. Initially we had two levels of sorting, then four, then ten… now you can sort on as many parameters as exist in the graph. (This took me quite a bit of work to do… I had to get my head around ItemsControls and DataTemplates in WPF to stop having a hardcoded set of labels and comboboxes. I will say the code is much more straightforward now, though: check it out, if you're interested.)

Sorting levels

One might ask, is it really useful to sort based on so many parameters? If using output parameters that are continuous, then probably not: the chances are the images will only be sorted based on the first one. Where this feature comes into its own (and it's also why Simon told me "10 isn't enough") is when you want to sort based on input parameters. Especially now that with Refinery 0.9.3 or higher the step size for input parameters is respected, so you start to see inputs mapped more onto a grid, rather than being all over the place. This is a super-important feature, and I'm really glad the Refinery team prioritised it.

Sorting levels - extreme

It also means that you're going to see more clustering of runs with common input parameters, so multi-level sorting becomes very relevant, especially if you want to create interesting animations based on different sort orders.

Which brings up a very important point: you don't have to capture any new images to create a new animation, you can just load the existing set of captured images. You do this by checking "Load existing images" and by setting the "Number of items to capture" to 0. (The start index is irrelevant, at this point.) This will quickly allow you to explore sorting by different parameters. To facilitate this, I also added a textbox allowing you to customize a root name for the various animated GIFs that are created. This way you can specify the goal in this root name, so that you don't overwrite existing animations as you play.

Here's a sample animation (which needs slowing down manually using GIMP, as we have no control over the speed inside .NET) that sorts based on the Daylight metric:

Sample results

As you can hopefully see, this tool has evolved fairly quickly with quite a bit of complexity, both from a user- and a developer-perspective. If you have questions, please do post a comment, but also be sure to let me know of any quirks: there are for sure issues that I haven't yet spotted, and I do keep stumbling across quirky behaviour. I've flagged this as a "pre-release" package, for now, so do let me know how you get on!

6 responses to “Capturefinery is live on the Dynamo Package Manager!”

  1. Thanks for this, really cool 😀

    Which version of Dynamo should I be using? Because it warns me during package installation that I'm using an older version. I have 2.0.2.6826

    🙁 It crashed every time i tried using it. The progress bar runs to half way, sometimes to the end, then Dynamo closes itself (leaving refinery open).

    I've tracked down the screenshot folder, however it seems the same screenshot is repeated 5 times. It also doesn't complete the total number of intended screenshots. No Animation file created with ''create animation" checked.

    I might be doing something wrong.

    1. Hi Sylar,

      That version should work fine (it's what I'm using).

      Are you using Dynamo Sandbox or Dynamo for Revit? Can you share the graph you're using, so I can try to reproduce? (You can email me at kean.walmsley@autodesk.com.)

      You can always create the images in batches, if there's some kind of memory problem (reduce the number of items and vary the start index to capture them a few at a time). Once you have all the images on disk you can create the animation without capturing any items (set number of items to 0).

      Thanks for giving it a try!

      Kean

    2. Kean Walmsley Avatar

      Hi again Sylar,

      I've updated the Capturefinery package: please make sure you're using 0.9.5 or higher. I don't know that it will fix your problem, but you should recheck with that and we can look into any remaining issues after that.

      Thanks for your patience,

      Kean

      1. Hi Kean,

        Thanks for getting back to me. I'm using Dynamo Sandbox.

        I've updated Capturefinery as recommended. I tried doing a Capturefinery study as before but Dynamo popped up an error and crashed. Relaunching Dynamo Sandbox revealed that Capturefinery had been uninstalled. I've tried running it again but the results were the same.

        I'm sharing the files with you as suggested, including the details of the crash.

        1. Kean Walmsley Avatar

          Right... it turns out the issue was having the run type set to "Automatic". I've posted a new version (0.9.6) that sets the run type temporarily (during a capture) to "Manual", and then sets it back afterwards.

          Thanks for reporting this and help me track it down, Sylar!

          Kean

          1. Awesome Kean! Works flawless now
            Thanks!
            😀

Leave a Reply to Sylar Wesker Cancel reply

Your email address will not be published. Required fields are marked *