robcat2075

If, by chance, there should be some sort of tie leaving more than 10 entries vying to be counted in the top 10 I will hold a drawing with me as the official name-out-of-a-hat-puller-outer to resolve that.

Some weird-looking stretch frames from "Rabbit Transit" (1946)

In addition to the Hash gift certificates for the top three entries in the Sci-Fi image contest, the top ten entrants will be receiving the a DVD of Mark Largent's all-A:M-made "The Wobbling Dead," an animated puppet parody of the AMC series "The Walking Dead." Now you have no reason not to dust off that sci-fi entry you didn't quite get finished, polish it up and jump into the fray. Contest deadline July 6 Don't be a lazy zombie! If you wake up on July 7 and find out only 9 people entered you're going to kick yourself!

Ka-Voom!

hmmm... if the pen only works with new software that would be big problem. Here is a review of the Thinkpad Yoga that ha a wacom pen. 3.5 pounds, that's getting heavy again. Lenovo ThinkPad Yoga review: a good (if slightly heavy) Ultrabook for business users

I'm sure any mention or non-mention of Wacom technology was negotiated in the licensing before hand so i'd be surprised if anyone was surprised. The "penabled" tablets were always entry-level Wacom stuff. Positionand pressure but no tilt or rotation like the high-end Wacom products have. Probably not intruding on the serious-artist Wacom market. But I'm curious now to see how this N-trig thing performs. If it has a battery in it it must be a tiny one.

I wonder how there could NOT be parallax? There's got to be some thickness of glass between the display and the pen. No? If it really has no latency that will be better than my Cintiq or any I've tried.

Here's David Pogue's video review... Smart, Versatile Surface Pro 3 Can Do It All — Maybe Even Lift the Windows 8 Curse

Heu , Will... here' what I'm wondering... Can you now make a basic shape in A:M, take it to ZBrush and add a bunch of surface detail, then somehow export a map from Zbrush that can go back on the basic shape in A:M and act as a displacement map to make it look like the denser, more complicated shape you sculpted in ZBrush?

Mark, you're right! You've made two CG movies that people actually pay to see. That is way beyond hipster.

I'm looking forward to seeing it, although I'm going to hold off until I've seen the first season of The Walking Dead that you've said will be key.

It is on the high side in price. It's never going to be a hipster thing like an iPad. If we are comparing it to an iPad it's about 25% to 50% more expensive than an iPad with a similar amount of RAM A 128GB iPad is $799 A 128GB Surface Pro 3 is $999 Both are more expensive than I would pay for such a thing but there are many people for whom the difference between this and a cheaper machine is an insignificant amount of money if this fills their functionality needs better. Endgadget has links to numerous, cautiously positive, reviews on the bottom of its page http://www.engadget.com/products/microsoft/surface/pro/3/

To me, it looks like a cool thing. I don't have a need for an iPad but when I travel I like the idea of a very light something that runs real Windows programs. I have an old XP tablet that weighs twice as much as that Surface Pro does with probably 1/8th the computing power and battery life and yet it is useful when I travel and fulfills my travel computing needs. So I look at the Surface Pro that can do every thing my current tablet does and do it better... to me that's a valid product. I probably won't buy one, i don't travel enough for it to be a major need, but i can imagine people for whom this fills the gap between iPad and desktop just right.

A review of the Surface Pro 3 I didn't even know there was a 3 yet.

Thanks, David, that loaded. If i take that PRJ set to 1 fps and make keyframes at 0 second, 1 second, and 1.5 seconds ( I have to manually enter 00:01:0.5 in the time counter to get that half-frame time) I get this in the file: So even when the PRJ is set to 1 fps, A:M still writes the keyframe times based on 30ths of a second.

a crowd simulator!.. that is something I've had in the back of my mind but have never embarked on yet. I will be curious to see what you make of that. lessee... I'm sure there's some sort of Pythagorean hypotenuse formula that would let you calculate the distance between any two points.

There was a time when the fps rate was never saved in any file. The fps that A:M used was whatever was set in the Options panel and you needed to deduce what the correct setting was for whatever work you had loaded. Sometime after we started TWO A:M was changed to write the fps setting in the PRJ. I forget how got everyone to use 24fps for TWO since we were mostly saving chors and not PRJs.

I tried copying and pasting your text and saving as a .PRJ but I get "invalid project file" when I try to load it in A:M. I'm not sure what it's missing.

