Saturday, May 5, 2018

Code Quest - Weekly Roundup (Weeks 1-4)

Lo and behold, we're almost a month into the Code Quest already! I had originally intended to write this post after the first 2 weeks (already down from my initial target of maybe a single post per week). But... between making the most of my time here to explore Amsterdam/Europe, the day to day activities in the studio, having to deal with all the other "life crap" (e.g. cooking, laundry, groceries, and some ongoing struggles with our apartment's water heating system, etc.), and finally, a broken laptop this past 1-2 weeks (more on this in a moment), the third fourth week has been and gone, and I still haven't gotten around to putting this together finishing this post!


I'm going to keep this brief though, as I'm still running my laptop off its battery after the adapter started playing up (basically last weekend, it suddenly got somewhat fried, and is now only sporadically charging, and taking nearly a day to do so when it works)... just what I needed when development activity was starting to pick up pace here!

For more up to date info as it happens, I'll be mostly posting short updates to my Twitter feed, since that's a bit easier to update using just my phone. Hopefully I haven't already started getting my dates mixed up - I'd been trying to keep notes to help remember, but it's been a challenge even finding the time to get those done!


Tuesday, April 17, 2018

Shell script to set up Ready-To-Use Blender Git Checkouts on Linux

Recently, I've been setting up quite a few copies/checkouts of Blender Git repositories (approximately 3-4 per machine I'm using - including twice on the same machine after the hard drive failed). Doing this has made me all too aware of all the steps needed to get these things into a nicely working state for development (including how you need to copy out a whole bunch of commands each time).

Today, I can announce that for Linux users, the wait is over! I've successfully put together a script that basically automates the entire procedure listed on the wiki, making it possible to relatively painlessly grab the Blender sources, and then proceed to compile and run them.


It's actually part of a larger repo of automated configuration-setup scripts/tools I've been putting together over the past few weeks to make it easier to get my computing setup deployed onto new machines faster. For the time being, I'm not quite prepared to release the actual repo where all these are housed publicly, as I still haven't managed to fully vet that no private details have managed to leak/leech into the config files contained. Unfortunately, the final release of that may have to wait until I'm back in NZ (as it seems that I ultimately ended up forgetting to transfer some critical files for a few of the programs).


Saturday, April 14, 2018

Knotted - A Short Film Idea (for testing Tools for Animating Hand-Rope/String Interactions)

(This post was split off from my post about a grand vision for the future direction of animation tools, as it was growing a bit too large for that).

For the ultimate test of hand/finger interaction with a length of string, I've dreamed up a little short film, set in a village where everyone (but the main character) is a master knot-tier. In fact, the opening scene is literally a montage of different pairs of hands tying increasingly fancy knots and bows.

The idea is that, we'd produce this short once we have the technology in place to make producing it feasible. That is, we'd have a bunch of awesome new tools that are amazing at helping animators manage such interactions (which are fiendishly hellish now), meaning that doing such shots should be much easier, meaning that we can afford to do quite a few of them to show off a bit :)  Well, at least that's the theory!

Of course, we'd first have to find a solution to that technical hurdle :)  (I'd love to have a chat with some experienced animators about this sometime in the coming months, so get in touch)


Future of Animation Tools - Some WIP Thoughts and Ideas (+ the Role of Pose Sculpting in All This)

As a follow-up on my earlier brief discussion about the general direction for Motion Path editing in Blender, I figured that it's probably time to outline a bit more my longer-term vision for the future of the animation tools (mainly in Blender, but also the wider animation industry at large) to give a bit more context/motivation to my earlier comments.



I had originally intended to release this all a bit later once I had a few more key pieces in place, but, inspired by Raf Anzovin's enlightening blog, Daniel M Lara's Easy Rigging stuff, the exciting developments in the VR-based animation space, and also the 2.8 code quest, I decided to put this out earlier.

In this article, I'm going to try to "throw the ball further" (as Emirates Team NZ would say) and take a more comprehensive view of where we need to going in the medium to long term, as well as what steps we can take now.

