auto-inbetween feature gives me bad inbetweens

165 views
Skip to first unread message

Tyrzin Paska Kynä

unread,
Jul 24, 2018, 4:35:30 AM7/24/18
to OpenToonz Users Forum
Auto-inbetween should generate shapes which are exactly intermediate between 2 shapes from 2 frames, and I get some wacky lines which are not part of the original shapes. https://youtu.be/-H4zun92uR0

Rodney

unread,
Jul 24, 2018, 10:57:04 AM7/24/18
to OpenToonz Users Forum
Tryzin,
Nice character!

I played with this problem for quite awhile and didn't come up with any truly useful solution.
Some of my exploration went out into different territory because I was trying to replicate your drawing and shapes and that of course only made autoinbetweening associations worse.

A few take aways from my wanderings include...

It may be easier to manipulate some inbetweens via other methods such as skewing a copy of the drawing or using the plastic tool.
I came very close to getting things to work with my version of your character but when I came to the ear... my manipulation required changes to the start or end targets and so tended not to work.
I didn't explore plastic tool manipulation because it was too far afield for your topic.

I am curious if the vector eye pupil and the surrounding white of the eye in your character are two distinct shapes.  
It seems to me that wherever OT has to guess how to proceed with an open area (in your case the location where the lines meet to form an oval/ellipse/shape that's the likely place where shapes will deform.  I have seen something similar with drawing with the snap feature in that end lines meeting other end lines often don't terminate in compatible bias angles... they meet but with un-smooth deformity (if I had to guess and I do... I'd say the deformity forms toward the side closest to where the origin of the vector line came from).

I'm sorry I don't have any good news for you here.
One thing you could do is isolate those areas to simplify your auto-inbetweening.
auto-inbetween the shapes that are working optimally and then via secondary 'layer' (column/level) resolve the other areas.  In the case of eyes and eyebrows (and mouth in cases of lip sync) you'd likely wan those on separate levels anyway).
Combine everything later after getting the desired result.

Knowing more about the specifics of the vector lines you are working with will help developers see exactly what is going on so if you can provide some example files that demonstrate the problem that problem can be further isolated.

So, with apologies for messing with your character... I learned a lot trying to replicate the problem.
Unfortunately not anything that specifically addresses your issue.  :(
Hopefully someone else can steer us down the right road.
NiceCharacter.jpg

joshua shute

unread,
Jul 24, 2018, 12:27:14 PM7/24/18
to OpenToonz Users Forum
autoinbetweening removes control points as it creates drawings which is great in concept but the curves it creates can be too smooth and the angles of bezier handles can be pretty far off. the solution is to add in control points that the computer can't remove. enter the cutter tool. the computer doesn't remove ends of strokes so adding a cut or two to any of the curved strokes will help to solidify those shapes. since what you're ultimately doing is creating more strokes within your drawing, you will need to be systematic about the order and placement of your cuts in both drawings being autoinbetweened.

Tyrzin Paska Kynä

unread,
Jul 24, 2018, 5:59:19 PM7/24/18
to opento...@googlegroups.com
Rodney
Yeah I kinda figured that it would be because of the round shapes. I've been using a workaround for this which is just me using the iron tool on the spot where the artifacts take place, tho it's 1 extra step which makes this issue noteworthy. Auto-inbetween should make perfect inbetweens, so this current issue needs some fixing. Of course, there are better ideas to actually fix the vector math in this but I was wondering a workaround that isn't a feature yet, it's that you could subdivide the control points in your strokes so there are not bezier curve ruining the middle parts of round shapes when they get inbetweened. 

I added a .pli file into this reply for further inspection.

K.pli

Rodney

unread,
Jul 25, 2018, 2:49:33 PM7/25/18
to OpenToonz Users Forum
Thanks for the test files.
Much appreciated.  That really tells the tale.

It's interesting to note that generally speaking we don't want a lot of control points in our drawings but in this case... a rarity I say... there are too few.
That is to say the number of control points generated by the autoinbetweening.

More testing!

Rodney

unread,
Jul 25, 2018, 3:04:18 PM7/25/18
to opento...@googlegroups.com
Tyrzin,
Here's something well worth investigating...

If we look at the eye shape of the extremes that are about to be auto-inbetweened what I note is that the first is open ended and the latter is closed.
This should be expected to cause an incongruity.

Try making sure the troublesome shapes are both closed or both opened.


Added:  a problem with simply editing the current vector lines is that editing renumbers the stroke order and presumably direction of strokes.
I'm not sure how to defeat that yet.

Edit: That doesn't solve the issue either but it adds a bit to the mix.
And... it doesn't help that even a copy/paste can mess up auto-inbetweening.

Attached:  a successful auto-tween of the shapes in question.
I need to record the workflow involved as it could lead to a few possible approaches to resolving auto-tween problems.
The initial thing was to check for open shapes vs closed shapes.
With circles the open shapes appear to be problematic.
The.. a copy paste but... making sure we get rid of the original so that we are working with two copies of the original... not the original and a copy. (this can be important for troublesome shapes)
Then adjust one of the copies as necessary.
Auto-inbetween.
The results should come out well.
The key here for the problematic shapes appears to be that of starting from a common shape.
This is not easy to do especially when two shape may look the same but are not.

Keye.pli

openanim

unread,
Oct 8, 2018, 2:52:29 PM10/8/18
to opento...@googlegroups.com
@ Tyrzin Paska Kynä I was wondering if you could move your subject in the feature request section ?

I agree with you, and I would like to submit some areas of improvement as well.

Even if that does not answer your direct concerns. I think that in all cases, the theme remains the improvement of the tweening feature.

And that would avoid creating an extra topic, I guess. What do you think ?

Tyrzin Paska Kynä

unread,
Oct 12, 2018, 12:43:47 PM10/12/18
to OpenToonz Users Forum
I dunno how to move my subject to another category, but if you think that it would help my issue then I would like to move this subject.

Rodney

unread,
Oct 12, 2018, 2:10:00 PM10/12/18
to opento...@googlegroups.com
At the top of the forum/post there is an icon/tag that show what category the topic belongs to.
Clicking on that will allow you to see the various categories and pick the one desired.

I've now set the topic to Feature Request.. but feel free to change it as you like.
Personally I don't see this as a feature request as it doesn't quite fit that.
The feature as is though... it's doing what it is designed to do now.
A new topic should likely be created that outlines what a new implementation would provide... i.e. what success might look like.

There are different aspects to this auto=inbetweening so a hard look of the current process might be in order even if only to educate ourselves.

If we can demonstrate an actual Bug in the code that is causing a problem... that's perhaps even better because a report can be placed on github to resolve the problem.
There is no category for 'Bug Report' here in the OT Forum because github is the proper forum for those.
While ferreting out the cause of a bug the ideal category might be 'Troubleshooting'.


Added:  A difficulty in almost all software with auto-inbetweening is that round shapes often don't get their line biases recorded, stored and processed smoothly (for any number of reasons).
Perhaps a useful look at the code would be to examine how that data is maintained and processed so that the math/algorithm can be further optimized.
A logical way forward would be to examine closely a very simple setup that produces 'correct' results.
Then examine a similarly simple setup with 'incorrect' results.
We likely can do this by extracting elements from you Project @Tyrzin.





openanim

unread,
Nov 6, 2018, 7:08:13 PM11/6/18
to OpenToonz Users Forum
Rodney I was also hesitant to open a topic like troubleshing from start. I find that in fact it is astride between the two. But in short these are just words lol... to avoid any confusion, I opened a new topic on your advice.

Sorry Tyrzin Paska Kynä for the inconvenience.

openanim

unread,
Nov 6, 2018, 7:14:40 PM11/6/18
to OpenToonz Users Forum
I reproduced your drawing, I had no problem with geometry tools. So I will advise you to go to them for round shapes.
Reply all
Reply to author
Forward
0 new messages