robcat2075

I'm wishing fluids had something like the "damping" setting cloth does so it could eventually lose energy and stop moving. I recall Fluids were written by a college student that Martin had as an intern several years ago. I wonder if he could be located....

More tests with fluid. BowlTests.mov

Along the same line, in the original "Madagascar" many of the background cityscape buildings are not CG, they are physical models painted and photographed to look like CG and used as "rotoscope" behind the character animation. They did this because they didn't have the computer power to render all that. I'm surprised by that but that's what they said in the commentary to "Madagascar II"

Same here.

From the Hollywood Reporter... I presume there's some sort of signal light they shine on the clouds to call an emergency board meeting.

If you add a "Turbulence" to a combiner it will make the boundary less straight. Can you show us a real-life reference image of what you are trying to do?

I recall reading that in the early years Pixar had a goal of no more than 5 minutes render time per frame. They've blown way past that on more recent projects but there was a time when that was their practical limit to get the movie done on time. Basically you try to swap in faster things that will do the job of elaborate things. For example, it's unlikely I will use particle fluids for the lagoon that submarine is in, I'll probably use my "cloth" water which is pretty fast to work with and will look appropriate. Somewhere in my tuts is a thread where I went through a shot that someone said was taking too long ans showed various alternate techniques to make it spit out faster.

Does anything happen to the Techsmith codec? Do old quicktimes done in Techsmith no longer work?

Seen while waiting for the first frame to calculate...

Mostly I'm just coloring these tests so i can see where all the droplets go easier. I'm still investigating basic settings for their effect on particle behavior. What I'm finding so far... The "Droplet Physics" has two parts, Pressure Force and Surface Tension Force. The droplets are imagined as spherical particles that can move independently of each other but Pressure Force and Surface Tension Force influence their interaction with each other. Pressure Force controls how much their spherical boundaries are allowed to overlap. If Pressure force is set to zero it is possible to endlessly pour particles on top of other particles and the volume of the liquid will never increase, the particles can overlap completely. When Pressure force is greater than zero the particles will begin to nudge each other aside and begin to stake out their own personal space with less overlap. If particles are born closer than their Pressure Force setting allows or if they collide and end up too close together they seem to spray apart from each other. Higher values make for lumpier, more churning liquids. Surface Tension Force is the tendency of particles to attract to neighboring particles and form a larger droplet

Impressive detail as always! So somehow the interior of the dishwasher figures in your story. I am curious!

Here are some more fluid tests, not all useful but interesting none-the-less. PRJ06Tests.mov

I'm finding there's a lot of interplay in the parameters that have a way of amplifying or negating one another so don't shrink her yet!

No particle will be left unturned in our search for an appropriate result! We're going for something that is less "white-water" than a dam burst but not as static as a glass curtain. Somewhere between those two extremes.

This is the start of some basic R&D on particles. Four different tests for "fluid" to see how it behaves and how it interacts with the objects it hits. FourWaters.mov

P.S. My animation of the backflip WAS done in an Action instead of the Chor because I did intend to repeat it exactly a few times and animating that once in an action, then reusing it in the chor made that easier. A rare case. None-the-less, the model bone isn't moved to make the character flip, it's all skeleton animation. (It's actually impossible to move the model bone in an Action. You can only keyframe a model bone in the Chor.)

Nope. Paths, as we know them in A:M, are rarely used in character animation. The model bone is placed once to locate the character at the start of the scene in some convenient spot, but after that the skeleton bones of the character are animated tp create whatever motion is needed. Here's a video that shows the animation process on a simple robot. Notice that even though the robot is being animated to walk forward the model bone is never moved. Post #20 Simple IK Leg Walk. If all a character had to do was walk the same walk indefinitely, then we would use a walk cycle on the character with the model bone constrained to a path. However it is exceedingly rare in story-telling situations for a character to just walk. When they also have to do the butt-scratching and twirling, getting in and out of that path constraint is a huge hassle and it's really easier to keyframe all motion from start to finish.

William Detwiler (aka detbear) and I will be collaborating on a brief shot in this forum William and I have both been long time A:M users but we didn't really "meet" until we were both students in the very first class to enter AnimationMentor and noticed that we were both using Animation:Master for our assignments. William is a professional animator and since AnimationMentor I have contributed bits of rigging, animation and other elements to projects of his. Now William has asked me to consult on a new endeavor, a trailer for an adventure movie he hopes to use for a Kickstarter project and I am eager to see what we can do with it. In particular we are narrowly focusing on one scene here. William has prepared a rough draft to show the essential concept... Detwiler_Project_Waterfall_WIP_C.mov That is not the whole trailer, that is one shot. Out goal is to make it look like a truly cinematic, movie-quality scene. The water effects are the obvious challenge, but we also need to design appropriate lighting and probably rethink the staging a bit. Basically, everything needs to look better and we want to figure out how to do that and we want to do it with A:M! That's what we'll be doing in this Special Topics forum and if any of you have comments or suggestions you may certainly toss those in!

Welcome to A:M, guye! I also was worried about leaving the model bone in one spot and having a character walk away from it when I started animating but that is the overwhelming choice among animators professional or otherwise. The model bone is good for moving the entire model as a whole but that is something animators rarely do. They are always moving parts in relation to other parts. Even when the whole body is in motion, it never moves as a rigid whole which is the effect of moving the model bone. Here is a step-thru of an old back flip I did. The model bone is never moved, but all the other bones are animated to turn the character 360° In this view bones turn red when they have a key frame on them. clip3568Gymnast.mov Basically, you key bones as often as you need to to get them where they need to be. I'd have to know more about the constraint problem. Constraints should work no matter where the model bone is. This suggests some additional mishap you may want to tell us more about.

Problem solved now? I think we got you moved over to particle bubbles instead, right?

If you are using hair for grass you can use a grayscale map to control its density to make the grass gradually thin out over some distance or even have some dense clumps that diminish over an area. Unfortunately we can't use particle materials as components of combiner material

What's causing the ripple on his face?

Hi Mark, here are some wandering, random comments on your heavy push... clip3566MarksPush.mov

It happens if you re-save a PRJ after you render? I'm not sure about the disappearing names but you don't need to re-save a PRJ after rendering. If you just save the PRJ and reload it the names don't disappear, right?

A:M has a camera post effect that will "burn" the current frame timecode into the rendered image, but on Mac you can't set the size of the effect. Here is a simple integer image sequence of 000-719 that may be added to a camera as a rotoscope if frame numbering other than what the "burn" effect can do is needed. It can be resized and moved to anywhere in the frame. I'll note that having an animated rotoscope in the frame seems to slow down real-time performance so you may want to turn it off until you render. counterTGAs.zip