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!

When we just started we have used a forum software set up in a local network. It was our test workflow, that’s why all titles on screenshots are in Russian.

The forum was split into categories and every thread represents a scene or a library element (we called such elements “tasks”). Also there were threads containing documentation about project and used software.

When a person wanted to work on particular task, he just downloading the archive containing task files from the last message of the task thread. Then he had to check if some library elements used in task have new versions and update them. After finishing work, contributor archiving the resulting task files and uploading them to the forum. Such usage of forum software for keeping project files had obvious advantages:

• Easy to use for contributor
• Version control implemented through forum messages
• It is easy to discuss the changes

That approach works very well, especially because the project was structured as relatively independent modules – scenes (thanks to storyboard). But during the 3 months of work following disadvantages were revealed:

• Every user should update all files related to his current task by hand
• Uploading a set of files is a time consuming process
• There is no mechanism of tracking changes in working copy
• Non effective storage of file versions
• Lot of work needed to construct full working tree of project

At that time every scene have been rendered by hand and then inserted into the montage. We started to realize what for such huge (and quite ambitious) project we need something what will eliminate such routine tasks. Then we come to idea of using “make” for this. Digging deeper into the problem it’s become clear, what the best way to implement project build system is to make a solid project tree. That made the future use of forum software for storage the project data impossible.

Then there was a deep research of different version control systems (svn, bzr, mercurial, git) and finally we are stayed with git. But that’s another story.

Imagine we have a model of… mmm… bike! And as you could see from storyboard bike is appearing on many scenes of Morevna Project demo. We do not want to include the full copy of a bike because every time we will change the original model, we will need to re-insert it into each scene and (sic!) animate it again.

Consider, what it is unavoidable to make changes in the model after it already inserted in the scenes and process of animation already begun. We can’t design the model from start till the very end – there is always something to fix during the usage. Also it could be handy to insert unfinished yet model to the scene to see how it will look, and let one artist to work on the scene and other continue develop model (like we did for truck model in scene 54).

In other words we want each scene where model is used to update automatically when the file with model updated. That implies:

• Applying all modifications done in the original model file to the model in the scene (including newly created objects);
• Keeping animation applied to the model in current scene.

That’s why we are using blender’s feature to link data from one file to another.

We just briefly describe process of linking in blender 2.46, paying attention to some tricks and unobvious moments.

Ok, if we want to link some model into the current scene we just go “File > Append or Link” menu. In the appeared dialog enable the “Link” button instead of “Append”. To keep our files transferable, we are also enbling the “Relative paths” button, but in this case current blender file should be saved first.

Next, search and click on the file with a model, then choose what you would like to import. We are choosing the “Scene”, cause we want to import the whole scene containing object. Then choose the scene name you would like to import. For Morevna Project we are always naming the scene containing model as the .blend file named, i.e. in file “bike.blend” we will choose scene called “bike”.

After you click “Load library”, a scene called “bike” will appear in current file. A linked scene.  But you can not move or edit linked data from current file.

The problem is solved with the help of Proxy objects. Just select the linked object in the scene and press Crl+Alt+P. Huh? No luck? OK, as I mentioned above, the linked data could not be edited. When we pressing Crl+Alt+P it issues he creation of the proxy object in the current scene. But our current scene now is linked one! So it couldn’t be edited and the proxy isn’t created.

So, all we have to do is to create a new scene where our action take place, link objects there and after that create proxies in that scene. C’mon, create a scene and name it… let’s say “54″. We are always naming them as a number, representing corresponding scene number in storyboard. Then return to the scene “bike” select all objects (A) and link them (Ctrl+L > “To Scene…”) to the scene we just created – “54″.

Now, just go to the newly created scene, you will see the bike there. Select object, you wish to modify and press Crl+Alt+P. Now it could be moved and animated.

But here’s comes another issue. Creation of a proxy means creation of the object, which comes as agent between current scene and linked data. That means all modifiers for current object what applied in the original file (like Subsurf and Mirror) will be lost after creation of proxy for it. Also, all materials linked to the object (not to the mesh) will be lost.

For example, if we want turn a wheel of a bike, we will create a proxy and will be able to turn it, but we will loose Subsurf modifier. Of course, we could apply it again to the proxy in current file, but that’s no good, cause if we modify Subsurf’s parameters in original file, it won’t be reflected in our scenes.

We could suggest a little workaround to fix that. But before that we should get rid of the wheel proxy. Just delete wheel object from scene “54″. It’s okay, cause we could link (CTRL+L) it again from scene “bike”. If we not delete proxy object, when we will link wheel again from “bike” scene to “54″, the proxy will continue it’s existence and will keep performed transformation. It’s a good behaviour, but not what we want now – we just want to get rid of the proxy. Another way is just Undo (CTRL+Z) if you have enough undo steps available.

Ok, let’s proceed. In the original file, containing model (bike.blend) we are creating an Empty (SPACE > Add > Empty) and parenting (CTRL+P) the wheel to it.

After that, when we reopen the scene, containing linked bike, the empty will appear there on a scene bike. Cause we added a new object, it is not appears on the main action scene though. So we need to go to the bike scene, and again: select all (A), Link (Ctrl+L) > “To scene…” > “54″. The scene will be updated.

Now we can go to the scenne “54″, select the Empty and make a proxy for it. Nothing wil be lost – no modifiers or materials appled to the Empty, but the wheel object will follow the Empty object transformations, cause it’s parenting to it in the model file.

That’s all tricks about reusing models workflow.

If you updated the model, the changes will be reflected automatically after reloading the scene, where this model was used. As I mentioned above, if new objects were added to the model, you need to make additional steps – go to the linked scene, select all, and CTRL+L to scene where the action takes place. New objects will be linked together with old ones, but the proxies position and animation will be kept. That’s just what we need.

One last thing: watch your linked files! If you open scene file having one of the linked files unavailable, the blender displays a “WARNING IN CONSOLE” message and all data from unavailable linked scenes will disappear. If you’ll save file after that, the lost linked data couldn’t be recovered even after you’ll return linked files in place. Keep that in mind.

Good luck!