robcat2075

A:M uses formulas to calculate how much farther to move a bone from the last frame to the current one and in what direction. The "time" element of that calculation is not dependent at all on our real-world human time that passes while the calculations are being done. The computer plugs in a number that represents the passage of 1/24th of a second and the formula (which also considers numbers for things like previous direction and speed) returns values that tell where to place the bone for the new frame. It matters not how long the calculations actually take the computer to do. A very slow computer processing the formula should come up with the same answer as a very fast computer processing the formula. If there is a difference between realtime simulation result and the simulation that results from Baking, then the formula is somehow being applied in not exactly the same way. It's possible that my simple test with default settings does not catch what is happening for you. If you could create an example case that shows your differing result that would be very useful. For reference here's my test PRJ. DynamicBakingTest.prj

in the Chor>Bake Dynamic Systems in the Chor>Remove Dynamic Simulation Data You may be thinking of cloth. Cloth (not a Dynamic bone system) has no explicit un-simulating option, but in actual practice a new simulation will overwrite the old one.

Modeling and rigging a Spring

I'll add that getting the walk cycle to match exactly at the jump from 100 back to 0 is very difficult. If you really need a character to walk several times in a circle, it will be easier to make the path itself circle several times and ease te charcter conventionally on that longer path.

Here's the work around. Set the ease in the first frame to zero, then set the ease in the next frame to whatever you wanted the starting ease to be. After that you can key the ease to be anything from 0 to 100 and it will all drive the walkcycle properly. Just dont' render that first frame.

Yes, I remember there used to be a substantial difference. markw, what version are you using?

example of the problem... say the ease starts at 20%, rises to 100, then jumps to 0% and rises again to 20%, then continues to rise past 20% the feet will be inactive in the stretch from 0 to 20 then begin working again beyond 20. /| / | / | / | / | / | / | / / | / | /* |/* Probably a bug, given that other body parts continue to work.

I think those have promise too!

Have you watched "Using Walk Cycles on a Path"? http://www.hash.com/forums/index.php?showtopic=41588 if you want a model to follow a path that loops back into itself, key the "ease" to jump from 100% to 0% at the point where the path starts over again. A walk cycle would require that the path length be exactly a whole multiple of 2x the stride length However, in my brief test I have not gotten a walk cycle action to survive the point where the jump occurs; the feet stop moving. A quick work-around for now might be to make several copies of the path and rotate them so each model can appear to start at a different point.

Nice looking shot! two ideas... -I think a little bit more direct light might help show the shapes better. Or possibly if you added a light from above highlighting their top edges to simulate the light from the torches. -If you animated the torch light's intensity to flicker a bit they would seem more fire-like.

Here's a partial turn-around of the bread The angle of the bread to the camera has quite a bit to do with how it looks. The crust will need some other treatment, it looks rather gelatinous here. The noise combiner has a too obvious repeat to it when it's scaled this small, that's another problem.

v17 beta 4

My test is similar to Nancy's but has a very slightly different result. I don't think there really is "real time" to the computer. It does the simulation calculations to get the object from the last frame to the current one, throws a picture up on the display and then waits until it has to do that again. To test that out I captured a real-time display one-frame at a time and compiled the captured frames back into a 24fps movie (middle view). It wouldn't matter if I waited 10 minutes between each capture or did them 1/24th second apart, the motion of the chain woudl be the same. PendulumComparisonH.mov The result looks so similar to the realtime playback on my screen (which i can't capture at 24fps) that I'll say they are identical. It also looks identical to the animation sent, unbaked, to the renderer (top view) The "baked" version (bottom view) is also similar but show some slight differences, particularly in the behavior of the top bone in the chain. I can't think of a good reason for them not to be identical, however. It's possible that if you had a one-bone dynamic constraint you might be getting a very different appearance between unbaked and baked. This test uses just the default settings that happen when you create a dynamic constraint. I believe "simulate Spring Systems" is left over from the old cloth scheme and isn't relevant to dynamic bones. It's greyed out on my screen.

This is something that has bothered me, but I've never gotten around to investigating it. Logically, an unbaked dynamic constraint sent to render (not Netrender) should look no different than a baked one sent to render (not Netrender) since both start from Frame 0 and work their way through the animation with the same imaginary 1/24th second units of time. That's the way i see it. What do other people think?

I'm not close to being done either, but I was waiting for someone else to ask first. I hereby move that we extend the deadline by a month! How about it, Paul?

You could experiment with keyframing the stereo frame distance as the camera zooms in. Just see that it is in front of what ever the closest visible object int the frame is. I'm not sure I've seen a stereo zoom before. It probably wasn't technically possible in old movies and zooms, in general, have fallen out of fashion in modern movies. But we're making a semi-old movie so give it a try!

We could break it into two shots, divided by a reverse angle shot of the observer putting the binoculars up to his eyes. ?

How about Steam? I don't know much about Volumetric effects, but they're sitting there waiting for someone to use them... Steam02_v17.prj

BTW, the Tasmanian Tiger was a real animal, now extinct. You can

try this: SpriteClouds07_emmitters_keyed_off.zip -Remember the sprite needs to be painted to imitate the direction of light in your scene. You may need many sprites if clouds are seen at quite different angles. -Sprites are not affected by "fog" so some other way will need to be contrived to make sprite clouds fade in the distance for a more realistic effect. -the fps in this PRJ is set to 120. I was trying to to reduce the sprite popping by shooting fast and slowing the frames down to 24 fps. Mark's suggestion (above) to have sprites slowly fade-in at birth is likely a better solution. -the "landscape" is just a quick placeholder I dashed out to serve the purpose. -better clouds shapes will make more convincing clouds -a better sprite would help a lot

TSM2 does something like that. It probably only means that the text that goes there didn't load. Try saving and reloading the PRJ right after the error happens. Either way, make an A:M report of it.

Yup! I love easy solutions!

A slightly less-burned crust look... Getting a good crust look is turning out to be the hard part.

You're going to composite the CG hulk in live action? I'm eager to see what you come up with.

Testing out some bread materials to go with my cheese...