robcat2075

I had never thought of it that manner and I'm doubtful it is meant to work that way. Anyone? I think if you find cloth wizard settings that work well in one instance... remember them ( to paper?) and use them as a starting point with the cloth wizard for your next outing.

Ok, I laughed! I actually remember him doing that on SNL a looooong time ago. You should Youtube that.

You got my curiosity going so I did a simple test In this animation, it starts at 0:00 with the near and far focus enclosing the just the depth of the closest box. from 0:00 - 1:00 the far focus moves back to include the distant box. from 1:00 - 2:00 the main focus distance moves from the closest box to the distant box. from 2:00 - 3:00 the near focus leaves the close box and moves back to just in front of the distant box. first with no multi-pass dofNormal000.mov now with 25 multi-pass dofMP000.mov I think either of these are usable in certain situations, but for the most control I think you'd want to render a depth map and do your DOF blurring in a compositing app. 16 pass is equivalent in anti-aliasing of a regular render. DOF and motion blur are quite different issues.

There are people who have done long coats. Scour the forum for their accumulated wisdom and give it a try. I know it can be done, but testing, revising and tweaking simulations is for the exceptionally determined.

Generally, for cloth to even begin to behave usefully, it probably needs to be mostly pretty square patches. the long tall ones look unlikely. On the other hand I've never tried it that way, so who knows? Cloth is an advanced topic that requires enormous diligence and a love of experimentation.

well, you have something that you don't want anything poking thru... hide that something so you can see what is moving underneath it, if anything.

You dont' need to repost them, I've got them now. But Sorenson3 or Mpeg4 are good choices for small file size. and 640x480 is more than big enough for most tests. ok, i see a little bit of flickering on the face. I'm not sure why simulating the dread locks would be the cause of that. Hide the face and see what part of the body is moving around.

Tip... don't use the "animation" codec. that's why it's taking up 20 megabytes for just one second of animation. That one second should take up maybe 300K at most. Also, don't render at 1600x1200 for tests like these, there's no computer that can play that smoothly. I don't see the face going crazy. What do you mean by that?

You might consider rigging before texturing. Rigging sometimes shows a need to change/move splines which would undo some of your texturing.

You're designing lots of cool characters! The splining may even be getting better too. I don't know who that is.

With no motion blur both of the above examples would appear stationary and unchanging, since the ball is keyed exactly the same on each whole frame. here is motion on an object that actually moves from frame to frame: BlurInMotion_10_20_40_66_100.mov The same 1 second motion repeated at 0%, 10%, 20%, 40%, 66% and 100% with 25 passes and again with non multipass blur at 0%, 10%, 20%, 40%, 66% and 100%.

Is the material on the hands a different one than the material on the face?

Are you sure it isn't tooned? Black toon lines on a black shape won't be very visible

You can keyframe and vary certain camera properties like motion blur % For demonstration this clip shows a ball that repeatedly moves in an arc over one frame. If there were no motion blur the ball would appear to stay in the lower left corner a it is always keyed there at the beginning of the frame. As the motion blur % is increased from 0 to 100, the blur covers a greater portion of the path the ball travels during the frame. This shows motion blur with 16, 25 and 49 passes and then the non-multipass motion blur. BlurVarying_16_25_49_Post.mov Multipass blur is more accurate if you use enough passes, but nonMultipass blur is way faster. In most situations (settings around 20% or less) the nonMultipass motion blur will work fine. Notice also that nonMultipass blur is appropriately centered around the location of the object at the keyframed position, while Multipass blur actually stretches forward from the keyframed position. This could be detrimental when an object needs to exactly be in contact with something on a certain frame, such as in a bouncing ball situation. You could make Multipass blur be appropriately centered by offsetting your keyframes by a fraction of a frame. Tricky, but doable. On the other hand nonMulti blur seems to have a limit to how far it can stretch; Multipass blur can stretch the full 100%, although there aren't many situations that you would want 100% NonMultipass Blur can sometimes create weird results in complex motion situations, particularly on objects that are rotating more than they are moving linearly. This clip shows 16 pass, 49 pass and nonMultiPass motion blur increasing from 0 to 100% on a spinning sphere that has been keyed to rotate 360° per frame. BlurSpinning_16_49_Non.mov But again, the nonMultipass blur will usually look fine at typical low % settings PRJ: MotionBlurKeying.zip Q: How is A:M's renderer more powerful than Pixar's? A: A:M's renderer can accurately create arcs in motion blur In interviews Brad Bird has expressed disappointment with the lack of arcs in their CG motion blur.

That's much better than a Cease and Desist order. A hopeful sign.

I feel bad for the troll. He had the best toonlines.

