robcat2075

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.

Good to hear they got you put back together. Was it Duct tape or Super Glue?

Looks like the deal is off already. Hope some of you snagged it!

I do hope to see an entry for every one of those yes votes. Get started!

Bargain hunter alert... as of today May 9 2014 they are on sale again for an even lower price. See top of thread for details.

I don't think you should composite the final image unless there's no way to render it all at once. Maybe it's feasible to render sprites separately but sprites aren't really all that time consuming unless you need shadows out of them. If you have to composite them I suppose it might work like that way i composite "glow" in my "It Can't Be Done" tutorial.

I like the idea of the streaming particles. With two months to R&D it I think it can be done.

there are some bones visible in that thing that are a mystery to me. Like I'm not sure what "ArmControl" is intended for. It's possible that some bones are visible that should not be... but i don't know.

Do you mean the bones names "clavicle"? Those you animate directly to adjust the shoulder when you wish to. They won't be dragged around by the IK arm.

Which ones are not working?

It's ironic that they were so careful to use underscores instead of spaces in their pose names but then left a leading space on the front of one. D'oh!

I think I've found it! There was a leading space on one of the Pose names " OLAAfans_DoNotTouch" in the original file. Somehow that is correctly interpreted when the original file is loaded but lost or corrupted on resave causing all of the constraints in that Pose to not work. I text edited it out of the original file then loaded and resaved that from v18 and have sent you that v18 MDL. Try it out. I haven't looked to see if the smartskins are working. Those are sometimes trouble on old models.

This is quite a riddle. To look at the relationship properties it appears that the constraints are there and properly targeted and yet, they stop working.

I just got a bunch of PM notifications that were about a year old. I had read the messages long ago, but only now am i getting notice that they arrived.

It's something peculiar to this old v8 format. If i resave in v10.5 that file is able to be reloaded and still work in v10.5. That is a small success. I notice that I get an error when i resave. "file argument" or something like that. Also the v8 file is crashing my text editor which is weird.