When you start drawing a characters you usually have “front” and “side” concept reference images. And when you need 3/4 view at some gradation it’s always a bit tricky part. And here’s Synfig to the rescue! No, it’s not a tracing time yet, but we can use Synfig’s tweening capabilities to extend our concept references. For example, this is how we get guides for Ivan’s head at particular angle.

Notice how your brain rebuilds the inbetween positions of the head basing the guide lines as references.

The next helpful trick is to use photos as references. Yes, sometimes to figure out the correct look of some elements at certain angles or positions we have to go with shots like you see below.

Hands position on the photo...

...turned into this.

And of course we cheat by using 3D models. Of course the easiest way would be to have 3D models for all characters and do all drawings on top of them. But there is a bad part about that. My experience shows that when you rely much on 3D models in drawing, the characters loose some flexibility or some kind of “creative sparkle”. And it’s not about “uncanny valley” only. Using model clarifies your image, it allows you to make the “right” image, according to “right” rules, “right” perspective, etc. But at the same time it puts your imagination to the limits and that’s bad. Because, you know, the hand-drawn animation takes much of its effect from the exaggeration and the most cool and exciting images come exactly when you breaking some rules. Understanding that is very important and that’s why we tend to use 3D models very carefully.

Currently we started to experiment with the soldier model. The funny thing happened with shot 35 – it’s the shot where the camera makes a long dolly out and all soldiers are thrown into the air. Initially we wanted to use soldier model as a base for drawing keyframes on top. But when we put the model into animation we found that the model looks very naturally as it is.

Considering that it will be masked with some vector elements, effects and dust we decided to use soldiers as pure 3D models in this shot. Of course that saved Nikolay a lot of efforts in the keyframes drawing.

Keyframes marked as to be done with 3D models

That’s everything I wanted to confess about our cheating. ^___^ As usual, you can see our progress for keyframes drawing on the image below. Don’t forget to check the gallery page to see the recent images of this week. We hope you like them. Stay tuned and have a great week!

Keyframes production sheet (08.04.2012)

Nikolay uses MyPaint to draw the keyframes and some edits are done in GIMP or Krita. Thanks to the GIMP’s ora plugin and native support for ora files in Krita we can seamlessly edit MyPaint files everywhere. Well, in fact Krita’s ora support isn’t that perfect (2.3.3 here), but we can live with that.

So, our basic working format is OpenRaster (ora). My task is to prepare all animatic images – compose them together with all reference data into ora files, so Nikolay can proceed directly to the drawing. We have a special production sheet to identify pending, prepared and finished keyframes. I also mark keyframes which are considered relatively “easy”.

Keyframes production sheet

Nikolay looks at this sheet when he needs to choose next keyframe to draw. After the keyframe is drawn he sends me ora file for review. My job is to look for style consistency and general quality issues. If the keyframe is accepted then Nikolay moves to next one in the list. If there is a issues then I put my notes onto separate layers together with some explanation sketches, send the file back and process repeats. On the images below you can see how it’s usually looks like.

Typical "work-in-progress" screen

Having a production sheet allows Nikolay to proceed with other keyframe while I’m doing review, so the work keeps to be intensive.

Also we can’t go without phone conversations – although Nikolay is quite familiar with the matter it takes from 10 to 30 minutes for discussions on each keyframe. Discussion can take place at any moment, so the mobile phone is an only option for that.  Although Nikolay lives in other town, we are lucky to reside in the same region – that allows us to have all talks at the flat rate.

Needless to say that we have certain conventions about file naming which allows us to keep all data in the order. I will not cover them here as it may sound boring and there is a high probability that those conventions will change with a time.

That’s all my notes about the current workflow. If you would like to see the finished keyframes please watch the recent images page at our wiki. Cheers!

Download remake-0.4-1.noarch.rpm
Download remake_0.4-1_all.deb
Download remake-0.4.tar.gz

This release delivers a number of major improvements and bugfixes. See full list of changes below.

• It is now possible to install “Remake” into “/usr/local” or any other system prefix. Use “./install-remake PREFIX” command for that. Uninstalling is also possible with “./uninstall-remake PREFIX”. DEB/RPM packages are also available for download.
• Special command to create new remake projects – “remake-manager create PROJECTNAME”. This command checks that all required software is installed, creates PROJECTNAME dir, copies default project template, automatically detects installed blender version and writes necessary configuration.
• Desktop integration for Gnome users – if you have nautilus-actions installed, then you can call “Remake” commands by right-clicking files in Nautilus.
• Support for Blender >= 2.62.
• If some software is missing then provide informative messages including hints on installation, configuration and links to download sources.
• Check if installed Blender version have FFMpeg support.
• New option in remake.conf – “BLENDER_VERSION”. Allows to set Blender version required to work with the project. If installed version of Blender is different, then throw error message.
• New option in remake.conf – “AUDIO_RATE”. Specifies default audio rate for the project audio files.
• Improve quality of samplerate conversion for mp3 files.
• New mode – “pack”. Packs file into zip archive together with all dependent files. Usage: “remake FILE pack”. Packed files are written into “packs/” subdirectory in your project root.
• Dependency detection uses cache now. Dramatically increases dependency detection speed.
• New option “-z” to disable cache.
• New option “-i” to ignore all errors in commands executed.

