Complex inbetweening workflow

[Zachary Brown]

Hi folks,

As I learn OpenToonz, one thing I'm noticing is that the level strip is very linear. So for example, if I have a single base image, like a face, and I want to have several target versions of that face, each with a bunch of "inbetweened" images, it looks like I have to just keep track of which images are part of which sequence of inbetweens.

So for example, if the base image is #001, and the first modified view is image #010, I can have inbetweens in images #002-#009. But if I then create an image #020 for a second modified view of image #001, it'll take some shenanigans to create inbetweens in images #011-#019. But once I successfully create those inbetweens, it seems as though I then will need to find a way to keep track of which are the target images and which are the inbetweens; and the target images could be scattered around. In particular, the base image can only be immediately next to a single set of inbetweens. Other sets of inbetweens have to be more distant.

I'm just wondering how other people tend to deal with this. What sort of workflows have folks come up with to make this easier?

One possibility I'm considering is this: Have the identical base image in multiple columns of the xsheet, and use each column to define a single target image and single set of inbetweens between the base image and the target image. Then instead of naming the column to match the body part (or whatever), name it to match the transformation.

To use that system, I would simply use all the related columns as needed, having column 52 be visible for frames 1024-1096, then column 53 be visible for frames 1096-1139, and so on. All the related columns could be collected into a sub-x-sheet to keep them out of the way of other elements of the animation.

One problem with this is that if I have a plastic mesh on one of the columns, then any changes I make to that image will not be carried over into the identical images in other columns. So I basically would have to avoid the plastic tool if I used this technique. Which may not be so bad, since I'm using the whole inbetweening thing to do the animation. Still, I know the plastic tool and inbetweening can theoretically be combined to good effect, so it would be a shame to have to choose between them.

Another problem with this technique is just the overall clunkiness of the process. The number of columns in the sub-x-sheet could really mount, especially if a character is going from one secondary pose to another, instead of always from the primary pose to a secondary pose.

What other methods have people come up with for this situation? ... or am I missing something really simple?

Be well,

Zack

[Rodney]

Hmmm.... There are several methods you could use but inbetweening is an intuitive process where we generally can know where are keys are fairly easy.

.

The classical or traditional time tested and true method is to draw a timing chart on the first key drawing of the shot.

In the example you outlined you'd indicate 1 as your starting position and 11 as the end.  The breakdown inbetween(according to your example!) is frame 3... which would generally not be drawn next because it is not precisely 'in between' frames 1 and 11.  So frame 7 is mathematically your first inbetween. 

Note:  odd numbers especially for the keys are generally used in order to allow for animating on 2s with regard to the inbetweens.  It's certainly not impossible to see an even number but rarely as keys and when we do we automatically know the drawings are being animated on 1s (i.e. every frame).

In the example you first outline it sounds a bit to me like you are setting up a very very short sequence of 3 frames where frame 1 would have a timing chart on it like this:  

While this would be somewhat strange that is the scenario that would allow for creation of frame 2 as your first inbetween.

Technically speaking your first inbetween between frame 1 and 11 might be frame 7.

If the breakdown (first inbetween) is in fact frame 3 then what you should expect to see animated might be a very slow cushioning (slow in or ease in) as you arrive at frame 11.

But note that if such a timing was used we might only see frames 1, 3 and 11 indicated on the timing chart because all of the rest are very likely going to be mathematically inbetweened (i.e drawing exactly inbetween).

In your example, the animator most definitely will want to draw frame 3.  frames 4 through 10 could then be automatically generated (i.e. assigned to an inbetweener).

I suppose what I'm suggesting is that it would be a good habit to get into to learn and use timing charts not only because it will help in remembering where key drawings are but if you ever need to communicate that to someone else... bam.... there it will be there.

Added:  The extremes (storytelling drawings) are usually circled but I haven't done that in the attached timing charts.

[Rodney]

I don't know if this article will be particularly helpful but... it might... so I'll link it here.