--> QUOTE(Jeff B @ Nov 20 2008, 01:53 PM) 287163[/snapback] Hi All Thank you all so much I will have to look into the NLE editer. How do i get into that can anyone tell me. http://www.hash.com/forums/index.php?s=&am...st&p=244717

--> QUOTE(Jeff B @ Nov 20 2008, 11:54 AM) 287143[/snapback] Sorry, very newbie question here. I am trying to make a short film with two different camera shots, but I'm having trouble. Can anyone tell me how to get two cameras to work and how to render them at different points of the film. I would like to have the first camera slowly zoom in one my actor then change to the next camera that is in a different place and continue the shot. Then may be go back to the first camera again. you can keyframe the camera to change position like you can any other bone. Keyframe it to do the move you want in the first "shot", then keyframe it to the new spot for your next shot. All in the same Chor. Another option is to do your two shots in different chors, render them separately, and edit them together with A:Ms editing (NLE) ability.

Here's the third one, squetchy bouncing ball... with anticipation! anticbounce0001MP4.mov Actually I've been meaning to do a tut on bouncing ball because I have yet to see one that made good sense in terms of what we do in CG. So much to do... so little enthusiasm to do it.

It's not a BAD bouncing ball. He's really close on a lot of it. I don't mark him off for not using squetch. The first assignment you get in animation school is to do a bouncing ball with no squetch and that may very well be the intention here. It's hard to make the contact with the ground look solid without squash but there are certain objects like bowling balls and coconuts that you'll need to drop on some one someday and they never squash even in the floppiest of universes. So we won't worry about squash. Several of you are on the right track with comments about the speed of the bounces or "hang time" or the gravity going away. Any one of those bounces from one contact to the next might be an OK motion for a ball to travel thru. We have no idea about the scale of the ball or the distance it's dropping. But if we count frames on these bounces we find some things that just can't be. To simplify, I counted the frames it took for the ball to drop from the peak of each arc to the ground and came up with these 6 6 5 5 5 5 4 4 3 3 3 3 2 1 (btw, the time going up should equal the time going down in each arc) So we have quite a few drops that are taking the exact same length of time to happen. For example drops 3, 4, 5, and 6 all take 5 frames to hit the ground. They are falling from progressively lower distances and yet take the same amount of time to reach the ground. In fact, drop 6 falls from 1/3 the height that drop 3 fell from. It's as if gravity is reducing for each bounce. That starts to look weird after a bounce or two even if you don't count frames. One solution would be to have the ball bounce height decay much less so the ball was rising to and falling from about the same height each time. But if he wants to decay the bounce as much as he does, the lower bounces will need to happen faster than they do. Which means he's going to run out of bounce much sooner. Which means he might want to start from a much higher height so he has more time on that first bounce to shave frames from on the later bounces. Somewhat related, there are several brief stretches where the balls speed is rather linear... it's moving the same distance from one frame to another, particularly as it nears or leaves the ground. That can't be. A ball falling will cover more and more vertical distance on succeeding frames and a ball rising after a bounce will always cover less and less distance on succeeding frames. On the plus side, he's got the horizontal motion of the pretty well down. It moves steadily forward regardless of how fast the ball is rising or falling. A lot of people will have the ball slowing in mid air at the top of the arc. And the arcs seem to be pretty good parabolas. The beginnings and ends might be a little straightish but it's hard to tell when the distance covered in each bounce is so small. The spin of the ball is an issue. It looks OK initially but in the last few bounces it doesn't seem related to the ground contacts. But you'd really want to get the basic bouncing motion of the ball right before you tried to fix the spin. (Real balls can spin in an unintuitive manner. A superball can actually reverse spin on a bounce if you toss it right) Now these may seem like very small points, but small points are all that "bouncing ball" has. There's no story, or dialog or posing, or staging issues. You just need to get the basic physics right, and if you can't do it on a bouncing ball you probably won't get it on all the bounce-like things a character has to do like walking or running or falling down or tossing something or just dropping their hands to their side. Mastering the basic physics of falling or bouncing objects goes a long way to making your characters seem to have real weight when they move. Thanks for all your participation and comments!

That looks like you've go the spline continuity thing figured out! One item... most rigs presume you model the "palms" down rather than forward like you have. That may or may not be a major issue, but something to keep an eye out for.

Since your character has human legs you may find these vids on walks helpful post #180 Also the general strategy on quadruped walks is that the rear foot contacts the ground right after the front foot lifts off in front of it.

Ok, I'll make that next weeks target. If you can render a clip that includes a side view that will help people analyze it.

I don't know that there are any dancing actions made, but there may quite a bit of motion capture files out there on that. It is possible to attach an A:M character to Mocap data. Somewhere on this forum is some info on using mocap and some links to free mocap sites.

It seems to be another occurence of this problem that Steffen has described try this... momia_George_ok_v_15X.zip