I believe that documentation info is wrong. If I set a PRJ to 30 fps and create keyframes at 0 seconds, 1 second and 1:15 ( 1.5 seconds) A:M will write this in the file: If I start over and set a PRJ to 24 fps and make key frames at 0 seconds, 1 second and 1:12 (1.5 seconds again in the new PRJ) A:M will write this in the file: So whether you have the PRJ set to 24 or 30, A:M will always write the times in the file as a clock that counts in 30ths of a second (plus ticks if necessary). One and a half seconds will always be represented as 1 second and 15/30ths no matter what fps the PRJ is set to. If you are in a 24 fps PRJ A:M will be clever enough to draw that keyframe at one second and 12 frames. I can't create a case where A:M writes the values any other way. If you can that would be something to look at.

I take it back! A:M is not writing time in files as a floating point second value (what I should have said instead of seconds and a decimal). A:M is storing times as seconds plus 30ths of a second plus ticks If I make some keyframes in a 30fps PRJ I get this. I've bolded the time values If I just change that PRJ to 24 fps they still have their format of seconds-plus-30ths If i snap those keyframes to 24fps positions then they get times in seconds-plus-30ths of a second-plus ticks (after the period I thought was a decimal) The periods looked like a decimal to me but it is really just a separator between the 30ths and the ticks.

No request has been made to change it to 270000. It seems like a big can of worms to open in pursuit of a feature we will rarely ever need. AFAIK, 135000 ticks per second has been the A:M way for a long long time. I'm not sure I'd call it a "codec", I'd just call it the unit of time that A:M works with. Paradoxically, the time in A:M files seems to be stored as seconds with a decimal if needed but not a very long decimal. There must be some internal code to fix the error introduced by the short decimal when the file is read in. Mistake on my part. See correction below.

I think "drop frame number" would have been a better name.

If they mean that the frame labeled 00:00:01:00 arrives slightly later than real time 1 second, because 29.97 was counting slightly too slow, I agree with them. After 00:00:00:00, it isn't until you get to 00:00:02:02 that a frame number and the time match, because we threw out two numbers to catch the counting up. And then the frame numbers start arriving later and later again after that until we skip from 00:00:03:59 to 00:00:04:02 to catch the counting number up again to real time. For the whole frame rates you CAN set in A:M there is no discrepancy between the frame count and true elapsed time, within the limits of computer accuracy of course. A:M sidesteps the problem of counting in 29.97 by not letting you set it. . I'll note that industry opinion is beginning to accept the fact that 29.97 was never really necessary. No one has ever demonstrated the supposed interference problem that would happen by running color at true 30fps and the whole debacle is traced to a mistaken engineering report produced during the rush to set a color TV standard. link You will still find Very Serious Video Professionals insist that it was necessary but they are just parroting the same mistaken premises that have been repeated for 60 years. None of them has ever seen the alleged problem in person and none of them ever will because it can't be produced..

Best wishes for a happy birthday to you, may all your patches be outward facing! Geez, none of you are even 40. I'm jealous.

I'll note that this 135000 value is part of the difficulty in implementing a 29.97 fps rate for NTSC video. The official frame rate of NTSC video is not truly 29.97 but 30x1000/1001 which is roughly 29.97002997002997... If we divide 135000 by(30x1000/1001) we get 4504.5 ticks per frame which is not a whole number. If perhaps, in the long ago days of Hash, they had chosen 270000 ticks per second as the basic value then we could do that division for exactly 9009 ticks per frame. Another part of the problem is that "29.97" still imagines there are 30 frames for every second and counts that way. That accumulates as an error between the time it has counted and the time that passes in the real world. After 60 seconds, "29.97" has counted one fewer 30ths of a second than have passed in real time. By two minutes, 29.97 is two frames behind in its counting. To catch up, every two minutes "29.97" skips two counts. After the frame it calls 00:01:29 (which is really only happening at about 00:02:01 in real time) the next one is called 00:02:02. This is called "drop frame" even though it is actually dropping numbers and not video frames. So there are three problems in implementing 29.97 on A:M -Our tick value is not evenly divisible for that frame rate -the time scale at the top of the timeline would have to accurately exclude two unwanted frame numbers every two minutes -the time scale would have to somehow deal with the fact that almost none of the frame numbers it displays are truly in synch with real time. This is a problem for synching with audio. None of these are unsolvable but 29.97 is a rare need for animators. Most of our work is for internet video which doesn't need 29.97 and animators in general rarely do a single shot that is long enough for the time discrepancy to be noticeable. We edit our single shots together in a video editor that conforms them to 29.97 if needed and the synch error for any single shot in that new, slower 29.97 fps is always under one frame which will not be noticeable as an audio synch problem.