luckbat

That's what I wanted. I'd tried making folders before, but was never able to drag anything into them. It looks like you have to right-click on the 'Choreographies' folder itself in order to create the kinds of folders that will contain the models in the chor. Now if you'll excuse me, I'm off to reorganize my PWS...

Cool, thanks! That'll speed things up considerably.

Exactly. To each his or her own workflow. The important point is that we both agree that the PWS needs some sort of grouping system. Badly.

In film school, this is called "editing in-camera," and it's discouraged. I plan to render out shots from each camera's POV and edit them in a separate editing program, like on a real film. Having so much overlap between shots gives me the ability to play with the 'rhythm' of a scene, not to mention the benefit of trying out different ways of cutting together the same set of shots. Understood, but then I don't consider ten lights to be a lot for a set of this size, especially when the viewer will be seeing nearly every part of it over the course of the scene.

There will probably be 60 or more shots in the finished piece, taken from a total of about 20 camera positions. In many cases the same action is viewed from multiple camera angles. Creating 10 choreographies would mean I'd have to make every keyframe 10 times, so that each camera would see the same thing! Of course. There's only one set. In about half of the shots, yes.

Here's the deal. Like many animators, I've got an elaborate set in my choreography. Over two dozen models just for the one room, ten lights, ten cameras (so far). Although it was necessary to place all of these elements individually, I often need to deal with them as a group. For example, when doing test renders, I may need to toggle the entire set on and off. Or I may need to flip all the lights off so I can add in another light. Right now, doing stuff like this is really tedious. Clicking through the property window on 26 different models and setting each one's 'Active' property to OFF, and then back to ON when I'm done, is getting old real fast. Managing all these camera views is equally cumbersome. The only way I know of switching camera views is by hitting the '1' key, so I end up having to do this a lot: 1,1,1,1,1,1,1,1,1,Oops--went too far!,1,1,1,1,1,1,1,1,1,1,1. And that's only with 10 cameras! I expect to have almost double that by the time the animation is finished. I'm hoping there's a way to group these things, so I can globally disable the set, or all the lights, or some other arbitrary group of objects. Does anyone have any suggestions? Am I missing something really obvious?

Brain... imploding... Excellent. I'd argue in favor of altering the color of the light between noon and morning, not only the sky color and light intensity. Perhaps morning could be more pink or amber?

Right. This type of shifting focus is often called a "rack focus." In this case, the viewer's attention is being shifted by the camera movement, rather than the focus. I felt that using the camera movement and a rack focus would have had too much impact--the cinematography equivalent of OMG! LOOK OVER THERE! A FAUCET!

Two thoughts: 1. Wow, that is really slick, with clean, dramatic lighting and bold colors. 2. Seriously dude, you have to do something about that brain stem. At least put a Speedo on him, or something.

Well, technically the faucets are "scenery," and therefore don't get the toon rendering treatment, but I'm pretty sure Hash lets you do DOF and toon at the same time. As far as this shot is concerned, though, you could either go with a rack-focus or a tracking shot, but probably not both. I may elect to use a rack-focus in shot 6. Stay tuned. Edit: Just wanted to clarify something. In this shot, the important faucet is the far one, since that's the one the character is using. So it has to be in focus. The near faucet has a neat-o droplet effect and takes up most of the frame, so it has to be in focus, too. Hence, DOF isn't really an option here.

Well, after many tests and experiments, it's time to consolidate my WIPs into a single thread and begin plowing forward. The two-minute short I'm working on is a single scene from a feature-length screenplay (called Ebon) I finished a little over a year ago. With animation in mind, I segmented the screenplay into 13 seven-minute chapters, and have been working on character designs and storyboards on and off since then. I plan to turn chapter 1 of 13 into a long-term project, but since I have no animation experience, I decided to choose a single scene to focus my energies on before I attempt something on a larger scale. I picked chapter 2, scene 4 for several reasons. First, because it's the first encounter between the two main characters of the piece, so it's easy to follow. Second, because it has a nice balance between dialog, acting and action--there's a little of everything. According to my storyboards, this is the first shot of the film. It's only five seconds, with no sound, and doesn't do much beyond establish the location (a public bathroom) and mood (gloomy). But you gotta start somewhere. As I continue to work on the short, I'll be posting my progress and updates here. faucets.mp4