See also:

• Remake homepage
• Tutorial
• Man page

Part 1 – Setting up

In this part I will explain the purpose of using stickman and show how to prepare everything for tracing.

Download Part 1 (ogv, 25 Mb)

Part 2 – Tracing

The main tracing procedure is explained here. Notice that the version of Synfig Studio used in this screencast is very old – you can see different icons and even  Russian interface elements. I hope that will not distract you. ^_^

Download Part 2 (ogv, 9 Mb)

Part 3 – Compositing tricks

Here I will show some composition tricks that will help you in the tracing process.

Download Part 3 (ogv, 15 Mb)

Part 4 – Shadows

Final part of the series is about tracing shadows.

Download Part 4 (ogv, 43 Mb)

That’s it. I hope you haven’t tired of my mumbling. Enjoy! ^__^

Download remake-0.3.tar.gz

This time we have delivered a number of major improvements, and “3″ in release number have some symbolic meaning – among rendering of Blender and Synfig files we got support for rendering third type of animation – Pencil, we got new rendering mode that allows to get stereo 3D output and finally files of mp3 audio format are supported as well.

Here’s full list of changes:

• Support for rendering Pencil files (*.pcl). You need modified version of Pencil provided by MorevnaProject to have this feature working.
• New rendering mode: “stereo”. We were sponsored by our friends from CifroCity company to develop this feature by their request. You can use this mode to create 3D stereoscopic rendering of your Blender scenes. Just create two cameras for left and right eye and name them as “Left” and “Right” respectively. When launched in this mode Remake will automatically  render both views and stitch them into video file suitable for watching with your favourite 3D stereo player. See manual page for details.
• New rendering mode: “deps”. In this mode Remake will render dependent files only, but not the file itself. Very useful when you working with video sequence file (project.blend): “remake deps project.blend” will make sure that you have all footage rendering up to date and you don’t have to waste your time waiting when full sequence will be rendered.
• New “-c” option to select camera to render from in Blender files.
• Support for processing mp3 files (will output as wav).
• Compressed Synfig files (*.sifz) now supported as well.

See also:

• Remake homepage
• Tutorial

Download remake-0.2.tar.gz

What’s new:

• Support for the Blender 2.5x.
• New “-t” option to run multiple jobs in parallel when rendering footage.
• New “snapshot” feature – you can save the current rendering as video file to track your “work in progress” changes. This feature is especially useful when your project is under version control. See manual page for more information.

See also:

• About Remake
• Tutorial

Now all repositories are the “same level” – there’s no “super-repository” anymore. The “production” repository is replaced  by the “lib” repository, which is now of the same level as the “demo” one. For the cases when we need “synced” history view, that problem is gracefully solved by “git-subtree” and that results in much simpler structure and workflow.

Current repository users need to re-fetch all data according to new structure. Please wait while we updating “Contributor’s Guide” with new instructions.

EDIT: “Contributor’s Guide” updated. Have fun!

As I wrote some time ago, it’s purpose to automatically track changes in your project files and update rendered footage where needed.

“Remake” is released under GNU GPLv3 and available for download here.

There’s also nice tutorial about its usage.

For more information please visit project homepage.

We are successfully applying the principles of free software development to animation production, and for that reason some people used to think that those processes should be followed completely, but I think this is not correct. Let me point to some differences between the two activities.

The result of the software development process is a software package. Any software package is a tool, which helps a person to produce something – to do it faster, better, or even just to make it possible. Though it is the result of someone’s work, software is still a means to achieve some other result. So, to fill its purpose, software must be easy to use. It’s usage should be intuitive, or, to put it another way – predictable. Predictable behavior of software is good, unpredictable behavior (caused by bugs, crashes, non-intuitive UI, etc) is bad. That’s the key point.

Developers decide when to release a new version of software based on how stable (read “predictable”) the software is at the moment. The user can always try the unstable development version if he wants. He risks getting unpredictable (bad) behavior, but he doesn’t loose anything by trying, because later he will get his better (predictable) version anyway.

On the the other hand, an animated movie is a product of the entertainment industry. Entertainment is a way for a person to fight the daily routine. People watch movies to kill their boredom. To defeat boredom, to kindle interest, to attract viewers, a movie should be unpredictable. Unpredictable is good, predictable is bad. Do you see the difference?

Now, let me go a little further. In a good movie every little piece, every little detail works to build the final impression. Nothing is meaningless, everything is important. If a person stumbles onto the unfinished, “development” version before the author’s conception is implemented, his impression could be spoiled just because he watches something that hasn’t reached its climax yet. And that can’t be fixed. Because even if he watches the finished version, there is some chance that it will strike him as uninteresting, because he has already got his “dose of unpredictability.” That’s why the “release early, release often” rule doesn’t work for animation production. And it never will. Because of the different purposes of software and animation products.

