Animatic and Script(s)

  / by Matt

Well, the others haven’t posted anything recently, so I’d better give an update on what’s been happening here! Work has been continuing thick and fast – we’ve given tutorial workshops here in Amsterdam (which will be posted about soon, I hope), Ton has still been coding like a madman, and over the last weeks, we’ve been working on putting together our secondary animatic, with the script broken down into individual shots by Bassam.

We did a very preliminary animatic (the ‘crappymatic’) a while ago, before the script was fully broken down, as a bit of a practise run to flesh out some ideas. It helped, but it was nowhere near anything final, and of course purposefully dodgy. For this one, we’d been working on scenes in parallel and in tandem, and we assembled them together over the last few days of last week to see the then current state of the film in its entirety. We’ve also been using the structure of the script, with the intention that we can take the .blend files used in the animatic, and revise them by replacing character models, re-doing the animation, building the sets, to gradually turn them into the final shots.

Here’s an example of one of the scenes in the animatic, actually one that has subsequently been partially cut/revised, for you to download. Of course it’s an animatic, with proxy models, very rough animation and blocked out sets. Please, no complaints that it’s not Pixar quality yet! :)

Animatic screenshot
» 4.3 MB MPEG4 | 4.5 MB Xvid AVI

Rather than being anything intended for presentation to other people, the animatic is a tool for ourselves. It’s a tool for communication, and also for review – it’s much easier to use the animatic to see the quality and flow of the story than it is by reading the script itself. It was a very interesting and productive experience to see it all together as one. Some of the scenes were working very nicely, but some of them weren’t working at all, and seeing it all together like this was a catalyst for some of our dissatisfaction with the script to come out.

We had big problems with the dialogue, and the amount of it. It wasn’t really doing what we wanted, and there were far too many lines for what the characters were actually supposed to be saying. Particularly since lipsync takes such a huge amount of time and effort to animate well, this was quite scary. We realised, seeing the words together with the images, that there was a lot of redundancy. In many occasions, we wouldn’t need to have the characters say something if we could show it through acting or through the sets and props, and we could cut and combine many of the lines to be more concise and direct.

So, we’ve taken this opportunity (probably the last we will have) to make some revisions to the script, to give it more purpose and direction, and to give the characters more motivation. Bassam and Ton worked over the weekend making edits and cuts, and now things are looking much better. Although time is quickly running out, I don’t really see this as going back and losing time – it’s more like a natural progression. It took us this amount of time to get to this stage and see that we needed to make changes, so we’re revising as we go.

The other script

While making this animatic, we had the help of some nice Python scripting work by Basse for controlling the camera changes, and also to display subtitles with the dialogue. The script requires a recent version of bf-blender (the version 2.40 alpha 2 should be fine) since it uses Python scripting access to the Timeline markers.