(NOTE: I originally started writing this article in NZ, but in between preparing a new laptop for travel, and travelling to/settling in Amsterdam for Code Quest, I've only had time to really work on finishing this in the past day or so).

Tuesday, April 3, 2018

Blender 2.8 Code Quest - Here I come!

Tomorrow marks the start of my next big adventure - travelling quite literally half a world away (with a 12 hour time inversion to boot)!

As most readers of this blog would probably know by now, next week, the Blender 2.8 "Code Quest" begins in Amsterdam. 10+ core developers of Blender will be gathering in the Blender Institute/Animation Studios for several months to get Blender 2.8 ready for public use - finishing off many todo's from the 2.8 project and/or laying the foundations for the next 5-10 years of Blender development!



Early tomorrow morning, I'll be flying out to join the team, spending some 26 hours or so of bone-crunching, butt numbing long haul flying. (Alas, this is one of those times when New Zealand's relative isolation from the rest of the world is a bit of a curse). Sitting here typing this tonight (while wrapping up a few last preparations on the stuff I'll be bringing along), it feels quite surreal to think that soon I'll finally be meeting many good friends and colleagues "in the flesh" for the first time after knowing each other for over a decade, and having spent many years watching the conference/BTS content wanting to visit Blender HQ and hang out with everyone.


Thursday, March 22, 2018

The Hunt for a New Laptop + My New Box Setup Process

I've probably mentioned this before (or maybe it was just in one of my still "in-draft-form" posts), but it's probably well and truly time that I set up a new machine. Actually, it's probably been time to do so for over a year now, but I've managed to get by with an increasingly large bunch of external hard drives and nasty hacks (i.e. command-line args + wrapper scripts) to make Blender 2.8 runnable (due to graphics driver bugs). But, as I'll soon explain, the reason why I haven't just gone out and gotten a new machine is not so much the money/cost aspect, but rather, the time + effort cost involved in hunting down a suitable machine, and then, SETTING IT UP.

Long time readers may recall the series of posts I did a few years back when I set up the current box - first spending weeks/months tweaking Windows 8 into submission, which lead to a 3-4 month unsuccessful "Linux Experiment" (which was nominally a dual-boot setup, that was an minor marathon in itself to set up). This time, I'm not currently hoping to do another Linux experiment (yet!  Until Microsoft's Windows 10 auto-updates drive me up the wall enough to start taking nuclear options...)

Anyway, with the Code Quest looming, matters have become a bit more pressing, as I'm not keen on lugging my current box over. (For one thing, I'd need to also lug a fragile external HD along with it, if I didn't want to wait several months until I could get all my photos off my camera; also, there are those hacks needed to run 2.8 (seriously inconvenient at times), and there's too much other stuff on this box that I don't want to be lugging around everywhere).

Originally, I'd been planning on getting my first desktop tower in years (with all the scope/capacity to put whatever high powered stuff in there, plus ample room for many racks of internal hard drives, a proper "silent" cooling system, and gazillions of top-mounted USB ports) for my main/daily-driver home-office workstation, and then a not-so-critical laptop that could be used on the go. (And, by "not-so-critical", I mean, I don't care soo much about max speed + max storage + max ram + graphics performance, since my tower can serve that role instead... of course that said, it'd still have to satisfy my selection criteria below still!)


Friday, March 9, 2018

Thoughts About Geometry-Editing UX issues - Multi Object Editing, Edit Modes, Selection/Action Split, etc.

Just a little earlier, I spent some time reviewing and commenting on T54242 regarding the design issues behind making Blender be able to have multiple objects in Edit/Sculpt/Paint Modes at the same time. As outlined, there are certainly a few rather prickly issues in that we'd need to resolve to be able to do this.

In this post, I'll go over a few of the key issues we need to contend with here, along with some other general thoughts I've been mulling over for quite a few years now about what IMO makes an effective UI for editing large amounts of geometry (i.e. vertices, control points, etc.)


