What is the approach that is being adopted by developers to implement animation (i.e when we click play button)?


(keshav sharma) #1

I’ve been looking over the source code recently and it was a bit confusing to draw some concrete conclusion in mind regarding animation implementation, like when i click play button, a series of signal and slot mechanism finally leads up to certain function that eventually plays animation by traversing over each frame,
Traversing over so many source file was bit time consuming and i was looking for answer a little bit early (I’m doing some work related to animations and so i want to know the concept and theory behind this)
I want to know exactly

  1. How are you handling cases where animation is currently playing and suddenly user adds a new frame?
  2. A little highlight on entire concept and what thoughts went into your mind during the implementation phase of this feature

(Jose Moreno) #2

@keshav2010 Hmm as I do not know the inner workings of the code I’ll tag other developers here so that maybe they can answer you appropriately. However for point number one I can provide you a quick logical answer.

As you know animation is an optical illusion that depends on the playback speed of a successive display of sequential images. As such the playback in any animation software, is meant to help the animator estimate their own work while working. However in your workflow you do not draw and playback at the same time. While it’s not impossible it is simply not efficient or purposeful to the animator itself. The reason being that the animator is always planning the drawings to represent motion, you are not simply drawing real motion, but you are crafting the motion and as such you require utmost control, which drawing while playing back the animation would simply become a sort of “motion capture” which for most styles and techniques of animation is not useful.

Aside from obvious motion capture devices and techniques, the only instance of this type of real-time drawing capture I know of, which I consider more of a gimmick than an actually useful feature in most animation work, is in the commercial software TVPaint, where you can draw “over-time” while the timeline is playing, which means that while the strokes are being drawn, the software itself is “photographing” the state of the stroke for each frame, which can lead to a “build-up” effect.

For the rest of your queries i’ll tag @chchwy @scribblemaniac @CandyFace so maybe they can answer you more adequately about the source code. Thank you for your interest in Pencil2D :slightly_smiling_face:


(keshav sharma) #3

Thanks for your reply and tagging the developers, yup im aware of the technical details that goes into implementing such systems but my actual goal here is to see through developer’s point of view, to get familiar to their thought process and how they planned to implement this, I had implemented such applications before but the approach was different from what I’ve seen in Pencil2D and my goal is to basically compare the approach and being not so experienced, i want to see what is it that i need to improve when implementing these crucial features.


(Matt) #4

Hey @keshav2010, I am one of the developers.

We don’t really handle this. Actually, you can even draw things when the animation is playing.
Playing animation is driven by a timer. For example, if an animation is playing under 12 frames per second, every 83 milliseconds (1/12 sec) the frame indicator steps forward and asks the canvas to repaint until reaching the last frame. So you will see the new-added frame immediately while the frame indicator goes over the position of the frame.

I will provide some key functions about playing an animation that may help you start tracing code:

When a play button is clicked:

  1. PlaybackManager::play() in playbackmanager.cpp will set up the playback range and start the timer.
  2. The timer will call PlaybackManager::timerTick() regularly based on the FPS.
  3. timerTick() will end up calling Editor::scrubTo(int frame), the frame number will be the current frame plus 1, so the animation steps forward.
  4. In Editor::scrubTo(), it emits a signal currentFrameChanged to force the canvas to repaint.
  5. One the Qt widget gets a reapint event, ScribbleArea::paintEvent(QPaintEvent* event) will be triggered. CanvasPainter then goes through all layers and draws things on the canvas based on the current frame number.

Let me know if you want to know anything further.