Take a look at this in-betweening technique in a recent ‘two-minute paper’ video: https://youtu.be/mb6WJ34xQXg
After some training, there is quite some realistic in-between generated for virtual humans.
My point is there in no "formula" you can use, since it's not (just) about "smooth" motion in 2D specifically.
In 2D animation, also always do "breakdowns" between key poses and those are absolutely artistic decisions that cannot be automated (at least without doing a selection step—you could probably automate, e.g. generating 32 different variations and then allow the user to select the breakdown they like best—same with inbetweens, you could allow the user to select the style—but at that point it's only barely ML).
this reminds me of an old XP-era program i had in the late 90s. every now and then I try looking for that program but can never find it (I thought it was called morpheus or something similar).
Anyways, i have something fun and nostalgic to play with for tonight
1. That Stack Overflow question is about MediaRecorder, which is encoding. It’s quite reasonable for a browser to support decoding (playing) a format but not encoding in that format.
2. That MDN page says nothing at all about the VP9/Firefox/hardware support combination—in fact it essentially says hardware support isn’t needed (“VP9 is widely supported by browsers, and hardware implementations of the codec are fairly common”). The other point it talks of with hardware support is saying that Media Source Extensions is only available for VP9 if no H.264 hardware decoder is available (which seems at first blush a curious restriction to make).
Wrt MDN, it may have been a misunderstanding. One para says it's preferable to use VP9 over VP8, the next is:
> "3] Firefox only supports VP8 in MSE when no H.264 hardware decoder is available." //
Which I took to mean, if there is a hardware decoder then it would support the better scheme, VP9. But I realise it's ambiguous. It also notes WebRTC requires support of VP8, so the interpretation
It would be weird of availability of a hardware decoder meant that support for VPx was then completely lacking, when it could be provided when there was no such decoder. But clearly I only skimmed the sources, so if you're asserting that's true...?
No, it’s definitely saying “if there is a H.264 hardware encoder available, MSE does not support VP8/VP9; but if there isn’t, then VP8/VP9 support under MSE is enabled”. There is no ambiguity in the wording.
It’s a curious restriction, but I suspect it’s to do with the use cases for MSE and perhaps some inferiorities of VP8 and VP9 codecs for the MSE use cases, though I’m not sure. Adaptive bitrate streaming is caring a bit more about the trade-offs in network, CPU and whatnot, so preferring a codec with hardware support is perhaps reasonable—though I do wonder why it wouldn’t still have VP8 if it had a hardware decoder. I certainly don’t know the details of all this, but the wording on MDN is very clear.
Remember also that WebRTC requiring VP8 doesn’t imply that anything else in the browser support VP8. Safari 11, for example, supports WebRTC but doesn’t support WebM or indeed VP8 anywhere else. Only Safari 14 starts to support WebM, and there only from Big Sur on.
IIRC, Disney was investing heavily into computing starting in the 90s, including inbetweening automation. Even John Lasseter promoted computer-generated imageries as a way to reallocate animators' time from "gruntwork" to more creative processes.
In Japan, most of animation still involves paper. Inbetweening is treated more as a craft, and the best animators still do inbetweening for top-of-the-industry projects like for Studio Ghibli and Studio Khara.
It is a shame that this only supports Chrome/Chromium. As I'm not willing to take the performance and privacy hits, I won't bother with this application until the necessary technical fixes are made. No matter how small of a group we are, Firefox/Safari users should be taken into consideration and could be the best advocates for your animation service.
Such user agent sniffing should be strenuously avoided. If there’s a particular feature you need, such as WebM with the VP9 codec, do feature detection instead:
if (!document.createElement('video').canPlayType('video/webm;codecs="vp9"')) {
location.replace("https://bestsnip.com/browser_not_supported/");
}
(For reference, that canPlayType call returns "probably" for me on Firefox and Chrome, and would return an empty string in an environment that didn’t support WebM or the VP9 codec.)
Nice, reminds me of discovering Macromedia Flash 3 and trying out their "Tweening" feature. The good old days when the "tech stack" were things like Macromedia Flash and Paintshop Pro.
The website seems to suggest that Firefox doesn't support VP9, but my research suggests that it supports it since 2013-12-06 (https://www.webmproject.org/vp9/).
26 comments
[ 3.1 ms ] story [ 60.5 ms ] threadIt's a bit mysterious.
I drew a circle on the canvas. I hit the plus button in the bottom left twice, to create a new board.
Selecting the new board, I moved the circle to another location on the canvas, and I clicked the save disk on that new board. I hit the play button.
The site animated my circle being moved from its location on the first board, to the location I placed it on the second board.
Edit: Using the hamburger menu, I exported it and downloaded my animation as a .webm video.
Thanks!
In 2D animation, also always do "breakdowns" between key poses and those are absolutely artistic decisions that cannot be automated (at least without doing a selection step—you could probably automate, e.g. generating 32 different variations and then allow the user to select the breakdown they like best—same with inbetweens, you could allow the user to select the style—but at that point it's only barely ML).
See https://youtu.be/86tqKH3zxuM for all of the different kinds of inbetweens
and https://youtu.be/wdPbiy-8BRo?t=108 for a demonstration of how important breakdowns are between key poses.
Source: I do 2D animation with computer inbetweens, and we also use ML to automate other aspects of our work.
Thanks for the link.
Anyways, i have something fun and nostalgic to play with for tonight
how is vp9 a problem? it's been working for years in firefox
But MDN says it only works on Firefox with hardware support: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/V... .
Caniuse suggests https://caniuse.com/?search=vp9 it's fine on FF and works on Safari if you install the VP9 codec at OS level.
1. That Stack Overflow question is about MediaRecorder, which is encoding. It’s quite reasonable for a browser to support decoding (playing) a format but not encoding in that format.
2. That MDN page says nothing at all about the VP9/Firefox/hardware support combination—in fact it essentially says hardware support isn’t needed (“VP9 is widely supported by browsers, and hardware implementations of the codec are fairly common”). The other point it talks of with hardware support is saying that Media Source Extensions is only available for VP9 if no H.264 hardware decoder is available (which seems at first blush a curious restriction to make).
Wrt MDN, it may have been a misunderstanding. One para says it's preferable to use VP9 over VP8, the next is:
> "3] Firefox only supports VP8 in MSE when no H.264 hardware decoder is available." //
Which I took to mean, if there is a hardware decoder then it would support the better scheme, VP9. But I realise it's ambiguous. It also notes WebRTC requires support of VP8, so the interpretation
It would be weird of availability of a hardware decoder meant that support for VPx was then completely lacking, when it could be provided when there was no such decoder. But clearly I only skimmed the sources, so if you're asserting that's true...?
It’s a curious restriction, but I suspect it’s to do with the use cases for MSE and perhaps some inferiorities of VP8 and VP9 codecs for the MSE use cases, though I’m not sure. Adaptive bitrate streaming is caring a bit more about the trade-offs in network, CPU and whatnot, so preferring a codec with hardware support is perhaps reasonable—though I do wonder why it wouldn’t still have VP8 if it had a hardware decoder. I certainly don’t know the details of all this, but the wording on MDN is very clear.
Remember also that WebRTC requiring VP8 doesn’t imply that anything else in the browser support VP8. Safari 11, for example, supports WebRTC but doesn’t support WebM or indeed VP8 anywhere else. Only Safari 14 starts to support WebM, and there only from Big Sur on.
In Japan, most of animation still involves paper. Inbetweening is treated more as a craft, and the best animators still do inbetweening for top-of-the-industry projects like for Studio Ghibli and Studio Khara.