Wednesday, February 28, 2018

Struggles of a Rust Novice - Annoyances and Stumbling Blocks

Over the past few weekends, I've been spending time investigating more of the Rust language. Along with the web trifecta (HTML, CSS, JS) and OpenFrameworks, this is one of the things I've been meaning to spend some time learning/playing with this year.

It's a funny kind of language, as I've previous noted during my very brief foray into some simple things from last year) - On one hand, a lot of the concepts seem nice/vaguely familiar to stuff I've played with in other languages, making it sometimes feel deceptively easy to use. But then, you go to compile the code, and proceed to spend the next 30-60 minutes trying to find a way to convert various things into the right types that the compiler insists you need. Admittedly, it's quite frustrating work at times (see notes on String handling below), but, it pales in comparison to the blackhole and deranged hell that is web-based dev (i.e. CSS-based Layouts in particular - aaaaaaargh!!! Despite now having "CSS Flow" and "CSS Grid", it seems that CSS Layouts and I still don't get along very much at all). Faced with a choice between the two (and having just done experienced both back-to-back recently), I'd much rather face the Rust compiler anyday.

Anyway, to actually get a proper feel for the language this time, I decided to use this opportunity to bash together a little processing tool that I was going to need for another one of the many projects I'm working on atm:
That is, a tool to take XSPF playlists generated by VLC (and containing a carefully sequenced list of music I've composed/recorded over the past year), extract the filenames (and process them to unpack/extract-out the important identifying bits of metadata I was embedding in the filenames), and then spit all this info out into a more easily consumable format (e.g. JSON).  
Sure, I could've done this all in Python (though it lacks a XML library that just gives me the DOM element tree with no "namespace" tag mangling, etc.), or a mix of VLC + Python (i.e. saving out a m3u list - 1 line per track - then processing that in Python), but this way was going to be more fun (and a good way to throw something a bit meatier/realistic at Rust than the toy-examples I'd been playing with) :)


Hopefully the following post will be enlightening to some people out there - both other newbies stuck and struggling to get their heads around certain things they keep running into, but also for the Rust dev team in their self-professed "ergonomics drive" to lessen the humps that new devs face when learning Rust.

Friday, February 16, 2018

Happy Chinese New Year 2018 - Year of the Dog

Wishing everyone a productive and joyous Year of the Dog!


Thursday, February 15, 2018

Silvereye vs Berry - Slowmo & Regular Speed

Yesterday evening, I caught a plump little silvereye blissfully feasting away on a tasty little yellow berry out the back of the house. Amazingly, I managed to stand there for a few minutes snapping away and recording footage through the gap between the window and the windowframe; it may have helped that the toilet was gurgling away nearby to drown out the clap-clap-clap-clap-clap of the shutter XD (hence why I've replaced the original audio with some more snippets of music from my thesis writing collections).

Here is the footage of the birdie in action. First up is the slowed down version (from 25 fps down to 5 fps):

It's comical watching the birdy chomping, twisting, and tugging away like this.

It's also surprising just how relaxed/serene it all looks when slowed down like this (something I've noticed when stepping through the footage of some earlier clips too) - it's almost like we're finally seeing the world at the speed that the birds actually live/experience it! And to think that I only really noticed this after watching the full-speed clip render out at about this speed and realising just how much more interesting it was to watch when played back this slowly... :D


Now, if you're wondering what it actually looks like at full speed, here's the full-speed version:

