robcat2075

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.

Thanks for the tutorial! I was not aware that Action Objects could be in a Pose, I had only known them as being in Actions.

Yup, Sculpt3D was my first 3D program, also on the AMIGA. I recall rendering anything with shadows was painfully slow. You could watch the image form one line at a time and it was like it would snag and stop on every shadow. After three years I had about 60 seconds of spinning things rendered and made this video out of them... 6IiUwVFV2lY

About 25 years ago in my first CG job i once accidentally deleted about three day's work. I turned around to see if anyone had noticed but they were still all toiling away at their desks so i just started back in redoing it and never told anyone. That was back when three day's work could fit on one floppy and you had to "format" floppies before you used them. Formatting the wrong floppy was the crucial mistake that day. I recall another temporary job I had doing graphics in an office and there was a guy at the computer next to me working away on something he had been working on for a long time. Suddenly he starts screaming. The power on his computer had flicked off for a second and it was rebooting. I kept one ear open to listen to the crisis meeting that developed at his desk between him and the managers. Apparently he hadn't saved anything significant for days, he had just left the computer running all the time with the project open in the program. And now it was gone. D'oh!

That is fabulous. When I started this benchmark the computer I had could manage it in 19 minutes, now mine can do it in about 4-5 minutes. But 89 seconds... that is impressive.

A laptop back then didn't have lots of HD space... or did it? I wonder what it was exactly that she had a copy of. My brother tells of working at Control Data in the 80s and watching a salesman demonstrate a super safe system they had introduced that was really two computers mirroring each other. The salesman was going to unplug one to show how one could fail and yet the system would continue to run on the other with no loss of uptime or data. So he pulled the plug and everything immediately died. It turned out another salesman had done the same demo the day before by unplugging the other computer and never plugged it back in. Or so the story is told.

First, if you never use more than 25 multipasses this was a non-issue and even if you do it was mostly undetectable. The following is only for the painfully curious. One way A:M does motion blur is with multi-pass. It slightly increments the point in time being rendered for each pass and moving objects appear blurred as the passes are blended together. As the number of passes is made larger the fraction of time between passes must be smaller. It turns out A:M stores time in "ticks", not seconds or frames, and A:M counts 135000 ticks per second. Every keyframe you make is stored internally as a number of ticks elapsed from zero. This makes it possible to change your PRJ from 24fps to 30 fps, for example, and not have your animation run 25% faster. A:M can count up to 18,446,744,073,709,551,616 ticks which is somewhat more than 4.3 million years. 135000 was chosen because it is evenly divisible by all the common frame rates and further divisible beyond that for most multipass intervals. For example, at 24 fps, each frame is 5625 ticks apart. At 20% motion blur the multipass increments must be apportioned over 1125 ticks and with 25 passes each pass is exactly 45 ticks apart in time. Previously, A:M would calculate that ticks-per-pass number at the beginning of a render, multiply that by the number of the pass it was about to render and then add that to the number of ticks that represented the start of the current frame to get the time of the current pass. Up to 25 passes that calculation worked fine, but beyond that problems occurred. At 121 passes, 1125 divides to about 9.2975 but in ticks that has to be either 9 or 10. Ticks can only be whole numbers. With many passes the small error would accumulate to a large error with the result that motion blur increments would either not make it to their full distance of desired blur OR they would get to the full distance too soon. This composite shows a bright white dot constrained to travel a path, from the brown lines on the left to the brown lines on the right, in 20% of one frame with multipass set to 20% motion blur. At 121 passes the dot has traveled less than the 100 pass version and at 196 passes the last dot is brighter than the rest, indicating that several passes have rendered it in the same spot. For motion blur purposes this error was usually unnoticeable if the motion blur was too short, but in the over-reach cases it could create a detectable solid image at the end of a blur as too many passes were being assigned the exact same instant of time. This was also a problem for light-on-a-spline situations with the light ending up stuck at the end of a path for part of its intended sweep. In v18f this is fixed! Steffen has changed the multipass subdivision calculation so that it now calculates the ticks for the current pass as (current pass number/total passes)*motion blur fraction* ticks/frame This eliminates accumulating error and the resulting tick count for each pass is never off by more than a fraction of a tick. Thank you, Steffen, for fixing that!

Look around for some previous discussion of this possibly with contributions by steffen (yoda64) It may be a non-issue with Windows 8 since that doesn't have Aero anymore, AFAIK.

I hadn't though about it for a while, my Win7 is set to basic graphics all the time. In v17 there's an Options>Global switch that prevents A:M from turning on basic graphics, but it's needed for some of the interface to display properly. That switch is gone in V18. Somewhere around here there's a discussion of why that is. Look for "AERO" My recollection is that A:M still needs to run with basic graphics, but I'm not sure what the current details are... since I'm always in basic mode anyway.

I can recall a few days like that where things looked very odd. At the time I thought the skylight was the wrong color. It was an overcast sky but somehow it looked very bright and orange.

Here is the introduction of the tutorial on AO and SSAO I was working on before I stopped working on it. I though it was important to make sure people knew what these effects were trying to do but maybe it's too obvious? This is unedited. There are several spots where I repeat myself to try to phrase something in a better way with the intention of editing it later.

Good to see you back Kathryn! As always, I enjoy seeing your characters.