You can download a demo file here that includes the script as a packed text file ( It uses script links, so remember to enable them in the script buttons window, and if necessary, add as a Scene script link on FrameChanged.

Subtitles python script
» camera_subtitles.blend

There are instructions in the .blend file on how to use it – they all involve markers in the Timeline. It’s very convenient this way, as it’s very quick to adjust timing and cuts. It would be nice too if we could influence objects’ animation with Timeline markers as well, perhaps the upcoming Python Ipo drivers will allow us to do this. If you have any questions about this script, I’m sure Basse would be happy to answer them here!

« | »

62 Responses to “Animatic and Script(s)”

  1. Francisco Ortiz said on 11 Nov, 2005:

    Dawn looks like a Bug! A part of my message dosen’t appear.BTFW i dissagree whith Johan.

  2. alt said on 12 Nov, 2005:

    Well well well, I want to critic too!

    But not the animation as it’s animatic and only marks camera movement, angles and picture sizes. I would have used less character movement (and probably scanned storyboard). Just stick figures to help with composition.

    Why does the camera pans around the boat? If you wan’t to show that they are in the middle of something huge, why not use extreme long shot with still camera? If you want to show they are in a boat then why rotate the camera mindlessly?
    I don’t know what was the previous shot, so maybe it makes sense in the larger picture. But unnecessary camera movement is the most common crap-feature of all 3d-shorts, because it’s easy and has (wrongly) perceived w0w-factor. And when something is easy then it’s easily used without reason. Rotating demoscene cameras only manage to irritate. Rotating camera also takes viewers attention away from the character who starts to hear something, his listening and reaction are too fast and in addition he is hidden behind the other character!

    Ear shot, well, it’s just an ear. Why do viewers need to see an ear? Don’t they hear the singing on the soundtrack? If it’s supposed to mark listening, that’s better to do with shot of the characters trying to be very tense (not computer still) and trying to hear.. UNTIL!

    I would also suggest using fewer cuts while they are in boat (it seems there’s one unnecessary closeup of the bigger guy reacting). Scene seems to be temporally continuous and slow-paced and about singing (probably ethereal and angelic) so no need to do fast pacing except when they fall, and that would stand out if everything else gets prolonged.
    Also you cut from medium shots to almost medium shots pretty constantly. It makes it a little boring (maybe it is supposed to be, I don’t know). It could be spiced up by using bigger size changes between shots, something around two units.

    But anyway the storytelling was quite clear (dialog naturally helps but action should be understandable without dialog).

    That’s my whining for now, feel free to ignore. (I have a flu and I needed something to do :)

  3. rubbleman said on 12 Nov, 2005:

    Suddenly everyones’s playing with mud and light sabres…
    Give them a break people. They are doing just fine.
    This is a terrific project and experience for these young guys from across the world to be doing and I cheer them on.
    Don’t forget all the great things and refinements that are going into the code that everyone gets to benefit from.
    They are doing a wonderful job to pack so much into the 6 months.
    A big thankyou to Ton and all who are participating in this for giving of themselves for the Blender mission :o)

  4. Bassam said on 12 Nov, 2005:

    Perhaps two things can clear up some of the boat criticisms:
    the camera isn’t rotating; the boat is going around in circles, and the boat isn’t a boat- the shot after they fall out is supposed to reveal both facts, but doesn’t show the rotating bit, becuase the rough/animatic animation made it easier to do this way.
    However.. the scene has been cut (sadly) so I don’t think we’ll ever get the chance to see the refined version.
    As to too much medium shots… yah, probably true, though in this case, forced by not wanting to reveal the non-boatness too early.
    criticism doesn’t bother me- can save us from big mistakes sometimes and is always interesting to hear an honest description of someone’s reaction on viewing things.. indeed, we had some people in to view the animatic who had no idea at all about the project- their reactions were very educational (both positive and negative).
    oh, and thanks for the nice comments, everyone!

  5. wu said on 13 Nov, 2005:

    just curious about this project, it seems very top secret.
    but will their in the future of this site be a gallery of characters and a long summary of the story. it could be dangerous in the marketing/raising money for this because it does not have the appeal of visiable characters and ideas that make people want to buy the dvd. i would really push you to set up a section that gives a good outline of the story and characters, and a gallery of characters and settings.

    for now all anyone knows is that this is a project developed to improve blender, and the only images are oranges and the scary looking members of project orange, haha, that was a joke. anyway, i think it would only help you sales to have somthing people could get excited about owning.

    good luck to you all, and post some character shots and story summary already!!!!!!!! or i will eat your childeren!!!!!

  6. Johan said on 13 Nov, 2005:

    Bassam- about bone deformation…

    In my experience bones tend to ‘snap’ whatever shape they are deforming. Weight painting helps to reduce this ‘snap’ effect by creating ‘lag’, but it does not really get rid of it.

    This extreme deformation is evident in the animatic (note the extreme angle bend of the elbows).

    I was wondering- do you guys struggle with this problem? Do you have any suggestions for Blender users, workarounds or could possibly post a .blend file showing some good muscle deformation/constraints/degrees of freedom etc?

  7. Bassam said on 13 Nov, 2005:

    johan.. keep in mind those are proxy models, not finals.
    Forgive me if I confused what you are talking about: things like “snap” and “lag” are what I think of as time domain issues- deformation has nothing to do with it. If you mean deformation fixing then, yes there are several options:
    1- modelling for animation (big topic there)
    2- fan setups: you can have multiple bones (or at least one) for instance, at the forearm, with copy rot constraints at different influences. smooths the bend and helps the arm “tube” from flattening.
    3-shapes! you can take advantage of several new features in cvs:
    the modifier stack and “crazy space” lets you model in the deformed pose of the armature, to fix the deformation. save that as a new shape (make sure you have the basis shape created first)
    and then use the angle of the bone to drive the deformation fix.
    we’ll be using all three for the finals

    I don’t believe in limiting rotations- extremer than possible limits are useful to animators, it’s always “ok” to break the joint in for instance 1 frame, if done right it can read in interesting ways. I do like DOF locking (not the same as limits) where I can lock a joint (either in IK chains or in transform panel) from rotating in undesireable angles.

  8. Johan said on 14 Nov, 2005:

    Bassam- thanks. I have not thought of fan setups.

    You don’t mention the ‘stretch to’ constraint. Do you use that at all (Or has shape keys made that feature redundant)?

  9. Bassam said on 14 Nov, 2005:

    Johan: yes I use stretch to- its not redundant. I don’t think we’ll do automatic bicep bulging in this animation- muscle bulge isn’t just a function of bone position- it has to do both with the angle of the bone and the degree of resistance it is pushing- indeed, it is possible to flex a muscle without moving the skelaton at all, either by flexing the opposing muscle, or by pushing against an immovable object…
    I used stretch to in the past to assist in shoulder deformation. I probably will in this movie too, though I haven’t started cleaning up the deformation for the characters yet.

  10. Genbod said on 14 Nov, 2005:

    I think my question got hidden behind those extremely long critiques. Would any one be able to answer my question from Nov. 10? I am not trying to be pushy, I am just really curious is all.

  11. Myster_EE said on 15 Nov, 2005:


    I’m pretty sure that they do almost all of it over. And since the scene was cut, It’s pretty much a moot point anyway.

    Unless you’re asking about animatic’s in general…

    Of which I have no Idea. But in my experience, It’s extremely difficult to rig a model with a skeleton, when the skeleton was made for a different model. For example, you may have the incorrect number of bones for the face, or for the fingers or something like that, and then you have to do that part over again anyway, (Not to mention the work of assigning each vertex to a skeleton). Not that that part’s hard, just tedious.

    But really, they should be answering.

  12. rogper said on 18 Nov, 2005:

    In the post 28 Bassam said:

    “We’d like to publish the full openEXR rendered frames too, but here we run into a filesize problem”

    Have you tried to compress the openEXR files in ZIP or RAR?
    Whit WinRAR (not freeware, but close enough) I get a lossless size reduction of 97% in a 30 Mb HD 1080p 32-bit Float point uncompressed openEXR image.
    So lets say that you have a 15000 frames movie (close to10 min.), multiply by 0.89 Mb (is the image size after the RAR compression) and you’ll end up whit 13350 Mb, or, lets say 14 Gb maximum… where talking of two Dual layer DVD’s and still a leftover space for some of the candy tasting high resolution sketch’s, crazy drawings, incomprehensive notes and wildfire mate paintings. Quite reasonable in my opinion.

    P.S.: I don’t have WinZIP, so I couldn’t test it, but compressing to ZIP in WinRAR gives me an even more reduced file size.

    Shine on Dudes! … ;-)