It was a random article on timing that I felt contained some important thoughts on timing and inbetweening.

Note that this is an article that is being presented to 3D animators but the principles apply to animation across the board.

http://blog.animationmentor.com/timing-the-12-basic-principles-of-animation/

A bit of this might be too deep but having the exposure to the basic principles is imporant.

This is the stuff they are teaching to people that want to work in the industry.

http://blog.animationmentor.com/timing-the-12-basic-principles-of-animation/

[Rodney]

This probably says it better than I ever could:

http://tombancroft.blogspot.com/2012/03/timing-charts-for-traditional-animation.html

An important aspect of this is that this Timing thing we speak of is independent of the software and so the animation can move from one platform to another as needed.  In our case we just adjust our workflow so that it fits nicely with OpenToonz!  

Aside:  It would be nice if OpenToonz had a Heads up Display (widget) Timing Chart that stuck to our extremes or stayed on top of our drawings but I'm not entirely sure how that would work in an automated kind of way.  Almost all software on the market today was created without concern for those strange critters known as timing charts... 

[Zachary Brown]

Hi Rodney, thanks for the very interesting response and links!

I think it's possible I didn't clearly explain what I was trying to say in my first post. The stuff you wrote is very cool, but I think I'm probably asking about something different than what you answered.

So first of all, I'm talking about using the "auto-inbetween" feature of the level strip. So for example in the simplest case I've got image #1 and image #2, and I use OpenToonz features to generate X number of 'auto-inbetweens' to go between those two images.

Second, I'm talking about rigged characters whose primary source of animated behavior will not be hand-drawn frames, but instead will be keyframes of rotations and movements from the Animate Tool, shape changes from the Plastic Tool, and drag-n-drops of sequences of auto-inbetweened images from the level strip.

The specific issue I'm trying to address is when I have multiple available versions of a hand-drawn image, for example multiple poses of a face, and I want to have a well-organized set of auto-inbetweens that can animate the movements from any one of those poses, to any other one. So, from a front-facing face to a side-facing face; or from side-facing to 3/4-facing; etc.

The problem I tried very poorly to express originally, was how to find a good way to organize all those key images and the auto-generated inbetweens.

In other words, if all I have are 2 hand-drawn facial images, being a front view and a side view, then the problem is easily solved. I just have the front view at the top of the level strip, and the side view at the bottom, and X number of auto-inbetweens in the middle. No problem there. I can easily identify what I need when I need it, and drag the needed frames into the X-Sheet column.

But suppose I have a front view, a side view, and a 3/4 view. I'll want to have auto-inbetweens that go from front-to-side, front-to-3/4, and side-to-3/4.

How can I put all of that into a single level-strip, and still keep track of which are the original drawings, and which are the auto-inbetweens? That's the basic situation I'm trying to get at.

A key element here is that these images are not part of any pre-known narrative. I'm not using the level strip to create a single linear passage of time that expresses an existing storyline, and that would then be transferred directly from the level strip to a column in the X-Sheet. Instead, I might use a each series of auto-inbetweens throughout the project, at any point in a column, whenever the character looks to the side, or looks up, etc.

So, for any given character, there might be 10 or more distinct primare facial positions And a fully-connected graph of all the sets of auto-inbetweened images leading from any one of those positions, to any other one. So we could be talking about hundreds or thousands of images in the level strip.

And the question is, what's a good way to keep track of all that so it stays useful? I sort of outlined a possible solution in my original post, and I'm just curious what other approaches might be out there.

Be well,

Zack

[Jane Eyre]

If you are using vector or Toonz raster levels you could add a notation (K or fv or etc) in the corner of each keyframe with a style made only for notations. For each set, you’d want to wait and add the notation after using the inbetweener but before inbetweening the next set. Then when you are ready to render, just turn the alpha channel for that style to 0.

[Rodney]

I apologize for straying off topic.  I think I was more caught up in the possibilities of where you (and digital animation in general) could head rather than focusing on the issue at hand.