This isn't quite anime, but the DC Cartoon Archives contain a wealth of "turnarounds," which are multiple views of the same character. Project Noir maintains a good gallery of model sheets as well.

Man! I hope I don't have that expression on my face when I run. But shouldn't his hips be bouncing up and down?

As I recall, Yves came up with an ingenious solution to reduce the appearance of wrist twisting in Hash models. He pre-twisted the splines in the forearms of his base model. When the rigged arms are moved out of the T-pose, they untwist quite naturally. I now use the same technique in all my models. Yves' magnificent wireframe is here (warning: not safe for work): http://www.hash.com/forums/index.php?showt...indpost&p=44804

This was the worst animation I've ever seen. Motion was "floaty" throughout, with piss-poor timing that ruined most of the so-called "gags." The decision to render the whole thing in black and white was clearly an attempt to cover up the animator's lazy texturing, and the less said about the laughably expressionless "Shaggy," the better. I've seen better animated faces on "Thunderbirds." Overall, a sad, childlike attempt at animation that ran far too long and had nothing to say. The people involved with this animation should be ashamed. I am ashamed of myself for watching it. The entire medium of animation has been diminished by this atrocity, and on behalf of all mankind, I would urge this ZachBG person never to go near a computer again. Pretty decent for a Hash A:M film, though.

I remember my first thought when watching it was... "Man! All those weeks of painstaking animation, and then for the main character he just grabs Shaggy off the CD?" It made the whole exercise seem a little... I dunno, academic. You know what I mean?

Yeah, no kidding. Fortunately this was a one-time undertaking. Character's going to be wearing a cloak; character's going to be walking around. So it definitely needed to be done. The other character's wearing pants and a short-sleeved shirt, so I guess I'm good to go now. Sure. The hands are the final thing I need to work out with this costume. The character does a bit of gesturing and even locks a door at one point, and with the current design she can't do that effectively. I have three options available to me: A) Shorten the portion of the cloak where the hands are, which is how ponchos are designed, Cheat the cloak bones so that the fabric inches up as the character raises her arms, or C) Have the character do what a real person would do--poke her arms through the opening at the front when she needs to point or grab something.

My effects don't have to be perfect, just good enough for Dearmad.

