As we are steadily pushing through to finish animation, Thomas has been creating rough mockups of the sound design, so we can iterate early and come to some conclusions before the final minute. Each time, we discuss some things about the sound, how to improve it, etc.

This time, I was getting annoyed going back and forth between a text editor and blender- clicking on one and then the other (focus follows mouse would be much, much better here!) and different hotkeys etc. Plus, text in a text editor requires me to estimate the frame/time of the note each time.

Then I had a little brainwave and downloaded gnome subtitle editor, and writing my comments as subtitles. It goes much smoother now and is a nice tip for teams who need to give feedback on videos. It’s also possible to use blender, but there the workflow would be a bit more tedious with markers (though grease pencil in the sequencer- if grease pencil could be used to display text as well as drawing, and could be rendered would be even better for me)

so here’s a little screenie in action. I paused it at a familiar shot so I wouldn’t show spoilers…

there’s actually many choices here – you can use video editors or blender (but then you have to render) or any number of subtitle editors. I just thought it was a neat use of something for the (wrong?) purpose.

This is a slightly technical detail kind of post- the kind of geekery you’d be interested in if you’ve heard of revision control systems, GIT, Subversion, etc. It doesn’t seem to have to do a whole lot with 3D graphics, but managing files is always going to be an issue in a project of any size.

Since the tube kickstarter campaign ended our team has swelled to 25, and most of them are not located at Hampshire. (Iincidentally why I haven’t blogged for so long- keeping the project running with an expanded team was a greater than full time job) Even a while ago, it was clear that SVN (aka subversion) was not a great fit for most people, for a bunch of reasons:

1. You have to download the entire project (roughly 8 Gigabytes!) the first time you use it. Slow internet connections and bandwidth caps make this impractical for some.
2. Not everybody is ‘technical’ – updating and committing is several, potentially error-prone steps, sometimes involving the dreaded command line 🙂
3. GUI front ends are platform specific – different docs for different people.

Animators previously used what we called ‘production packages’ : we used blenderaid to pull out dependencies and make a zipped bundle of all the file the animator needed, this was:

1. impractical to do updates on rigs/etc. while an animator was working
2. hardcoded to anim files (though I could have fixed this)
3. needed to ask the animator to send back work in progress for lighting tests.

So we found sparkleshare ! Sparkleshare can be best thought of as a dropbox clone with a git backend. A while ago I looked at it, but it only had a linux client; now that it gained windows and mac clients, we migrated from the production package way to sparkleshare, and away from blenderaid to the blender python api. Now we have the following advantages:

1. one click (on my end) to create a package for *any file* in the production tree – with a choice of including or excluding image files, and the possibility of adding more files easily to the same package.
2. user on the end has to click twice, and enter two bits of information.
3. end user experience after that resembles dropbox. updating rigs means just dropping them into the share, and we can get wip files at any time without having to ask.

Is it perfect? we found some issues (where else) on Windows, where there was no SSH client available (luckily one of our interns- Arindam Mondal) figured out how to use Putty and wrote an extensive Howto , and we also found that Windows XP is not supported. I’m frankly stunned that anyone is still using XP though 😉