 So, hi everyone, I'm Benjamin, in the next 20-30 minutes I'd like to tell you about performance timing and why I think it's a great thing. Performance timing is a real-time technique for timing computer animations. It's not about going to a performance with a stop watch or anything. Is there a feedback sound? Right, I hope to spread the idea of these kinds of animation tools and also get some feedback on the work I've been doing. I'm happy to take questions after the presentation. So just some quick facts about myself. I'm a PhD student at the Digital Media Department of the TZI Institute at the University of Bremen, and in my work I research new devices and interaction approaches for computer animation. I'm especially interested in real-time animation techniques or approaches that involve some form of motion capture. So to kind of bring the liveness back into animation. If anyone of you was here last year, you might have seen my colleague Mark and my talk on bringing multi-touch to Blendom, which together with the real-time animation tools that Blendom already has, like Auto Key Framing, can already give you a very good computer puppetry suite, turn Blendom into a computer puppetry tool. Now, I'd like to quickly, to get started, briefly talk about computer animation in general. Now, you can roughly say there's three approaches. There's been talks that have touched each one of these very interesting talks today and yesterday. There's motion capture, simulation, and obviously key frame animation. Now, motion capture, as also there was a talk yesterday, motion capture can involve quite costly setups, and it's not always really feasible, and also not always what you want. Simulation is also a very specialized thing. You wouldn't, for instance, use it for character animation. So, by and by, key frame animation is still the far most established and practiced method of animation. And concerning key frame animation, the actual placements or the creation of the key poses is probably a fairly straightforward thing, but what really is essential and what's probably the hardest thing to tackle is getting the timing right, spacing key frames on the timeline in time so that you get a convincing, you know, kind of realistic motion. So, this is kind of a key issue, and I've talked to animators, and they also really identify this to be the main thing, and that it just takes a lot of experience to get that right. And I believe it's not so much the problem of imagining the right timing, but rather transferring the idea of a timing you have using these tools to the animation. So, for instance, you could probably very easily, without much thought, just make up a speed or a motion for something you have in mind for a character for an animation. But it's bringing this into, you know, compute into the virtual world, that's the key issue. So, it's kind of this abstract mapping of an idea or of a motion to time units. And I want to get this acting out back into animation, this real-time liveness. And I'm not the first one, I'm building on prior work here. For quite a while there's been an idea, an idea has been around called performance timing. And there have been proposals that say you act out the timing, you act out the animation timing. And the workflow is you create your key poses with the standard tools, create a key frame, but you don't worry too much about the timing at this point, you just basically space them arbitrarily in time. And then you perform the timing. I'm going to talk about the performing the timing next. After you've performed, you can still adjust the key frames, spatial temporal values with the standard tools if you desire. Now, I'd like to demonstrate three kinds of tools, three performance timing techniques that I've developed as Blender add-ons. They all vary in the interaction approach, how exactly timing is recorded and mapped. And I name them scrub, sketch and drag, based on the main action you perform to do the timing, to act the timing. What I want to make clear is that this only changes the time of the key frames. The spatial component of the motion is not altered. So you could have an existing animation and re-time it, you could have your initially roughly or arbitrarily spaced, temporally spaced key frames and then do the initial timing or have several steps. No key frames are ever added or deleted. Right. First technique is scrub time. Scrub time literally means just that. Scrub the current time on the timeline. The movement along the timeline is recorded and set as the new timing. This is based on a plugin for Maya that's been around for a while by Jonathan Sampath. Unfortunately, it's no longer available as a download from this site. But anyway, I have re-implemented that for Blender and I'm going to give you a quick demo. Now, one brief disclaimer. The optimal tool for these kind of techniques would be kind of maximum direct input devices such as a touch or pen interactive surface, like a Wacom Sintiq. Many of you might have been using that. So I might seem a bit clumsy with my touchpad here at times, but I hope you get the idea. So let me just full screen this. Okay. So this is a basic bounce animation and you can see on the timeline the key frames are evenly spaced, which starts out as an okay animation, but kind of then doesn't make any much sense towards the end because you kind of quickly realize you would have this ball to go, want this ball to go faster and kind of have slower steps. So income scrub time. Now, the basic idea is probably one you know if you've ever done any kind of video playback, any playback of any kind of time based medium. So most of these tools work in a recording and non-recording mode and scrub time in the non-recording mode is just what you do already. It's like scrubbing along the timeline just to view kind of manually playback your animation. So this is automatic playback in real time and with scrubbing, I could just kind of determine the propagation through time myself depending on how fast I go. Now, the idea of performance timing now would be to record this input. And with this tool I go into the retime mode and I could now actually retime the bouncing ball animation. I'll try and do as best as I can. Yeah, it's not physically correct, but I guess you get the idea. Just to be explicit or just to make sure you get the point, I'm going to do some other stuff, a bit erratic, but just to show you that I can go really slow, fast, slow and I would record it again. It's jerky, you know, but you get the point. Yeah. So that's scrub time. The advantage is you have some interactive feedback. If you scrub it, you see the resulting motion. You see what's happening at that point in time. So you actually playback or as you record, you see what you get. The disadvantage is that you have this abstract mapping of a timeline, which is a linear depiction of time. Now, in this case, my ball was actually going from left to right, just like my timeline would, and it helps to do that, but my motion might be something completely different. And the mapping, you know, the spatial correlation between input and the result is not really given. Income sketch time, which has a different idea. Here you sketch out the motion path. And depending on how fast or slow you do that, you determine the resulting animation speed. This is based on work by Silvio Lissiza Lisanaterra and Ronald Anthony Metoyer. And I'm just going to demo that too. Let's take the little fella. By the way, the models and also basically the animations are not from my mind. Some of them are from Visilio Vasconcelos from his book, Rigging in Blender 2.5, an excellent book. That's not the exact title. I forgot it. And some are taken from the Blender regression suite. So for this, it helps to visualize the path. So this is actual path. The animation in itself is with equally spaced key frames, so it doesn't really make much sense as it is. So you kind of just plot down your key frames. And now I want to get dynamics into that. And I do this with sketch time. And I sketch in a way that I would think that this guy would jump. Maybe like this. Now, what the system does is try to find a correlation between my input and the actual motion path. And it does that finding extrema or salient points on the curve. It doesn't, it's not always excellent at this. So sometimes I have to manually edit. So in this case, it kind of missed this trowel. And now it turns green and I have a good match. And I can apply. Yeah, so it's getting closer to a physically believable jump. Just to make that clear again, I'm going to do a different kind of jump, kind of a fake, slow mo at the height of the curve. And this is done, you know, more or less real time, because I've just sketched the path, depending on how fast I sketch it. I get, immediately get the result. I could do something very slow. And it's got few too many. We don't want that. We don't want that. Oh, I'm missing one. Here we go. So here's my slow animation. Right. I want to clear my path. Anyway. So the advantage of this is we have this feeling of space and proportion because we actually sketch the motion path so we can literally, you kind of work with the 2D projection of our 3D motion path. But in this case, it's not really interactive. We don't immediately get feedback on our timing. We kind of have to complete it, do this intermediate adjustment step in some cases, and then view the timing. Now, we thought we can do better. So we developed a third technique, and we call this drag time. And this works by actually dragging a feature through time along its trajectory. And this can already be used for browsing animations. So even if you're not interested in performance time, you can maybe use it to browse complex animations where you just want to know, what's the point in time where my ball is exactly here? And if you record that, like in scrub time, this becomes a performance timing device. And this is inspired by work done on the video domain, mainly also mainly for browsing videos. People like Pierre Dragachevich, Autos and Kara and their colleagues have been working on this. And I'd like to demo that now. I might have to just quickly restart that. Let's take this guy. Lovely look so. Again, it helps if I actually calculate the path. So this is the path, the feature of the lampshade. So the head takes. And again, my initial animation is evenly spaced keyframes. Yeah, that's not the animation we want. We want a kind of more enigmatic, more believable timing. In comes drag time. So without selecting a player, I can use it as a browsing feature. So see how the play head down there moves as I drag it along its motion path. So say if I want to know at which frame in this animation, the lampshade will be, you know, at, for instance, this peak. So I can just grab the object and drag it through time. And I know that exactly frame 42 looks so is at this point. But if I want to change that, again, I can select retime. So actually record this and use it for the new timing. And here we go. Again, I kind of built in this fake slow mo effect of the peak. Maybe I don't want that. Maybe I'll just do a kind of physically believable jump or something much slower, maybe a whole slow mo shot as a little jump in there. Again, with a pen, this would be much, even much more expressive, easier to confer the input to the timing. Right. What's great about drag time is that kind of get the best of both worlds. You have the interactive feedback that the scrubbing has. And you get this sense of space and proportion because you actually drag along the motion path so you kind of can really feel that motion that's going on. Of course, this comes at the price that you do have to go all that way. And if you want to see kind of the whole motion path and you have a big screen, then you have to do the whole motion rather than with a sketching where you could do it in the corner and kind of map that. What's this good for? Well, especially in experience animators, I believe, can use this to kind of shortcut the timing problem. Like, if they're getting frustrated with keyframe animation, we had this, Daniel was talking about this early on in the other room, you can maybe breach that frustration valley by showing them tools that are much more literal, much more intuitive, you could say, just really acting out the timing. You need to learn this abstract mapping from a timing idea to the number of frames, you just act it out. But I also believe that professional animators can benefit from this approach. Maybe to draft an initial timing so you have a basic thing you can work from and then refine that further with the tools that you know are more established and more precise tools. Adjusting curve handles and moving frame by frame. Or maybe used by people involved in animation process, but not themselves animators, such as directors and storyboard artists, they can just go, okay, give me that tool, I want them to go like this. And then they more or less can much better communicate their ideas on timing. So I believe performance timing makes timing easier and more expressive and should be a more established means for timing. And you can use it from today, if you like, or if you know people who like, let them know of this URL. It'll be on the slides on the web too, so you don't have to note that down now. And since I'm researching in this area, I'm really interested in feedback from you, either right now, I'm around at the conference or drop me a line. And I'm pretty much through. That was it. Thanks for listening. Do you have questions? I don't know who is first. Sorry. Start the back. The curve in the 3d view. That was the motion path of the curve. Yeah. Yes. It's always a mapping from time to time. I think you're getting at the what you mean as the animation or used to be called ipo curves. So the actual mathematical representation of the axes, rotations and whatnot, you mean the relation between input and that? Oh, kind of in a in a graph. Okay. Expansion contraction. Yeah, I get your point. And I've been thinking about that kind of the the visualization of the re timing in a curve. There's also literature on that. They'd use it in a different context, but they have this input to output time graph. But that's also again, a much more, it might be a helpful tool, but it's also much more abstract and mathematical. So you have to kind of get into that. And it's not the main thing I'm focusing on. But it's a good good remark. Thanks. Yes. Sorry, coming in. You could do this with cameras. Sure. Yeah. It can be applied to more or less any kind of object or pose bone. I get it. You mean with a moving camera? True is a problem. Because as soon as you have the reference frame moving, the camera that your view of the scene, a lot of the mapping becomes well, you know, really difficult to imagine and to understand. No, this is intended for static cameras. I wouldn't recommend using with a with a moving camera. I haven't looked into that much. With slow moving cameras, it does work. But if you have a lot of motion, the mapping is very difficult. It's not it's not so literal. Exactly. You would just choose a static front, whatever view perspective that that matches your or is a good handle for sketching or dragging that curve. Yeah. I think you were next about this drag approach. The mapping is it looks for the closest point on the curve to your input to your mouse cursor, essentially, with also some further criteria. Let me just pay that back so we have something to look at. For instance, there's a third parameter parameter or a third dimension, the change in the arc length so you wouldn't have too much jumps. But essentially, this allows you to make a much more rough input than the actual trajectory is because you have this, yeah, you have this closest point mapping from the input. Yeah. It can lead to problems if you have very obscure, like pointy curves with nooks. There's also some research going on in that. But essentially, it does make it very easy as you saw in that example. Yeah. Yes. 3D curves or highly three dimensional curves in general are a problem. So you want you want something you want the best view to kind of the best projection to perform this timing. If you have a really high three dimensional curve, you can either do 3D input. We're also working on that. So again, these guys are also working on that as well. Or what was I going to say? Or you kind of divided into segments and saying, you know, I'll just re time this part or this part based on, you know, less or less three dimensional, more planar segments individually. But that's basically ongoing research to also solve those problems overlapping highly three dimensional curves. Yeah. Yeah, that's that's the idea. Yeah. Because the actual motion path you could develop with any camera. But then the timing you would probably do with the optimal view for the timing. So something that, as I said, kind of gets the two dimensionality of it best best mapping. I'm still around if you want to chat.