Vortex

http://dribbble.com/

Share designs

Doug Bowman on delight.

http://www.webstock.org.nz/talks/speakers/doug-bowman/delivering-delight/

surprising, unexpected

Delight (noun)

1. Joy
2. Something that gives great satisfaction or enjoyment

Delight (verb)

1. Capture attention
2. Increase engagement
3. Create desire for more

Misc pieces of advice:

http://www.clockandflame.com/media/dvfxs_webinar_pipeline.flv

http://www.fxguide.com/qt/2651/pixars-michael-johnson

So, the first release is in a week. We’ve been pretty busy this last month trying to narrow our feature set. The first release, is a complete restructure of our old code that looks exactly the same (interface wise, things look exactly the same), but, among other things, makes the software easy to install and get started for our advisory team.

One of our major discussions has been about what our core feature set is. In the time we have available, we can’t match the feature set of the major pipeline and workflow applications, but our premise has been that we can set the foundations. So, one of the key elements of this last month, besides the research and restructure, has been to write an “extension” system from bottom up, which allows the user, through our API, to add to and access the tool. We will also endeavor to write as many of our widgets and as much of our functionality as “extensions.” The hope is that, in the future, the users (studios, contributors, etc.) will be able to easily take our core and build fully functional customized systems on top.

We also continue to have a plugin system, which puts all of the responsibility on the developer to load/unload their code.  The extension system promotes the API interface, and adds some “logic” to the code handling.

Our last month has also focused heavily on getting our TRAC site up a running, and laying out some clear guidelines for code contribution (software guidelines, wiki guidelines, etc).  This kind of work seems incidental to the actual programming process, but I think essential if we want a strong contributor community.  The film/animation industry is filled with aspiring programmers (who don’t necessarily have the training).  One of our goals is to strongly encourage this group to develop their own custom extensions for the pipeline tool.  What that means is that finding a balance between easy of use, and depth of features, from an API/extension point of view, is a constant discussion.

Here are some of the miscellaneous research ideas:

• http://cassandra.apache.org/
• http://www.xs4all.nl/~irmen/pyro3/

Next time, I’ll get into more of the specific tests we’re running (speed, performance, etc), and our future roadmap.

Our development is focused around a particular set of projects – one feature animation, and one short animation.  We have assembled an advisory team, made up of other developers from our local (Danish) industry, which also includes the core development team, and representatives from the feature project.

The intent of the advisory meetings, so far, has been to broadly describe users, and user needs in animation pipelines, where “users” encompasses, among other things, people working on the project, the studio itself, and the pipeline systems that might run persistently across a project.  Since our tasks are not precisely defined for us, describing the scope is one of the first challenges.

Our tool is also intended, at least initially, for the small market here, which is not necessarily tech savvy, nor large in size (which both reflects the amount of financing, and the size of the target market).  That carries a number of repercussions, not least that one of challenges is in creating a high level of interface accessibility to the tool’s features.  Our users may know how to write Python scripts in their standard 3d application, but not know basic fundamentals of programming, or development.  So far, it seems unlikely that the target demographic will have large support teams, extensive r&d, or modular workflows (to name a few).

Although this project is not OSS, at least not yet, our focus is still on building a collaboration backend for our users.  We’ve set up a TRAC site for the majority of our communication (hydralab continues to depend on modified trac environments for our production tracking), where we also host the code.   The project has an #IRC channel, a list-serve, and a focus on documentation, style guides, and software FAQs.

At our next advisory meeting, we expect to look more specifically at implementation questions.  So far, the core team has been evaluating our legacy code, running simulation scenarios, writing a broad range of use cases, and doing some prototype testing, but this next week, we’ll start to try and pinpoint our specific projects’ needs.

The pipeline development is a continuation of Hydralab’s internal pipeline.  This pipeline began as a project for Mikkel Jans in the spring of 2009 to help us construct a custom view of our file system that would including some type of file version control (in our case, that dcvs was Mercurial).

As we progressed, it turned out that we could use this interface for a number of other tasks.  We developed methods to define “projects” which were selectable via a dropdown, publishing procedures for assets, a custom queue system for launching local scripts jobs, context sensitive menus, etc, etc.  We used the pipeline (termed Machine Browser, after the studio’s short film) for a couple of commercial and in-house projects, and invested in more development time.  Our task backend developed around trac, our applications opened through the browser UI, and we used command ports to control messaging between the applications.  We developed a rudimentary API and set all of our file path information based on relative “project” concepts in the browser that we accessed through that API.  We added a shortcuts panel, with per-project categories, bookmarks, and latest opened items.

Suddenly the tool that had begun as simply a view on our file system (with some convenience events to integrate the version control), took on a lot more roles.  Simultaneously, the benefits of working through a unified interface, and the problems of not having designed the tool with all of these new functions in mind, became apparent.  We had a functional tool, but needed to assess it with the intent to develop a much more robust platform.  Mikkel spent December of 2009 exploring a range of new areas, and with the persistent thought that the software needed to go through some heavy duty refactoring, and potential reorganization in order to be viable for all of our future plans.

This is what we start with from here.

Today is the launch of our pipeline development blog.  For info, look on the Home page.   World domination begins here!