The principles I was related apply the same though... I just didn't communicate that well.

The issue I was trying to address is that the autoinbetween feature inbetween images... not necessarily frames and that was the aspect I was trying to maneuver around.

I suppose the point would be that those images that you are trying to autobetween are (or should be) key poses and therefore worthy of inbetweening.

I'm straying again... so I'll try to focus.  ;)

The basic answer to the question of how do you keep track is:

The images in the Level Strip are just that images.  Each level strip has a name or (usually) a letter designation that tells you exactly what it is.  This can be any name you want it to be AND each image in that level strip can be any number (i.e in whatever order) you wish it to be.  That is how you keep track of them... by name and number.  Those names/numbers then appear in the xsheet and can be swapped out very quickly.

This same basic principle is true of cut out puppet characters.

The images in the Level Strips are exposed in the xsheet.

Keyframes (the locking down of settings... not necesarrily the same thing as 'key frames' (two words) can then be used to manipulate position, rotation, scale, etc.

So... yes... the short answer.  Name your Levels and then have the images sorted in some logical order.

For instance (and unfortunately straying again...) with lipsync I would prefer to organize my 'phonemes' according to a Japanese sort order because... Nihongo is a phonetic language with simple phonetic structure.

A

I

U

E

O

KA

KI

KU

KE

KO

Sa

Shi

Tsu

Te

To

etc.

Basically there are just those 5  keys that repeat over and over again.

If using English for Lipsync a standard order might be the Preston Blair Phoneme set which is well known and usually the standard used.

So it would be good to sort those mouth shapes in that order.

Then when you are looking for a specific mouth shape you'll be able to easily find it.

To prevent the 'hundreds of thousands of images' in a level strip it would (in my estimation) be much better to save out sets of Level Strips and organize them in your asset folders in meaningful ways.   Then when needed look for and load those level strips.   We definitely don't want to load every asset for every session of animation.   There's no need.

So, another part of the answer (in my estimation) would be to organize your files (Levels Strips etc.) externally.

The good news there is that OpenToonz's Browser room can help you look through those and find what you need quickly (with icon previews and everything).

Sorry to drone on again.  I will reread your posts yet again and try to refine my thoughts further.

I know my response is a bit too much 'big picture' but you don't want to create workflow that works for you in only one instance when it can work for you in many.

[Rodney]

In the above... a set of specific mouth shapes say... from a 3/4 view might all be collected in one Level Strip.

My own personal goal with many assets is basically to create them so they can be 'turned' as if they were in 3D.

That generally means that a minimum of 9 images must be drawn in order to show that same object or character from top, bottom, right, left, front, back and 3/4 views.

Of course the more drawings the smoother the rotation of that object will appear.

Again, these same approaches (naming conventions and organizational hierarchies) are largely independent of what type of animation (handdrawn, cutout, 3D etc.)

Also:  From what I have seen the vast majority of OpenToonz users do not name their Levels much less label them in meaningful ways.

If you can do that you'll be ahead of the vast majority.    It can be very hard to know what V3 is when looking at the label in the xsheet.

Compare this to looking and seeing 'Charlie_RightArm_000'.  If the Level is saved in a folder named "Charlie" in the Drawings directory even better because now you can save space on the filename.

To me that tells me almost everything I need to include the numerical designator that would tell me that is the generic default used when there isn't anything special needed.

The numericals could coincide with the number of a scene but... the important thing would be that they meet your needs (and if in a studio... everyone in the studios needs).

 

[Zachary Brown]

Hi Rodney, thanks for the followup!

I actually hadn't thought about applying this to mouth shapes, but that's a great example.

So, thanks to your answer I now understand something I've been doing all this time -- I've been naming my X-Sheet columns, and also naming the Levels by right-clicking in the column and choosing "Level Settings". I couldn't see a reason to name the levels, since they were all just the same as the X-Sheet columns, but the tutorials said to do it, so I did it. Now I see that the Level names are used in the project files. So even though I haven't used the browser very much, all my directories are already nicely labeled.

What I'm hearing from your post is, aside from naming levels, once a level strip reaches the limit of what can usefully be expressed in a linear set of images, it should be saved into a file on its own in the scene folder, under the "drawings" folder of the project folder, so then when I need it I could load it up again. That way I won't have all those levels cluttering up the X-Sheet. Is that about right?

Be well,

Zack

[Rodney]

What I'm hearing from your post is, aside from naming levels, once a level strip reaches the limit of what can usefully be expressed in a linear set of images, it should be saved into a file on its own in the scene folder, under the "drawings" folder of the project folder, so then when I need it I could load it up again. That way I won't have all those levels cluttering up the X-Sheet. Is that about right?

I haven't got to the point of having any specific session get so complex that I had to make any tough decisions regarding things like that.

For the most part I set up a Scene and only deal with what is immediately needed in that.

In my estimation there are many good reasons not to overload a session with too many assets.

This isn't to say that OpenToonz isn't up to the task.

The specific situation would dictate but I can easily see a directory structure that contains copie of files for each shot (rather than all referencing the same file).

There is some danger in doing something like this too early in that we could lose the benefit of OpenToonz ability to cascade update all of the assets say should a character design change.

I hesitate to suggest specific approaches but as long as the assets were locked down and not going to change I could easily see something like the following directory structure:

Scene001

<all the files required for scene 1>

Scene002

Copy all of the files from Scene 1 into Scene 2 folder and then delete everything out of the directory that is not needed.

Add new assets as required emplacing proxies (temporary standins) where an asset is missing.

Scene003

Copy all assets from Scene 2 into Scene 4 folder (if needed)

etc.

One benefit to current technology is that file movement doesnt actually need to occur and all of the assets can be referenced from a central location.

There can however be problems with this if an asset or character changes... and they almost always do.

So an update to an asset could break a scene anywhere else in the production if the same asset is linked.

But yes, I wouldn't say that you always need to save Levels... I don't do that although I am increasingly doing it so that I know exactly where they are located and what they are named.  The Levels are automatically saved when we save a Scene so it's not like we should lose anything if we don't manually save a level.  I think you've got the right idea.

Keep in mind that in a larger production there would be someone whose job it is to assist with asset management.

In our case it may be that we just put on a different hat from time to time and work our Asset Management magic so that when we put our animator hat back on we can fully concentrate on animating... and not worry about missing assets.

I suppose in a perfect world all assets would be saved to one place (a central repository where things become 'read only' upon approval as production ready assets.  The assets would then be copied out locally for use by those who need them.  The deliverables produced would then be sent on down the line where they would be incorporated into the final product.  Once complete all the local project files would be zipped up and submitted as well just in case they were also needed.  Most of the production work I've been involved in followed that basic pipeline methodology although with considerably more chaos thrown in for good measure..

P.S.  I'm glad to hear you've accidentally been naming everything.  That's a great habit to have this early in the game.

It can be very painful to know you have an asset but not recall where you put it and then have to open up and look at a ton of files generically named.

[beeheemooth]

Hi, Zack!

A year ago, I was interested in the same questions as you. In this video (here I asked for advice on the ungrouping of vector groups that are formed after the merging of levels), I demonstrate my workflow.

https://www.youtube.com/watch?v=LhT1WH8_8zI

 I also thought about how to do so that autonibetweening (1 - 20) does not overlap (1 - 6 - 15 - 20) My idea was to use two (at least) level: the second for inbetweening vector lines, and The first one is the collector of all animated lines.

 This approach has its pros and cons.

Pros: after clearing the second level, it can be used for the next inbetweens, since empty frames on Xsheet already have the necessary timing for this. If there are parts with a different timing, you can make one more level for them, and merge it with the first one.

 Cons: if you multiply a large number of vectors many times and want to correct something in the first level, then you can not use the Selection Tool because of the formed hierarchical groups. It is difficult to edit this level.

(sorry my english, i use Google Translator)