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!

read more…

Production Pipeline (click on image to enlarge)

Arrow, pointing from a task block A to a task block B, means what you need to complete task A before doing task B.

EDIT: You can download source OpenOffice.org Draw file here.

Download

Here’s the latest version of camera widget: camera-view-0.3.sifz.

License: Public Domain.

You could find instructions on it’s usage below.

Tutorial

Some synfig users got confused about the managing ValueBase Nodes of imported canvases. This tutorial demonstrates the usage of camera widget and also shows how this problem is solved in synfig-fu.

Download camera-view-0.3.sifz (camera widget itself) and example.sifz (background which we will pan and zoom). Rename camera-view-0.3.sifz to camera-view-example.sifz – this will be a “instance” of camera widget containing pan/zoom data for particular file (example.sifz).

Open camera-view-example.sifz in Synfig Studio. The red border shows the area visible in camera view. You could manipulate camera by clicking on the black semi-transparent box and dragging the widget ducks.

Select “File” -> “Import” command, choose example.sifz file and press OK. The example will be placed on top of all layers. Place it at the bottom of the layers stack.

Go to the Children panel. Here you can see “camera view” ValueBase Node checkbox. It allows to switch between view from the camera and arbitrary view.

But the example.sifz file contains its own ValueBase Nodes which are not shown here. To get access to them just open the example.sifz (but keep leave camera-view-example.sifz opened).

Switch to the just opened canvas window and look at the Children Panel. There you will see ValueBase Nodes belonging to example.sifz file. Modify the “a_sh” ValueBase Node. You will notice, what  modification will affect not only example.sifz file, but camera-view-example.sifz too. That’s because the example.sifz was linked to the camera-view-example.sifz file during import.

So, here’s the workflow: if we want to change the camera animation, we will work in the camera-view-example.sifz window, but if we want to change the animation which we pan or zoom, we just switching to the example.sifz window and work there.

That’s all for today, good luck!