robcat2075

I ran the A:M three teapots benchmark on my Core 2 Quad Q6600 machine. At the stock speed of 2.4GHz it takes about 5:10 per frame I have a utility to overclock the CPU. At 2.8GHz it takes about 4:14 per frame, which is about 20% improvement for only a 16% increase in speed. But at 3.0GHz the time goes up to 4:40 per frame. So what goes wrong at that higher speed?

that's a good composite!

Interesting. Does your old user name not work?

That is very good. I don't know about running it from the mac side but on my PC I get faster benchmark times if I run several instances of A:M (number of cores - 1) and send them all rendering simultaneously. Just one instance of A:M wasn't enough to get Windows to throttle the CPU up to full speed.

Cool! He previously had a website where he made them available but the links are all broken now. Here is the link to his Youtube page... https://www.youtube.com/channel/UCUOzJhz941BBdMMb6gg0R1g/videos Thanks for contacting him, Mike!

The poll has closed! Watch this space!

I just tried an ultra simple test case with this PRJ saved in v18 Groomong Test03v18p.prj Try that in your v19j and see what happens.

@Jason Simonds Jason, does the password problem Rusty describes in the above post sound like anything fixable?

Hi Matt, There does seem to be a pinching of "spherical" maps on lo-res splineage. I was able to make it unnoticeable with a 32-section sphere. You should be able to swap that in without having to redo the animation.

Today, January 14, is last day of Microsoft support for Windows 7. Windows 7 end of support

The action is a file on your hard drive somewhere, just like a .mdl or .prj is. on your Actions folder, choose import and navigate to where ever the Action (.act) is saved and load it. Then you should be able to drag it from the Actions folder onto the model in the Choreography.

I would suggest importing the action into the PRJ first.

Send him a PM on the forum. See the red envelope on the upper right? That is where you send PMs on the forum.

Hi Jason! LTNS! In the absence of an internet connection, Hash can do the authentication by email. Contact Jason Simonds in a PM on the forum for the details.

Do you just want the character larger? Proportionally larger in every dimension? After you drop it in the Chor you can scale it larger with the yellow bounding box that appears when you select the model in "Director" mode. If you want to make the character taller but not wider that is trickier.

I presume you don't just mean scaling the whole character larger. One way is to go into Bones mode where you can use the scale manipulator to scale bones. If you hold the CTRL key, the bone's CPS (and its child bones and their CPs) will scale with it. Since all the children scale too, it is often useful to un-child portions that you don't want to scale and re-parent them afterward. For example, you might un-child the neck and head if you only wanted the spine to be longer. The proportions of child segments can become very strange if their bone is not exactly parallel to the bone being scaled. This process can work well if you have a version of your character that is unrigged, with just geometry bones in it, that you can rig after you are done stretching. Because of the complex parenting in rigs, this is VERY unlikely to be simple or satisfactory if you try this on a rigged character. This would be a great problem to bring to Live Answer Time.

Here is another experiment. Watch the tall X as the camera moves away. (clearer if you hit the full-screen button) As soon as the jaggies get small enough to not be seen... a larger set of jaggies get swapped in. Some decision is being made too soon. LongPull2PNRC.mov

Those are classics!

The rings seem like a very specific effect that I think would confuse most viewers for outer space shots. I'm going to guess that your browser is set to not take cookies from this site. i never have to sign in when i come here unless i've intentionally logged out.

Here is a further inquiry into multipass rendering of displacement maps. I shot the same set of domes and pyramids to render displacement maps with 1, 16, 64 and 256 passes, then put each of those on a copy of the curved shape. These are all excerpts from the same rendered frame, the only difference is the displacement map on the model... The 1-pass map shows a slight banding in the displaced shape With the 16 pass map it is noticeable... With 64 passes, even more so.... 256... ouch! Somehow the data is being quantized into narrow bands when the displacement map is being rendered. Since it gets worse with more passes, something must be going wrong in the calculations that combine the data from the multiple passes.

Did someone here send me a fruit basket? I got one over the holidays but i don't know who it is from. 🤔

Bump! Vote now live in top post!

Here is a surprise. Compare the peaks of the hemisphere shapes between these two renders. This first one shows noticeable stair-stepping... When I examine that stair-stepping VERY closely, it is like a plateau, then several short steps packed together, then another plateau, then several short steps packed together... In this version the stepping is not nearly as obvious... Both have the same resolution displacement map and both are OpenEXR format. However the displacement map for the top image was rendered with 5 passes while the map for the bottom used only one pass. I had long presumed that more passes was better when making displacement maps but that is not the case! D'oh!

Do you mean that what the AE tutorial showed wasn't good enough or that you couldn't get what he showed in the tutorial?

This comparison uses the same displacement geometry rendered from the overhead camera at resolutions of 640, 320, 160 and 80 pixels wide, then applied to the same curved model. This frame was rendered at 640x480, 16 passes. Notice that the number of stair-steps on the tall X is the same on each model. This suggests that it is not a lack of resolution in the displacement map that causes it. If it were I would expect there to be 4x the number of steps from the 640 pixel map as from the 80 pixel map. Below is the same frame rendered at 4x4x the resolution (2560x1920) with just one pass, then shrunk down to 640x480 in Photoshop. For most anti-aliasing purposes I would expect this to appear the same as the 640x480 16-pass render since both are sampling the same number of points (4x4) for each final pixel. However, the stair-stepping on the "640" model is greatly reduced now. This indicates there is enough information in the 640 map to produce a better result but it was somehow not being all used. Notice that the "80" model has the same frequency of stair-stepping as in the original 640x480 render. This suggests that the original render was using ¼ x¼ of the information that was present. Could this be as simple as a MIP-map problem? Below is the same frame rendered at 640x480, with the displacement maps reset to BUMP. Here the diagonal lines render nearly flawless.