Imagine if someone will render raw data one month earlier before the release, publish it, and spoil the impression for many watchers who will think that they are watching finished work. By keeping repositories in private mode we are leaving for ourselves the right to decide when the movie is in its finished state, which is critical for an animation project.

At the same time, the private mode of the repositories is kind of fictional. Anyone can get access to the sources at first request – just read “Contributor’s Guide”. Why such a weird scheme?

Well, the production of animation is quite a specific process and understanding the workflow and policies is necessary to be able to contribute. From that point of view, the “Contributor’s Guide” plays the role of some kind of bootcamp for a newbie contributor. Instead of rushing into the repository, he gets familiar with the structure, rules, and workflow first. I think that’s a good strategy.

So, that’s my thoughts and reasons. I hope I have explained the situation. Also, I would like to know what is the opinion of my readers on that question.

Last time I have a lot of work with Synfig Studio. Making Production Cuts video and directing some external Synfig animation projects lead me to the idea of improving morevnaproject’s rendering system.

Currently the rendering system is based on pure “make” and works the same way as typical build system used to compile Linux software: you write rules in special “Makefiles”, describing how to compile (in our case – render) your files. Also those rules contain dependencies between all your sources. That’s very cool – “make” utility tracks the changes in your files and when you tell it to rebuild/re-render your project, it looks if any of the dependent files changed or not and invokes build/render procedure only if the change happened. Very cool. It saves a lot of time and efforts. You don’t need to remember which files need to be re-rendered if you have changed something essential (like bike model or – eww! – lightning template). The bottomside is that Makefiles are quite complex for ordinary user, you need to maintain all dependencies by hand and keep them up to date. For small projects it’s too time consuming to set up make infrastructure. It’s very unlikely to expect that average user will study make rules and use them in the daily work. Sometimes you just need to quickly setup directory tree, do your work and archive (or trash) result when everything is done – and all that int 2 or 3 days – there’s no time to write all those rules.

Projects like automake and quickly lead me to the idea is to have a “bridge” application between pure “make” and the user. It should generate Makefiles on the fly from user request and then let “make” to do the rest of the work. That can be achieved by introducing a set of conventions about the directory structure of the project sources and developing the tool itself. Most probably the result will look like some kind of project template accompanied with control application. We plan to make it available to community for reuse in any other animation project.

I still not sure about the name for the tool. I am going to call it “remake”. Any other ideas? At this moment I can tell that the idea is implemented at 70%, so we still have some time to think. BTW, realization of the tool lead us to some project restructuring – expect changes in repositories soon.

List of dependencies (1) transformed into Makefile (2). In the final version dependencies will be detected automatically.

About further evolution of this idea. It can be a web frontend for git configured for animation content. That should include generating snapshots for commits, diffs for animations and automated rendering. That’s totally crazy idea – I’m aware,  that I have no hardware resources and, most importantly, no time to implement it in nearest future.

More about used software (most probably I should have name this post Random Software News, eh-heh-heh). As you know, morevnaproject is closely related with development of Synfig Studio. We had hard times since we started web infrastructure reorganization at synfig.org and there’s still a lot-lot of work to do. Most of things are still messed up, but we keep moving. Released 0.62.01 version promises to be much more stable than previous one as it resolves some annoying issues.

There’s another valuable step made related to Synfig – we have started writing official documentation. Of course it consumes much time (again), but it’s strategically important to get more users into Synfig, build solid and growing user community and thus, have more contributors for Morevna Project. We plan to release documentation in three media formats – online, pdf and printed book.

Some words about Synfig’s future. Of course it will be bright, happy, etc. But I’m not about that. I want to share another crazy idea popping into my head recently. Probably most crazy one. Often I watched a people coming to IRC asking how they can do interactive animations with Synfig like flash ones. Those requests used to irritate me. From the start Synfig was developed for high quality animation production, not for cheap web animations. Synfig’s visualization is slow, the animation needs to be rendered, rendered animation is huge, adding interaction to rendered video is a big problem… But time passed by, Synfig is changing, we got opengl branch… And suddenly I have realized: hey, why not? ^__^ If we will get opengl optimization, then we will get realtime rendering and that means Synfig’s files can be visualised on the client side. All people will need is the browser plugin.  Now, let’s imagine Synfig developers will add just a single new feature – a hyperlinks. Now synfig animation is not just an animation anymore, it’s hypertext!.. err… hyperanimation? Then suddenly from animation package Synfig turns into web authoring package. It is powerful for animation, it is free, it’s WYSIWYG, it’s format is readable like HTML – Synfig can beat flash here… maybe even HTML? Who knows…

You may notice that we had very few commits in out git repositories last time. The reason is that most artwork produced goes into drafts. I haven’t managed to find time to integrate them into git repository, but you can watch some of them on the wiki. These days I’m spending much time trying to improve my drawing skills. watching artbooks, especially Gainax ones – like “Groundworks of Evangelion” and “Gainax Artbook”. That pursuits my learning very well.

That’s all my thoughts for the moment. Stay tuned!