Who's the loser now? After spending half a day tinkering with the walk cycle, I started noticing some weird glitches I thought I'd already fixed. It was only then that I realized... I've been using the wrong walk cycle! Back in February, I spent weeks making improvements to the walk cycle that I'd originally developed for my lipsync test. Somehow, months later, when I started working on this cloak test, I picked the older walk cycle by mistake. I guess because it had been so long since I'd last worked on it, I didn't notice the difference. (Let that be a lesson, kids! Never keep backups of your old stuff!) Of course, once I'd added in the new walk cycle, all of my cloak keyframes and constraints had to be revised as well. Also, since the new cycle was a bit more vigorous than the previous one, I started getting all kinds of collision problems with the backs of the legs. I'd originally omitted putting bones at the back of the cloak, mainly out of laziness, so I had to do it now, bringing the total number of bones in the cloak to 60. I didn't want to have to hand-animate the new back-of-the-cloak bones, so I implemented a solution I'd been wanting to put in for a while. It's hard to explain, but it's an attempt to approximate the effects of leg movement on hanging fabric--e.g. a cloak or a dress. Basically, if a character is standing straight, both the front and back of a dress will be hanging straight down. When a leg moves back, the back of the dress is pushed back, but the front of the dress stays the same. When a leg moves forward, the front of the dress is pushed forward, but the back hangs straight down. It's not the sort of behavior you can mimic simply by constraining the dress bones to the leg bones. So, I bit the bullet and added two new bones to the model, which I then associated with the thigh bones' Smartskins. Leg bends back, new bone bends back. Leg bends forward, new bone points straight down. Thank you, Smartskin. Which brings us to the latest cloak walk cycle. Despite being swishier than ever before (it's more like a short kimono than a cloak at this point), virtually the entire cloak is animated only by its own "orient-like" constraints, plus lag. Only 12 of the 60 cloak bones have manual keyframes, those being the ones that get pushed aside by the movements of the thighs. Needless to say, I will never, ever dress any character in a cloak ever again. No, it's bikinis and spandex from here on in. I've learned my lesson. Note: I've replaced the animation in the first post with this new one.

So let's see the new version already!

In my experience, the best way to convey "not actually looking at something" is to have the eyes pointing somewhere other than where the head is pointing--usually up and to the right. Ah, now it's starting to make sense. You don't have to do the fade if it's not the style you're going for--only you know the answer to that. Many films convey this sort of thing with straight cuts, but the trick is that the cuts have to go in the right place and the right order. (In a nutshell: 1. they need to visually establish that a character is *not* there before they can establish that the character has appeared out of nowhere, and 2. the appearance of the character via the editing must coincide with the moment they are first perceived by another character in the narrative.) Not that there's anything wrong with the fade, mind you--it's the least ambiguous method of all. You just have to be consistent throughout your own movie with it...

I'm gonna have to agree with Fishman on this one. The head sequence is confusing. 1. Ravel wakes up the instant the marble hits. There should definitely be a delay there. 2. He follows the bouncing marble with his eyes, which is fine, 3. But then he looks at his briefcase, which only makes sense if he didn't see the marble. 4. He then looks straight ahead, which is an odd choice, but not impossible. However, the way his face snaps to attention, it appears that he's looking directly at the person who threw the marble, and thus we would expect the camera to cut to what he's looking at. 5. Except that when we cut, we see that Ravel was fixated on empty space... 6. ...and that he apparently has no peripheral vision, since there's virtually no way you can stare straight ahead and not notice the girl immediately. I'd propose the following sequence, based on the "expanding sphere of awareness" that sleeping people have when they're woken up abruptly. 1. Ravel is startled awake by the impact on his briefcase. 2. He looks to his briefcase for clues. 3. He notices the marble. 4. He looks for, and spots, the person who threw the marble. Blocking-wise, I'd consider sitting Ravel a little further away from the right railing. In my opinion, the railing is cramping Ravel's visual space throughout the sequence, and in the close-up, he looks almost caged-in... Edit: Dammit, that's what I get for taking so long to write this. Okay, so he's not sleeping. That's fine, it actually looked like he was staring at the ground. But I still stand by my "sphere of awareness" notion.

Nope. My goal is to move away from dynamically calculated keyframes, towards an optimized "cloak rig" that responds to the character's movements through a series of constraints--with maybe a few "helper" bones that are animated manually to avoid collisions with the hands and knees. I'm using 11.1g--hang on, make that 11.1h. I'll be upgrading to Tiger/A:M v12 when the opportunity arises, though. Are walk cycles ever truly finished? It sounds like the consensus is that the feet are too stiff. I'm using a TSM-1 rig, so that's an easy fix. They are indeed...

I'm not sure how making two walk cycles in four months constitutes hard work, but I'll take my compliments where I can get 'em. Yeah, but it's a legitimate quibble. I just did a quick experiment with lag settings on one of the bone chains, and it definitely looked nicer. Gimme a day or two to play with it--I'll post an updated animation if all goes well. Agreed. They were just quickie umbrellas I threw together. They don't even have spokes. I have a lot of costume work left to do, from improving the appearance of the bandages to texturing the cloak properly, so it's on my to-do list. Thanks. This walk cycle is the first step in converting my animatics into the final short. I'm just gettin' started here...

Hey, does anyone remember my last attempt to animate a walk cycle with a cloak? No? Well, it was four months ago. Anyway, I had some concerns about the viability of the last version. Namely because it only worked when the character's arms were locked to her sides, and also because dynamics have to be recomputed every time you decide to change something. So, I went back to the drawing board. Since I wanted the cloak to swish around as the character's arms moved, I (loosely) constrained some of the bones in the cloak to the arm bones. The rest of the work involved manually animating the edges of the cloak so the hands and knees don't pass through it. The cloak as a whole is a child of the ribcage bone, so it naturally swings from side to side a bit while the character is walking. So here's version 2. I rendered the toon lines in a separate pass, but I thought the animation looked kinda cool without them, so I left them out. I also slapped on some cloak decals for visual interest, but they're a bit pretentious-looking, so I probably won't keep them. (By the way, if anyone's wondering why I don't simply use SimCloth--I don't think it's compatible with toon lines...) Edit (6/11/05): Updated this animation with improvements to the walk cycle and cloak constraints. Ebon_cloak_walk_2_1.mov