It looks a whole lot more frantic eh? (And, just to be clear, I didn't speed up the video... they really do move that quickly in real life!)


As always, these were edited in the Blender Sequencer - I still have the same complaints about ugly quirks in the workflow though :(

(Note to self: I must really get cracking on either adding per-strip blendin/out + better font/text support to the sequencer, OR just bite the bullet and put together my own FFMPEG-based "VIM x Node-Tree" video/audio editor project. If it wasn't for the overhead of setting up a new app structure from scratch and then maintaining it, I get the feeling that the latter would almost invariably end up being a better solution in the long run for my particular needs/workflow)

Tuesday, February 13, 2018

The Battle Against Compartmentalisation - Curiculum Design Challenges

Recently there has been a lot of discussion about the need for ethics courses as part of Computer Science / Software Engineering (or really, any form of engineering) degrees for obvious reasons. While I don't dispute the need for such courses (and indeed, I firmly applaud and welcome the introduction of these as integral parts of the curriculum) experience suggests that we do need to think about how we're presenting such material to students.

Specifically, I have doubts about whether the standard model of "let's just include a course in there to tick that requirement off" is actually the most effective way of doing it. Examples of such courses include "Programming in Matlab", "Ethics", "Security", and to a lesser degree, parts of HCI/Usability/UX. Many of these also carry a bit of added baggage in that they are often designated as "required" courses for a particular degree (more on this later).

From personal experience (and from observing students over many years), topics like this cannot be easily "compartmentalised" into a "tidy little thing that you think about separately from other things". That is, you can't really say, "Here is the body of knowledge you need to know. Memorise it, and pull it out of a hat when you need it". Instead, true understanding and mastery of such material is actually only achieved by adopting the "fundamental mindset" involved. For example, a few crude examples of fundamental mindsets for the aforementioned fields are:
     * Security - Trust no inputs - Treat everything that the "user" inputted as being potentially compromised, and a potential attempted attack.
      - Alternative mindset: How can I hack/crack this?

     * Ethics - How could this go wrong in the worst case? Who could get hurt/harmed, how bad would that be, and are there better alternatives that won't cause anyone that sort of trouble?
      -  Alternative Summary 1: Don't be a jerk
      -  Alternative Summary 2: Would you subject yourself and your loved ones to this? Your mother? Your children/future-children/grandkids/great-grandkids?

     * Usability - Humans are clumsy and stupid creatures of habit (with limited memories, limited attention spans, limited physical capabilities, and a whole bunch of other handicaps).   The problem therefore becomes - how do we try to reduce confusion and/or the potential for things to go wrong so that the bumbling apes can still get their jobs done.
       - Alternative Summary: Could I still use this thing when drunk, sick, injured, all of the above, and I couldn't look up the code/docs to check what's going on?

     * ProgrammingComputers are idiots - They can perform complex operations, lots of them, very very fast. But, you have to precisely tell that what to do, when to do it, and how to do it first.

However, you can only adopt/absorb a fundamental mindset if you spend time developing a new a set of skills and/or adopt new ways of thinking about problems.


"Hex to RGBA" and other Colour Conversion Tools for Sublime Text 2/3

Today I'm announcing the first release of a new plugin for Sublime Text 3 (ST2 untested, but may well be supported too, *fingers crossed*) that makes it easier to work with various colour representations in code. As anyone who spends any time working with various colour pickers and colour-related API's on different platforms knows, at some point you're going to have to convert your colours from one representation to another for some reason, and then you suddenly have to waste heaps of time converting and transcribing colour values between different representations. Clearly this can be optimised (we're using modern text editors for goodness sakes!)  So, without further ado, the plugin can be found at the following Github repo:






Key Features:
* Convert Hex (i.e. #RRGGBB) color representation to a RGBA tuple (i.e. rgba(0-255, 0-255, 0-255, 0-1))
* Convert RGB(A) tuple (i.e. rgba(0-255, 0-255, 0-255, 0-1)  OR rgb(0-255, 0-255, 0-255)) to Hex (i.e. #RRGGBB)
* Convert individual colour values from 0-255 (unsigned byte) values to/from float (0.0-1.0) values
* Accessible from menus (shown in screenshot), using hotkeys (shown in screenshot too: Ctrl-Shift-R for "Convert to rgba", and Ctrl-Shift-H for "Convert to hex"), and from the command palette (Ctrl-Shift-P - I recommend searching for "hex" or "ub")

EDIT (20180215):  I've just tested it in Sublime Text 2, and it also works there. So, it's safe to say that it works on both now :)