robcat2075

If you want to send me the file, Gene, I'll take a stab at it.

Gene, have you been moving any of this around on a removable drive?

I don't recall needing to type "Web Subscription". When does that come up?

My initial guess is like Fuchur's...maybe you hit the NUMLOCK key?... but in a desperate situation you can also right-click in the view window, choose "Views", then pick a view from the menu. You can also do Tools>Customize>Tools and enable the "Views" toolbar to add onscreen icons for the view choices. They're kinda small and look a bit too similar, but they do give you an on-screen button in case your number pad was broken.

I think that's mostly working well, but maybe he needs a bit more of a chin for the wide open mouth pose to work?

The deadline for completing your Rear Window segment has been extended (to Sept 30.) If you need more time to render, you got it! If you need more time to animate, you got it! If you didn't even get started and still want to do a bit for the project, you got it!

Turn on Show More Than Drivers then you can see the groups in the chor and animate the properties. But glow radius is a property of the Chor itself. Animate it there.

I forgot that you were on Mac. The TSM2 plugins don't work with the current MacOS. They work in Windows 32-bit A:M only. You can rig a character on PC with TSM2 an use it on the Mac, however. It sounds like one of the other AM rigs is a better idea for you.. There are threads here with instructions for each of them.

I prefer TSM2 for being easy to to install and having modern conveniences like a heel raiser bone and an IK spine that make it easier to pose characters. The newer AM rigs like 2010, Lite and Squetch are also much more modern than AM2001 but I'm not familiar with their workflow, so i keep using TSM2. You still have to assign and weight your CPs to your own discretion with all of those, and TSM2 does not include a scheme for rigging the face. My preference has been to roll my own face rig to suit the circumstances.

Well, that was scary. The model bone and Hips null "bone length" had been set from a few cm to a few light years in length. Possibly you had accidentally selected several things at once and adjusted something. try this: Eve_Blox_Toon8_mostly_fixed_.mdl Tip, when using the AM2001 rig always set "Balance Rigid", "Balance", and "Steady" to 0% and resave your character so they will be permanently set to zero and never turn them on. They only make posing the character harder. Always do that for all AM2001 characters.

Glow is rendering here in 16b. Try this sample PRJ and render preset GlowTest.prj Glow.pre A workaround is to do a second render with the object set to all white and 100% ambiance intensity on against a black background. In a compositing app, blur that and composite it on top of a regular non-glowing render. A compositing mode like "lighten" or "add" would prevent the black of the glow render from darkening the regular render.

Quicktime exists only in 32-bit versions of A:M. Apple hasn't created the code for Windows 64-bit apps to use it yet. AVI works if you choose "uncompressed" or have installed some 3rd party AVI codec that is a true 8 bits per channel codec.

that is spooky looking!

Definitely Dont' despair. We'll be here for a while.

Mark, if you can show us the case that comes out very differently that will speed things up enormously. Without a misbehaving PRJ in captivity it's hard to study the problem.

As far as the threads... they look so fine on that picture that you could probably just lathe ridges on a cylinder and not worry about them actually being a spiral.

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.