robcat2075

It's supposed to be 320x240

The 13% figure might represent A:M using one core out of "eight"

the 3.9 figure for your CPU is for "turbo" which I think means it's available when running something that needs just one core (like one instance of A:M) i have no idea if that is automatic or if there is a control for that.

Here's some explanation of "Core Parking" http://bitsum.com/about_cpu_core_parking.php

You are using the render preset that goes with the benchmark, right?

Well, that's disappointing! First thing I would look into is the Control Panel>Power Options and see what is set there for a "plan" You can create and name a new one there and then do "Change Plan Settings">Change Advanced Power Settings> Processor Power Management>Minimum processor state>100% to encourage your computer to run at full speed. Give that a try and report back. I find that even with that set i still have to run three instances of A:M to trick it into running at full speed. I just tested v18 for the first time now... If I run just one A:M the benchmark takes 5:09, if i run three A:Ms it takes 4:52 Those times are with my CPU ostensibly running at 2.4GHz If I use a utility that came with the mother board i can bump it to 3.0GHz and get 3:54.

I'll note that what I meant is to scale the character's model bone in the chor. That will be simplest, but making a new version of the character in the model window might be possible... hmmm... I'm not sure.

If you just need to use the action without transitioning to other actions you could scale the character -100% on one axis (probably X) to mirror him and everything he does.

That's a fine first project!

If anyone wants to try this... switch to regular OpenGL and load this PRJ HandToHand01.prj Select the Red Thom and then switch from Chor mode to Skeletal mode. Does that work? On mine the view window won't change to Skeletal mode and I'll get a freeze if I do a few further things like a zoom or a Turn. But that only happens in regular OpenGL.

Serg, here's a workaround... -Create the Rand() expression like you wanted to. -Set the FPS of the Project to the rate that you want your Rand function to change ( like 3 fps) -"Bake all actions" - set the interpolation of the baked random channel to Hold -set the Project FPS back to the original FPS.

Happy Birthday Dhar! I've had the pleasure of meeting Dhar in person when i've been out to SF and I can report that he is doing well these days!

As an experiment I used QuickTime Pro to convert a JPG numbered image sequence to Quicktime movies in Animation, Photo-JPG and H264 codecs and a TGA sequence and imported those into A:M (32-bit) I tried each one as a camera rotoscope in the default chor. My observation is that A:M doesn't actually load all the frames of these things just because you've imported them, it waits until you need to see a frame, then extracts it from original file and stores the decompressed image in memory for later use. All five formats worked as rotoscopes but the time it takes A:M to initially extract and display frames from Quicktime movies is longer than for image sequences. Scrubbing through an image sequence is fairly responsive but scrubbing through a Quicktime source is pokier until enough frames have been extracted and loaded. Photo-JPG seemed to be the fastest of the Quicktime codecs and H.264 the slowest. It is unlikely you will ever encounter a QuickTime in Photo-JPG, however. The only reason I can think of that you would convert a source to a Photo-JPG QuickTime rather than an image sequence for use in A:M is if you wanted to retain a soundtrack. Numbered Image Sequences are probably your best solution for rotoscopes and decals in A:M

Now an A:M report. Hopefully Steffen can look at that.

I presume the AO was "Transparent AO" off?

I haven't tried it recently but a simple QuickTime codec like "Photo-JPG" may work adequately for rotoscope purposes because it has no compression that depends on pre- or post- frames.

The eyelid/eyebrow structure always baffled me for a long time and I'm still pondering the best strategy for it.

Targa should work, that's what i always use. Did it crash or was it just slow? I suppose it's remotely possible whatever you are using to export your targas is doing it in a variant that A:M isn't familiar with.

David, I watched your AtTime tutorial and I think i am using it correctly. Good tutorial! Here is a demonstratin project that shows teh difference between a keyframed target and an expressioned target. ExpressionTest08_keyframe_vs_expression.prj In both chors the Vase has an expression to set it to the Y value of the Null at 1.5 seconds. In Chor "Keyframed" the null is keyframed in a conventional manner to float up and down. In this chor the Vase stays in a fixed place, as expected. In Chor "Expressioned" the null is on a Sin() expression to make it float up and down. In this chor the vase does not stay fixed and follows the Null.

My observation so far... AtTime works properly if the target it is getting a value from is something that is keyframed. If the target is something being moved by an expression, AtTime does not work correctly. I didn't save my working example where the target was on a Sinewave expression and i can't recreate it today. Maybe i dreamed it.

This will just transfer the problem to a different object. This would make it much simpler. Currently you get a circularity or a crash if you try to assign a value from the same property, even a past value.

Is the SSAO on the left?

Some nested "If()" statements along with some "AtTime()" statements could probably get a few things like that done. What would be an example of what you would want to do, Robert? Serg wants to get a random value captured less often than every frame Say, capture it on frame 0 and assign it to the Y property and then leave that value on that property for 5 frames. Then... Capture a new random value on frame 5 and assign it to the Y property and then leave that value on that property for 5 frames. And so on...

Basically i want to sample and hold a value until i need to sample it anew.

That is my first suspicion, but not supported by the case where we are sampling from a sine wave instead of a random noise wave. I dunno.