Rendering

When I am ready for a final render I always set final quality render settings, render to TGA sequence with a frame step of 2. Rendering takes half the time (of course), then I assemble the tga sequence and play it back at half speed. (animate on 2s, anyone?) If i like the timing feel and do not find anything that needs changing, I go and render the other half number of frames, and then assemble them all together. This way, my first "render" takes half the time, so if I decide to throw it away, then I have lost only half the time, but if I decide to keep it, half of it is ready already! :-) This has been a time-saver more than once ...

Sotiris Gougousis

I think what we all have to realize (especially myself) is that there are often major shortcuts that can be taken to drastically reduce render times.

For instance when panning or zooming the camera within your animation, instead of doing it in within the animation program frame by frame, render *one* matte frame, perhaps 4 times larger than your project frame size and *pan/zoom* through it using a production tool like AfterFX, Premiere or now even *Animation Master*

Doing a scene pan like this frame by frame (calculating lights, shadows filtering, etc) would have been very expensive timewise within AM.

Rendering this in Premiere (image pan filter) took about 2 minutes and exporting it to this MOV file took another 1 minute or so.

Granted there are things you lose out on, for instance if i wanted the clouds in the background to move i'm outta luck.

However when rendering the original matte scene, an alpha channel could have been used for the buildings then rolling clouds could have been added onto another track in Premiere.

Things like flames, flickering lights, etc., could also be rendered seperately and added in post.

The idea is to look at your animation and determine what can be *reduced* to a single matte image for the background and what foreground objects need to actually be rendered frame by frame.

Ultimate you'll be creating your animation in layers. This way you'll depend more on your production tools than your animation program.

You will gain a little more flexibility because if you don't like a particular part (layer), only that part needs to be edited and rendered again.

An example that comes to mind is Laurie's Alien movie -- the pan/zoom to the front door could have been a *single* 4x rendered wideshot image panned using a production tool or AM2K, then the door opening sequence would be added next and so forth.

I'm not sure how long it took her, but i'm sure this technique would have shaved a good number of minutes off of her render. This also would have allowed her to play around with the timing of the pan/zoom sequence without having to do any more rendering in AM.

The great thing about AM2K is that you now have animatable rotoscopes which i (and perhaps others) had sent in a request for last year, so now you can render your large matte background image, load it as a camera rotoscope, *pan and zoom* within that rotoscope and also have stuff from your chor interacting with it! (those rolling clouds and flickering lights for example)

The funny thing is, i actually find AM better at some things than say AfterFX, not to mention if you want to warp your images in AFX, you'll need the production bundle -- with AM, just create a 10x10 grid, map your AVI to it and muscle move your grid for the warping!

With all of the compositing features in AM2K, expensive programs like Premiere and AfterFX are not really required any more to use these techniques.

-William Bell

Rendering speed /is/ effected by the scale of your geometry, though you probably won't see much difference unless your scenes already take a few hours to render.

- Brian "balistic" Prince

This is nicely implemented in AM200. (Thanks, guys!)

Create a plane under your objects, and mark it as "Receive Shadows/Shadows Only" in the properties panel in the chor.

When you render, this plane will not be visible in the RGB channel, and the only portion of it that'll be visible in the Alpha channel will be whatever falls under a shadow cast by another object.

-Mike Caputo

Set your render quality to "Wireframe", and use at least 200% oversample.

A:M NetRender has a multipass feature that renders the same frame multiple times. This slows rendertimes greatly, but increases render quality beyond words. It improves all anomolies of motion blur... it is no longer nescessary to antialias... Dmap shadows are WAY more realistic in the latest beta due to some new jitter effects added to the lights.

The trick is finding the number of passes that looks the best and isn't an overkill. At somepoint there won't be an apparent difference in quality between the number of passes.. (but a HUGE speed hit).

What the multipass does is:

Say you have frame 1 and 2.. and multipass set to 16 passes. A:M divides the "time" between 1 and 2 into 16 segments. It then renders each segment and overlays the results.

So motion blur is rendered 16 times each one slightly offset. (which gives a more realistic look).

There is no need to antialias because it is redrawing the scene 16 times.. so in that process the edges are redrawn 16 indivdual times and overlayed.

We use multi-pass exclusivly for all our renders and it gives us amazing photoreal results. (You should see some of the HDTV stuff we rendered at 25 passes!)

Jeffrey Dates

Since there is been some talk about multi-pass rendering, I thought I would show my enthusiasm and support for this concept and also shed some light on all of the benefits of this very COOL technologie.

Here is a list of all the things you get with multi-pass rendering.

1. True Motion Blur (anything that moves will motion blur) with controlable quality.
2. True Depth of Field with controlable quality.
3. Very High quality anti-aliasing once again with controlable quality.
4. Incredible Area Light sources (Any Spline can be a LIGHT!) without using multiple lights or multiple shadow rays!?
5. Fuzzy Reflections and Refractions with controlable quality.
6. No need to use Filter or Anti-Alias option in Rendering.

BTW, ALL of the above features happen AT THE SAME TIME. That means if you turn on any one of these features you can get all of the other ones for FREE! (meaning there will be no extra hit in render times.)

THIS IS ALL CAPS BECAUSE IT'S REALLY IMPORTANT. MULTI-PASS RENDERING IS SLOW. AS THE QUALITY OF MULTI-PASS GOES UP SO DOES THE RENDER TIMES. IF YOUR NORMAL RENDER WITHOUT FILTER TAKES 30 SECONDS/FRAME, WITH MULTI-PASS SET TO 16 IT WILL TAKE 8 MINUTES! WITH MULTI-PASS SET TO 25 IT WILL TAKE 12.5 MINUTES! BUT, BUT, BUT YOU MUST REMEMBER THAT YOU GET ALL OF THE ABOVE AMAZING FEATURES FOR FREE!

Since I'm listing all the things you GET with multi-pass, I should also mention all the things you DON'T GET when you don't have multi-pass.

1. Pixel Streaking Motion Blur (only works on moving objects) i.e. shadows, reflections, transparencies, animated textures, lens flares, glows WILL NOT motion blur.
2. Post Blur Depth of field (sometimes produces unwanted halos around objects).
3. Non-User controlable Anti-Aliasing (you only get one setting on or off).
4. Very slow area light sources that only produce Area shadows, NOT true Area light source effects.
5. Fuzzy reflections and refractions can only super sample to one setting (the default that you can't change)
6. The need to use filter that gives you one default super sample setting that once again you CAN'T CHANGE.

Turning on any of the above features WILL add to your render times; unlike multi-pass where ALL of those features are FREE.

Greg Rostami

I do a lot of print work, and I came up with this workaround:

1. Set up your camera so you've got your subject in your sights.

2. Zoom into the upper left-hand corner of the image, so you can see the edge of your aiming frame. (You should make a rough calculation of how small an area you need to zoom into, based on your print needs.) Render.

3. Take a screen shot. On the Mac, I do command-shift-4, which lets me select the area I want to save.

4. Hit M, grab the bottom righthand corner of your frame, move over it over to the left hand side, keeping the vertical even. This ensures overlap between your images. Render.

5. Keep working your way across down, across, down, until you have rendered the area you need.

6. Open up the screen shots in Photoshop. Trim the edges. To line things up perfectly, I set the new layer to Difference, so that when the overlapping pixels line up, there is perfect black. Then I set the layer back to Normal and paste the next one until I've quilted everything together.

It's kludgy, because going back to a consistent zoom is difficult. But it works. And because I'm rendering piecemeal, I can always select a smaller area to render if I get the "Out of Memory" message.

Eric Dehais

I did a Huge render of one of our images. . . I set my screen at 1600 X 1200, visually zoomed into the top left corner of the camera window and did a progressive render. . . then a screen shot. Went to the top right . . . screen shot etc till I had all 4 pieces of a HUGE image. Then in Photoshop I just placed them all together and it worked.. . just fine. Well not just fine cause I was up till 3 in the morning trying to do it but it worked. . .

Billy Eggington

No, it doesn't.

Live-action which is originated on video, has fields which are obvious in frames where there is fairly rapid movement. If you are compositing CG and live-action (originally shot on video) together, then field rendering helps to match the "video" look (although you are not forced to do so).

Here in the UK, where our (PAL system) TV is at 25 frames/second (each as 2 fields), material originated on filmstock, and shown on TV/video, has no "interlace jitter" between fields, so the fields are not obvious, and the best option (IMHO) is to do non-field rendered CG for compositing (but with some motion blur). I can't comment about the best choice for film transferred onto NTSC video (where there are considerations such as 3:2 pulldown, of which I have no practical experience - though I would have guessed that the ideal option would be to reconstruct the original film frames (if dealing with material already transferred from film to video [assuming film=24fps and NTSC video=~30fps], composite without fields but with blur, then reconvert to NTSC video)

Personally, I think that field rendering is an over-rated facility, and for fast-moving objects I tend to select motion blur as my first priority. One of the components of the "stop-motion" look is that there is no motion blur ( so much so that "go-motion", where stop-motion models were shaken to blur them while being photographed, was invented!). Field rendered CG, without blur, tends to look a bit like very smooth stop-motion.

Dave Corcoran

No. But if your output equipment lets you use fields, you have an option to use field rendering. Field rendering can be very useful if you have camera moves, to avoid strobing.

On the other hand. A year or so ago, while working in another software package on cartoony characters (not cartoon render...just cartoony). I found that when I field rendered them, their motion just became too smooth and didn't look any good. I think that people get too used to a slight strobing effect when watching animation (most cartoons are drawn on twos...12fps) that when there is none, it just doesn't feel right. F.eks. the Iron Giant (as far as I know)was rendered on 12 fps second, to better fit in with the hand drawn animation.

Ragnar Brynjulfsson

Ok, so the makers of Iron Giant had a special software thingie made to vary the lines of the toon.

I just made a proof-of-concept test using AM99 and the toon renderer. I can share what I did, so you can try it on your own.

Make a test model or use a copy of any model you want. I started with something simple. Open the model prop panel, toon tab, set thickness to .50 (as a test) and change the line color to black. Open new cho, have the camera set to toon and default so the camera won't over-ride the model toon settings. Render to file as TGA with a step 3, file name = test000.tga, range 0 to 30.

Go back to the model prop panel, change the thickness to 2.50, and render to file -- step 3 again, this time range 1 to 31.

Go back to the model prop panel again, set thickness to 1.25, and render to file -- step 3, range 2 to 32.

Open QT3 or 4 pro, and use "open image secquence" choose your test000.tga image and let QT do it's thing.

Play the movie, see the concept, make mental notes for adjustments for the next time you want that Iron Giant look. I bet we can come close. If *you* come up with the "perfect combo of settings" please share the findings...

-Jeff Cantin

Because of the changes made to the renderer in 7.0/7.1, this is the equation for memory needed to render:

60(bytes) x width x height + textures/image maps + data, thus:

 Lo res		320 x 240 	= 4.4MB
 TGA 		512 x 486 	= 14.2MB
 D1 		720 x 480 	= 19.8MB
 HDTV 		1280 x 720 	= 52.7MB
 Panavision	2048 x 871 	= 102.1MB
 Print Res	2400 x 3600	= 494.4MB

NOTE: The above figures represent just the RAM needed for the image size. It does not include the RAM needed for additional textures/image maps or data....

Steve Sappington, Hash Inc.

I get that message when I've forgotten to close the movie file after Master signaled MoviePlayer to open it for me. So I watch the movie, don't like something, switch back to Master, twiddle for awhile, and send it off to render. When Master tries to write that first frame into the movie file, the OS tells Master that the file is already open Read/Write by another application and bug off, so Master reports that to me. Sound like it could be what you're experiencing?

Jim

Check your power management settings. If your hard drive is set to power down it will cause AM to hang during a render. Make sure your hard drives don't power down when you are rendering. I have mine to power down after one hour. If a render is going to take longer than that I switch my settings to never power down.

Mike Hovland

You said your power management was turned off, but double check for any proprietary management put in by the computer maker (e.g. my Compaq has its own management feature that has to be disabled along with Windows 98's power management).

Don't use a screen saver.

Shutdown any unneeded programs. If you're just rendering, A:M should be the only program running.

Make sure your CD Auto insert notification is turned off. It's not needed and steals part of the CPU cycle to operate. It can slow some programs down.

One recent thing I found is to set a limit in VCACHE to stop memory hogging by all programs. It helps keep system resources normal. Run sysedit

Under Windows/System.ini look for the vcache section. It will probably be empty. Add the following lines

MinFileCache=1024
MaxFileCache=8192

That will force Windows to write to the hard-drive instead of holding data in system memory, lowering system usage (which can cause any program to hang) and speeding up disk access.

Kevin

In addition to the other thoughts posted, are you running ICQ? I found that Hash would crash occasionally when ICQ was running, and was fine without. Not sure exactly why, just an observation.

Chad

I had the same problem and it almost drove me crazy. I then found out that the render hadnt STOPPED or STALLED, it was just a problem with my design. The number of lights and shadows was causing the render time to be somewhere around 2 days. It always seemed to stop at 40% and then not move for hours, but the clock kept running. I reduced the number of shadow casting lights, played around with having some of the objects not casting or recieving shadows, and started using the ambience options instead of all those lights. Believe it or not, this brought the render time down to just over an hour. I hope this helps out.

Mike Kelleher

Well, the same problem is occuring in both systems and both systems have one thing in commom, the same old video card. I had a herc card that crashed hash seemingly whenever it wanted to, I switched to a TNT chip card and it made all the difference in the world. BTW before the herc card, I had and old ATI PC2TV card too, I can't remember the details, but I didn't like it, I think I ran some video tests I downloaded from the web and the PC2TV card failed a bunch of differnt tests and even hung on one of them. If I were to make any suggestion on hardware, I'd say look at a newer model video card.

Jeff C.

You might want to reduce the shadow-settings on your lights, and if possible reduce the number of lights that are casting shadows (like down to three, or so). I find it hard to believe that you really need 15 ray-traced shadow-casting light sources (although I could certainly be mistaken) but if you do then it is likely to cause this type of slowdown no matter what you do.

-- Tony

I've found that raising the Diffuse Falloff value greatly increases the "soft" look of an object. This setting varies the curve along which diffuse light falls off before it gets to the object's 90% line and disappears completely. Raising it gathers the diffuse light up, so that there's a more gradual falloff near the 90% line. It will also make the object look somewhat darker, so you'll need to use more light on it.

--Raf Anzovin

Most of the time when oversampling (v7+) is used, it is unnecessary to use the Filter render option. In addition, in certain scenes with shadows, a big speed increase can likely be had by using soft shadows......

Jeff, Hash, Inc.

I believe you can get the shading you are looking for in AM99 Beta. What you need to do is turn OFF Flat Shading on the Render panel, and turn ON Toon Render on the Render panel, and turn ON Toon Shading on the Toon tab of the model's Properties panel. This will give you dark side shading (don't confuse this with shadows).

-Ken Baer

The *only* thing that will speed up final rendering is CPU speed. More RAM will speed up AMs rendering only if you don't have enough for your scene and the renderer has to keep loading image maps on every frame. If you don't have that prob, go for a faster CPU. A video card will (may?) only speed up quick-shaded renders, not final.

ed Lynch

I haven't tried with the new V7 renderer, but in V6.1 if you set Flat-Shaded, and then add shadow-casting lights, those shadows will (if deep enough) show up as flat darker regions on the model.

- Tony

Just to let everyone know, if you have a PC with APM, (Automated(?) Power Management) it might be the cause of your "freezing" I consistently get 30 minutes of unattended rendering, and finally figured out that Windows was putting my system to sleep (Hard Drive) and it would cause Hash to "freeze". This didn't effect my renderings in Inspire, (although it adds about 20 seconds to the render time when it falls asleep) but causes AM to freeze.

I have since disabled all Power Management in Windows as well as my CMOS. ANd now everything is Happy!!!

Patrick Clarke

On a PC the screen res is approximately 72 dpi, so for most printers thats going to make very small images when printed at PC printer resolutions. An 800 x 600 screen grab would be

• approx 2.6 inches by 2 inches at 300 dpi, and
• approx 1.3 inches by 1 inch at 600 dpi

So if you wanted your image to print on a 300 dpi printer and have the image be 5 inches across you would have to render the image at 5 x 300 = 1500 and 3.75 x 300 = 1125

Now you have to have enough memory to render this size image. Here is a copy of approximations of memory requirements for different render sizes from an earlier posting about this.

• Hires (640x480) ~5MB RAM
• D1 (760x482) ~6MB RAM
• Film (1200x800) ~16MB RAM
• Poster (4000x3000) ~200MB RAM

The calculation is as follows: Multiply the width by the height of the intended resolution and multiply the result by 24. Divide by 1MB (1024K).

Don't forget the 26MB necessary for interface overhead.

If you do it this way you do *not* want to re-sample the image in a program like Photoshop, just adjust the dpi setting from 72 to 300.

Hope this makes it clear for ya,

Jeff C.

For video, you need to know the resolution of the hardware you'll be using to lay your digital files to tape...some cards like 640x480, others prefer D1 (720xsomething) ... If you aren't sure what you'll be using for final output, 640x480 is probably your best bet, because it has a square aspect ratio... film resolution varies from movie to movie, and sometimes from scene to scene...I've heard that 2000 vertical pixels is pretty much the bottom end for film work...

Bear in mind I don't have a /whole/ lot of experience in this stuff...but I've been on quite a few mailing lists :)

Brian "balistic" Prince

For full screen broadcast quality video which will be put on videotape or TV you need to match the resolution of your render to the video format you will output to. US has NTSC, Europe has PAL. PAL resolution is 768 x 576, I cant remember just now what the NTSC resolution is since i live in Europe. PAL framerate is 25 frames/sec, NTSC uses 30 f/sec.

If you only plan to render small graphics (logos, small characters, fly-by's etc) you can save render time by rendering the object only and compositing it into your scene later. Use the PAL or NTSC resolution as a guide and render only the portion of the screen you need.

DV video format has funny oblong pixels at 720 x 576, but unless you specifically work with pure DV files, I wouldnt worry about it.

640x480 would do the job (it's standard for 13'' monitor) especially when it comes to just VHS quality, while the standard for digital NTSC signal is 720x486 with non square pixel (called D1). I guess you should use D1 format if you want the broadcast quality.

But as for AM98, I'd recommend you to do the rendering in like 800x600 then resize it to 640x480 because of the anti-aliasing problem. 6.1betas are getting much better (read much better) anti-aliasing but still it leaves something to desire. I'm planning to do my animation in such a larger size then resize it in After Effects. I remember a post saying that doing the rendering in double size then resizing back in Flint (SGI...) makes the rendering quality competing that of Renderman, and doesn't hit that much rendering time as we might suppose.

And the film....wow. In After Effects setting, res for film is 2048x1536, and I think it's the minimum. (About super 16mm quality?) For the 35mm feature, I heard they even use 4k by 2k size, with 10bit per channel color depth.

AV drives are supposed to guarantee the continuous data stream, which is critical for realtime playback of the movie files. Besides the higher RPM, they have larger buffer and separate heads for reading/writing the data, as far as I know of. So if you use some serious NLE system, AV drives or even RAID is a must. But, if you're going to do transfering to video at some service bureau and don't need realtime playback capabilty so bad, just buy regular harddrive with larger capacity with the same cost.

Euisung Lee

640x480 will get you by, but usually most print houses like the output to be in a standard format. Here's what we've used in the studio...

• 720x486 = Standard NTSC video size. 640x480 will also work, but looks funny.
• 720x576 = Standard PAL video size.
• 1125x633 = Standard HDTV video size.

Those are the ones that we use whenever we output to video. For film... That's entirely different beast. Seeing as how film resolution is so much greater than video, the higher the res, the better looking the image on screen. Here are two of the more popular ones that we've used.

• 4096x3072 = 35mm Full Aperture; 1.33:1
• 4096x1743 = 35mm Anamorphic; 2.35:1

Although you could get away with something lower. I've run tests using 2048x1536 for 35mm Full Ap. and 2048x871 for Anamorphic. Again, this is just what we've worked with. PIXAR's output res for TOY STORY was 1526x922, and that took up over 500 gigs of space. That should help you out a little when you get ready to output.

Now, about the the AV hard drive.... The best advantage of having an AV hard drive is the speed. AV drives run faster than normal drives, usually by about 1-5 ms faster. The AV drives that we use in house are all 9ms. The faster the drive, the better playback of the animation/video you're going to get. Hope that answers your questions. Any more?

For the rest of the members, I appologize for the bandwith, but I felt that this information could be used by all, seeing as how we're all trying to do the same thing... GET OUR WORK OUT TO THE MASSES!!!! ;)

Curtis Rhoads (aka The Vong)

Required sizes:
• NTSC (USA) 720 x 486 (@30fps)
• PAL (Europe) 720 x 576 (@25fps)

However.... if you simply create a graphic with these dimensions & import into a DV app it won't look right. This is because graphics apps use a different size pixel than video apps. So even though the _number_ of pixels may be correct, the different _size_ of the pixels causes a difference in appearance.

When creating a graphic image for a Digital video (DV) project, it's best to create it in the dimensions:

• 720 x 540 (NTSC)
• 768 x 576 (PAL)

This is a square pixel resolution that contains the maximum detail. Then resize the image to the native frame size of the video app, 720 x 486 (NTSC) or 720 x 576 (PAL). The resizing process adjusts the frame size to correct for different pixels used by graphics applications.

When you view the image in a graphics app it will look distorted. However, when you bring it into the DV app & convert to non-square pixels, the image will stretch & thus look correct. Hope this helps clear things up a little,

My understanding is that the NTSC format has a square ratio, meaning that the shape of the pixels are equal in height and width. D1 on the other hand, has an oblong ratio, meaning that the pixels are slightly wider than they are high.

So, for either case, the dimensions are correct. However, if you render to D1 at 720x480, the image on the D1 system will look stretched out because of the oblong pixels because you didn't counter for it in your original render.

To counter this effect, render out to NTSC size, 720x540, and then resample every frame's width so that the final size is 720x480. Now the image will look too skinny to your eyes, but on a D1 system, with the oblong pixels, the image will be stretched back out to be the correct aspect ratio. Get it?

As I think about it, I would actually render to an aspect ratio equal to NTSC but use larger dimensions, so that the resample will look better when I go down to 720x480.

Jim Sherwood

If I were you I would either:

1. Render at 720X486 with a .9 aspect ratio [0r]
2. Render at 720 x 540 then use a program such as Premiere to squish the height to 486 (squish, not crop). This in effect will give the correct aspect ratio.

Either of these will be good for the Avid.

As far as the gamma goes, I'd leave it at none and see how it looks. If you find it too dark and contrasty, try raising it.

Joe.

That is a lot of questions, let me see if I can answer a few. I use Premiere and AM98. NTCS is 29.97 Hz. It puts out half the frame lines (every odd or even line) (this is called a field) at about 60Hz. My experience is that moving a set of targa images from AM at 30 frames per second and at 640x480 into Priemere produces great animation better than SVHS if your computer system can sustain the data rate without dropping frames.

Fred Mendenhall

It can be all those things, and more!

I think (and I'm going out on a limb here, because I've never really taken apart a TV) that the problem here is that everyone is assuming that a television is, at its base, pixellated.

It's not.

TV is pixellated in the vertical direction, because it scans distinct lines. This is built into the nature of the signal.

However, on the horizontal plane, the signal coming into the television is analog. The TV is just given a continuous range of color to display. The fact of pixelation is caused by whatever phosphor mask your particular television has.

So, the NTSC standard actually does not list a horizontal resolution, because it's not relevant.

That having been said, individual video cards deal with the problem in different ways. Some decide to go with square pixels, because it makes life easier. Because NTSC has a 4:3 screen ratio, and has 480 (give or take) lines of video, that results in 640 pixels across each line.

Other cards decide to be compatible with D1, which results in a 720 horizontal resolution.

Theoretically, I suppose, a card could output 12764x480 resolution, but if no television ever showed that much detail, it wouldn't matter much.

I know that this doesn't help with the original question (about the Avid), but I thought it was an interesting little bit of technical trivia. Maybe it will help somebody someday. :)

-- Tony

Well, TV output is really analog across the horizontal plane and digital across the vertical (because of the scan lines). So, you have 480 scan lines vertically. You can really have any resolution horizontally, depending on the output hardware you use, it depends on the video output card used to convert the computer signals to NTSC. Many cards use 640x480 because that's a standard computer resolution. Some of the higher end equipment use 720x480. (I haven't seen these side by side to know if there's much difference) Whatever horizontal resolution your output card takes is scaled to fit across the TV screen. Some cards may take any resolution and automatically adjust the output accordingly.

As far as the 29.9 vrs 60 Hz, I think that is either a confusion between monitor and TV, or fields. Most standard VGA monitors have a refresh rate of 60Hz. Many nowdays go much higher, but it is the standard. As far as NTSC, there are 29.9 frames/sec (usually just referred to as 30), but each frame has two fields that are displayed sequentially. Each field uses half the scan lines. Field1 uses 1,3,5,9, etc, and Field2 uses 2,4,6,8,etc. So you can think of this as either a 640x480 image at 30Hz or a 640x240 image at 60Hz.

Nope. They just render frames. You can render your animation at twice the frame rate, and then let Premiere interleave the images, it depends on what you want. If you don't render with fields in mind, each image is used to create both fields. If things in your animation are moving slowly, then this if perfectly fine because there is not much difference between frames. When things are moving really fast, then lots of movement happenes between frames, and since fields happen twice per frame, the output can look a bit jerky. (The same kind of jerkyness you see when you take a typical animation and run it at say 5frames/sec, but it's just not as pronounced)

Should I not even worry about fields and just leave all the field options on default for Premiere to handle?

Again it depends. For most stuff, working with 320x240 images seems fine for me. Basically, the 320 is streched out across the horizontal, and both fields are made identical. When you move to 640x480 (no frame rendering), the resolution is higher, but really the frame rate is the same as 320x240. (True the fields render at different times, but the scene itself does not change) When you move to 640x480 (with fields) then it's like running 640x240 at 60 frames/sec. It's been my experience that when you have a complicated, slow moving scene, 640x480 without fields is fine. When you have a fast moving scene, field rendering can make a significant difference.

Of course I just do output for my own use, and am not concerned with broadcase quality, so YMMV. For the most part, I'm happy with 320x240. (Also, 320x240 doesn't take the same horspower from the computer that 640x480 does. Running with a P166 and IDE hard drives, high quality 640x480 pushes my system to it's limit, and it can't always keep up.)

John Markus

If you're doing broadcast thing, not video distribution, you'd better do it in 720x540, then resize it to 720x486. Don't worry about DPI, it does little thing to do with vidoes. Resizing every Targa frames in Photoshop with bicubic interpolation would be the most pains-taking but also the best-result-guaranteeing method.

You can also do that in After Effects, but I think AE can only do the bilinear interpolation(?). But at least it's better than no interpolation, and you can use just uncompressed Quicktime file rather than bunch of targas.

I'd do nothing on Gamma setting in AM. You really need to check how it appears on NTSC monitor and adjust all the gamma and color saturations in Avid, with the feedback on properly calibrated NTSC monitor.

You mean shrinking the size? I don't think QT3 alone does proper interpolation for resizing the movie file...? You may ask your friend who has After Effects or Flint on SGI(!) to do the job... otherwise you should do it in Photoshop as I wrote above :(

I think Debabelizer is best known for shirinking color depth of the image or movie for multimedia things. You wouldn't want to lower the color depth of your animation which should air on broadcast network, would you? :)

Euisung Lee

DPI (dots per inch) are relevant when you print your image. Some graphic file formats (e.g. TIFF) store DPI information; TGA doesn't.

Also in no significant order:

D1 Aspect Ratio

http://www.puffindesigns.com/support/white/wht_d1.html

Re: Graphics re-sizing

http://www.mediacube.de/avid/user-group/avid-l/Sep/msg00075.html

RENDERING FOR VIDEO

Preflight Check List
http://www.3d-design.com/magazine/0498/0498tome2.html

Aspect Ratios: A Frank Yet Candid Discussion

http://www.cs.ucsb.edu/~aduncan/Aspect/Aspect.html

The Avid FAQ a.k.a. Wisdom from Avid-L (Feb.1998)

http://www.texvideo.com/dslazyk/avid/andybavid.htm (try Section 6.6)

Mark.

Yes, the settings are in PhotoShop. Hash is just rendering pixels. You determine how many pixels you want for your printed image and then set that number in AM. Don't worry about what the "DPI" says in Hash.

For example, if you wanted to print out a 6" X 9" image at 300 DPI, then in AM, set your render resolution to 1800 X 2700 (6" * 300dpi X 9" * 300dpi)

When you open it in P-Shop, adjust your image size to reflect 300 DPI but don't let it resample the image.

Tommy D'Aquino

It makes no difference which way the camera is pointed.... the resolution you type in the render to file dialog changes the camera box.

For example, if you type in 360x240, the image will be wider than it is high.

Jeff, Hash, Inc.

When you put an object into a choreography and select its properties there is an option for "flat shaded". Check (select) this option and then render it using normal renderer(not toon renderer) thney you may get something.

Hayden Vimaas

I am working from memory here, so I could be wrong about some of this, but AFAIK:

Those are the Alpha, Shadow, and Depth buffers you are referring to, I take it. They are all used for compositing purposes, which is a lengthy discussion in itself ;-) Here's the highlights:

The alpha buffer creates an Alpha channel in the rendered TGA- and by the way all buffers will only work if you are rendering to sequential targas(rather than AVI's or Mov's). The alpha channel is used to indicate which parts of an image are background. This is useful information to have if you (for example) wish to composite you character onto a background later. Compositing is helpful for speed reasons- why render a background every single frame when you can drop it in later? The Shadow buffer stores information on where the shadows cast by a model are. The way to get this is to have an object such as a plane in your scene set(through properties) to be invisible but receive shadows. The shadows won't show up in the render this way but the shadow info will be stored in the shadow buffer. Then, once again you composite the foreground image with the background and your composited image has shadows in the correct places. There's quite a bit more to this one but that's the gist of it.

The Depth buffer stores Z-order info- i.e. how far away from the camera objects are. An illustrative example of how this is used might be best: You have a scene with a room full of objects that your character will walk around- boxes, tables, chairs, etc. To save rendering time you can render one frame of the set(room with all the boxes chairs etc.) on its own, then make the set invisible and render all you charcter frames. With a depth buffer you can compisite all the character frames with the single 'set' frame and have your character end up in front of/behind stuff as appropriate, automatically.

Hope you could follow that. As I said the subject of compositing stuff is a pretty in depth one. Feel free to ask lots of questions!

The buffer checkboxes save extra data into your targa files for use in post production...alpha buffer generates and alpha channel for your images, and depth buffer generates a depth-of-field blur channel...

Brian "balistic" Prince

Real time rendering is software or hardware rendering that occurs at a much faster rate than final rendering with the software based rendering engine in the application. Usually real time refers to rendering that occurrs in a special chip on your video board. It fairly crudely renders the image on your screen, and allows you to interact with it (scale, twist, move etc.) while it remains rendered; kind of like a video game. For most of us, "real time" is a bit of a misnomer-- it takes some serious hardware on the video board to actually manipulate a rendered scene of any complexity. But, it is much much faster than final rendering, and is usefull for setting lights and tweaking control points, and for getting very fast test renders of animations. The degree of rendering that the card does in "real" time depends on it's hardware-- bigger, better more expensive cards support higher resolution textures, better lighting, bumpmaps and transparency.

For example, MH3D for the PC supports hardware rendering using D3D. There are other engines like openGL and QucickDraw3D, and others. In Hash, you will not be able to use HAL mode (in rendering options) unless your card specificly supports D3D. Other apllications support only OpenGL, so a D3D card couldn't talk to that application. Some cards supprot many real time API's. If your getting a new card, you want to know what it supports, and what your software needs it to support.

Hash also has a fast "real" time renderer in the rendering options called RGB emulation. You can use this with any video card. It renders very quickly, with limited detail (like most realtime renderers).

To see this yourself, open hash, bring in an object. Go to Tools/options/rendering. Set the driver to RGB emulation, which it probably already is. Check the "show decals" box if your object has decals. Check Bi-lnear filtering if you want, it makes the real time rendered textures less pixelated. Now, go to the object, slect the object, right click on it. On the flyout go to Drawmode, and select shaded. The object will render, kind of crudely. You can now manipulate it and it will stay rendered.

Now create a simple animation using the object. Go to Render to file. Under quality select Quick Shaded. This will un -ghost the real time options you mentioned. Check the decals box if you have decals on the object. Render the animation. It comes out very fast, and comparitively block and un anti-aliased. But you can see the motion exactly, and it takes a fraction of the time that final rendering does.

Kerry

Well ain't this a kick in the pants. Remember that speed thing? And when I gave Jeff the project to test? And how we had basically the same results? Where his render time (266MHz) with everything on a 400 X 400 was 18 minutes, and mine (210MHz) was 24 minutes?

Well all that was done with a model that did not have any bones in it yet, since I was just doing phonemes (bones just aren't detailed enough for me).

My client wanted her head tilted. So I added two bones: One for the body and one for the head.

It seems that adding this tiny little detail has sped up both the scan-line and the raytracer immensely.

New time: at 600 X 600, everything on. About 5 minutes!

I talked to Ken Baer about this, and it's just as surprising to him as it is to me. There's no explanation for it. Adding the bones juked up the speed like I've never before seen.

So v.5's renderer is not only faster, the raytracer is shitloads faster too!

Now to post this to comp.graphics.animation.

-Armando Afre PixelShop(TM)

OK, Armando discovered a really cool tip that can dramatically speedup some renderings with V5. If you have an object (or character) that has some raytracing (transparency, or raytraced shadows on it, or reflections) you can speed it up by putting bones in it. What happens is that it has to search through the geometry for every ray, which we do with a BSP tree. This is bone based, so if you have a high patch count model, and divide up the geometry among bones, it doesn't have to search as far. The reason we didn't encounter this much before was in V4 the geometry was already divided into segments. And most people making high patch count models in V5 are already using bones. Remember this is only an issue if you invoke the raytracer and have a lot of patches and few bones.

-Ken Baer. Director Mac Product Development, Hash Inc.

This needs to go in a FAQ, because I've gone through this a lot lately. The raytracer is invoked on anything with transparency, objects or maps. If it's a map, just the map, not the rest of the object that doesn't have the tranparency map. Also, on cookiecut maps only in the part that is transparent. It is also invoked for reflection and refraction. And finally for raytraced shadows, which is set in the light. That's it, all the rest is Z-buffer because we want good anti-aliasing and speed.

Procedural textures add a little more time because every point that's visible needs a calculation. Decals are much faster especially if you turn on caching.

-Ken Baer. Director Mac Product Development, Hash Inc.

Hmmm, if you have a lot of bump, and/or cookie-cut decals, use Filter. If not, don't because it takes longer. Also use Film Grain to help aleviate the banding in the volumetrics. If your model is complex, make sure you've boned it so the SW doesn't have to look that far in the skeleton tree. This is a huge render time-saver.

-Armando Afre PixelShop(TM)

Here's what Glenn wrote. It's the most complete explanation to date. The muscle info isn't entirely accurate: meaning it doesn't slow down the renderer like he said, but everything else is on target.

This post was in answer to one of mine. The most important thing to ad to this, in order to GREATLY speed up render time, is to make sure you have your characters I.K.'d so that the SW doesn't have to look so far in the segment tree to find the appropriate patches.

Quick Explination of the renderer.

Unlike V4, V5 does not raytrace every pixel, What it does is shade the patchers directly using A-buffer, this is a lot faster because it does not render blank areas (Like v4 did) Also the A-buffer by its very nature is 32x anti-aliased. (Try rendering a scene with no options, notice that the shadows/reflections are not anti-alised but the object is)

Now materials like decals and procedual textures have to be raytraced , But this is quick UNLESS you use a lot of muscle motion/bones where the patchers are distored. This is because the renderer has to 'distort' and 'strech' the texture with the patch thus taking more time to calculuate.

Certain texturles like roughness are expensive because they also spawn the raytracer. Transparency / reflections / refractions also require a lot of rays, so the raytracer will slow the renderer down. By how much depends on the nature of the material.

Decals should be fine, but types like cookie/transparency also require the raytracer to look through the surface.(Fow shadows and to see through). But I BET that if you can model it rather than use a cookie cutter it would be faster. (Simple shaded patchers are cheap to render)

Shadow maps (New to v5) are like projection maps from the lights, The renderer generates a single greyscale image of the shadows from the lights point of view and applies it to the scene, Much like a decal. This is why the shadow maps are so quick cause they are NOT raytraced.

The problem with Shadow maps is that they sample to something like 16 pixels, so thin objects have a harder time showing up in shadow maps. (How about Hash create a Hi-rez shadow map option?) Armando this will also be why soft shadows dont work well with cookie cut maps

Raytraced shadows are by their nature are slow, since the renderer has to work out if any part of the object is in shadow.

Now if you think about it, all this extra raytracing isn't anti-aliased unlike A-buffer... so If you turn on the FILTER option the raytraced portions are then Anti-aliased by something like 8x or 12x. (And the funny problem with edges is fixed in 5.26 I think)

So if you think about it, If you create a model, that requires V5 to use the raytracer A lot, it will render the scene at 8x / 12x AA (Not sure) ... more than v4. (Unless using the v4 "Still" option which can be _up to_ 21rays)

So remember that "Shaded pixels are any that do not have raytraced attributes, transparency, shadows, reflections, roughness etc" and they are rendered the fastest with 32x AA

Yeah thats the raytracing anti-aliasing kicking in. (How about a filter options that are seperate for shadows / materials / reflections? so we can anti-alias what we need?)

I think the problem is that both the renders are really different ... While v5 is faster in some areas it maybe slower in others. I think ya need to work with v5s strengths.

I dont think Hash just decided to make v5 renderer on a whim, Think about it, They would of carefully planned out each feature, Its a balance between quality and speed, In most cases v5 WILL be faster, But its a trade off, In some cases it may be slower. That means that certain tips, tricks and ways of making a character that worked well in v4, may not work as well in v5.

The general rule of optimization is "optimize the common case" ... the gives the best improvement in speed for the majority of cases.

You will probably have to try things differently in v5, and at the end of the day may have to make a compromise here and there. ( Put up with not very detailed shadow-maps and cookie cutters)

I'd suggest clearing the object of different type of textures one by one, and then testing the renderer, remove a decal, Render and note down the time, remove some other texture then render another image, note down the time. Id be interesed to see where the slow down occours.

Again its an "unlearn it" thing.

- Glenn Wilton

I just completed my most complex model with about 3100 patches, with a chrome material that was applied to several parts (activates ray tracer). With no bone but the default black bone, the render took over 15 minutes at 640 x 480. I added two "do nothing" bones and assigned most of the CPs to the new bones and left a few still assigned to the black bone, then I re-rendered and the new render time dropped to 5 minutes! Just for the fun of it, I added a third bone and assigned the remaning CPs to it so NONE were assinged to the black bone and my new render time was 2 1/2 minutes! Woo hoo!

Thanks to all who figured this speed-um-up stuff out, it works!

Jeff C.

Front Projection maps are for combining 3D with a live action background.

Let's say you have a house that you want a CG UFO to cast a shadow on. Use the live action of the house as reference from the camera view to make rough geometry that matches the perspective of the house. This house geometry you check "front projection target". Then load the live action house into the camera as a front projection map. If you place your UFO where it can cast a shadow on the house, it will look like you are casting a shadow onto the house in the live action plate if rendered from the camera view.

Maybe someone else can double check me. I did a test with this about two months ago and I remember it working great.

Glen

In my current project, A walrus walks into a bookstore and pops up into a window at the counter. The Bookstore is real with live actors. The window area at the counter is real. The background behind the counter is real. The walrus is CG. I need the walrus to appear between the counter and the background. So I've built a matte object that matches the cutout shape of the window and counter area as seen through the camera. The video images are loaded into AM via camera rotoscope and for my matte, I've given it the option of receiving front projection mapping. Now, when the walrus pops up behind the matte, he has live video in front of him, and live video behind him.

Tommy D'Aquino

It appears that some of the people on the list think that I just chose Direct3D because of a love for Microsoft or something. So I thought I would clarify a few things... I have written drivers for nearly every 3D API there has ever been (D3D, SGI OpenGL (CosmoGL), Microsoft OpenGL, Conix OpenGL, Intel's 3DR, RenderMorphics, RenderWare, Heidi, and 3DFX to name a few). I came to the D3D conclusion for many reasons, and trust me it is the biggest piece of #!$&@! API I have ever worked with. Here were some of my findings:

Silicon Graphics OpenGL - Very good, very easy to write API. Just a few problems prevent this driver from being useable. The triple buffering that we do requires copying in and out of buffers in multiple directions, and not always the full size of the window. This copy is very slow when done between two offscreen buffers. This is why moving, zooming, and turning are fast, but moving something around is slow. The current rev of this library does not support hardware, bummer. That's it, if someone would get on the horn with me, and tell me what the fast path is for this copy, this driver would potentially be my non-hardware driver of choice. I will also say that the quality of the rendering out of OpenGL is better than that of D3D.

Microsoft OpenGL - The OpenGL API is supposedly a standard, right? Well why is it that the exact same code is used for all three OpenGL drivers, but this one shows some different problems. Like the fact that the wire frame does not sit on top of the shaded model, intersecting it and looking kinda shabby. And the big one is that when you have a textured model, only the first polygon renders. No help from Microsoft in curing these problems, and until they are cured this is not ready for human consumption.

Conix OpenGL - What can I say the dude is a stud. With the help of John at Conix this API screams.

QuickDraw3D - Needless to say a piece of junk (for a real-time modeling environment). I did not actually write this driver, Ken Baer did, and to no fault of Ken's, and really no fault of Apple's, this API just wasn't designed for the way we needed to use it. In this API you must render the whole frame or nothing, so moving some control points around on a face meant rendering the whole face, not just the affected patches. We got at least a twenty times speed up when we switched to Conix.

Heidi - After writing a test app to check out this API, and seeing that it could not swap buffers from back to front at 1280x1024 faster than 1fps, I decided not to even write I driver. I still think I must have been doing something wrong, but there's not a whole lot to do wrong swapping buffers? Heidi was actually the first driver I wanted to try. It is an API written exactly for what we are doing, real-time interaction with geometry.

D3Dv3 - The reason your driver has the v3 on the end is not that you cannot run it using version 5.0 of DirectX, rather it is because it does not take advantage of any of the new API calls in Direct3D 5.0. The only known problem is the inconsistencies between hardware vendors causing crashes on some cards (typically with textures), making it impossible to debug without actually having that particular card in my machine.

D3Dv5 - I was so anxious for this release to come so I could take advantage of the new API call "DrawPrimitive". Because of the nature of splines and the fact that our geometry changes from frame to frame, we cannot take advantage of display lists. So I must send all geometry down the API on every draw (for you tech-heads, we also transform and light ourselves). This is called Immediate mode. In version D3Dv3 there is no way not to build a display list, so I have to tediously build one on every frame for every object and then throw it away (often times more than one for each object because a display list can only be so big). Needless to say this is a ton of overhead (memory and speed), and a pain in the butt to write. What they needed was a command that would just put a poly or line to a frame buffer when asked with one call, DrawPrimitive. I implemented the new driver from scratch in one day rather than weeks, in about 1/20th the code, built it, ran it, expected a 20-30% speed gain, and got a 20-30% speed loss...explain that one. I personally think they have a sleep command down in that call somewhere.

I am unable to get any support from any of the above companies concerning these APIs, with the exception of John at Conix for the Macintosh OpenGL driver I wrote. John was extremely helpful, and is the reason the Mac version of the OpenGL driver is useable. I get the feeling from the other companies that they don't take us seriously (who woulda thunk?), and I basically get no responses from them. I rely on mailing lists to get what little info I have, and I don't have time for that. I have given will my copies of the D3Dv5, SGI OpenGL, and Microsoft OpenGL drivers to Will and told him to put them on our site for you guys/gals to play around with. See what you discover. Remember though, these are given to you as a courtesy. Any comments, bugs etc. are welcome, but there are no guarantees they will get fixed right away. These drivers are something I wrote in my spare time, not on Hash time. If you guys would like to see these drivers mature into something we can actually ship, get after the API company and get them to take us seriously. I will be waiting for their call.

Thank you, and I hope that didn't sound harsh, I just wanted to clear up some myths.

Randy Croucher

The reason you were seeing distortion in your face was probably because your focal length was too short, and your camera was too close to the model. This is similar to how a real camera works. The default focal length I believe is 50mm, which is similar to the human eye and how it sees things. For many landscape shots, photographers set the focal length to 35mm or less, which allows a wider angle of view and a long depth of field. The larger the focal length, the smaller the angle of view, and the higher the compression of the depth of field.

What that means is, when shooting a "head shot" i.e. portrait shot, you should choose a higher focal length (135mm or higher) and move your camera back away from the model. This will zoom in on the head, but compress the depth of field so that it doesn't look like your models nose is a giant appendage extending into the camera lens.

Another example is this: have you ever watched the track races during the Olympics? On the last 100 meters, they always have a camera at the finish line pointing straight down the home stretch, and you see everyone racing towards the camera, and it looks like they are neck in neck. Then, they cut to another camera, a side view pointing down along the stretch, and you see that the person in first is meters ahead of anyone else. This is because the camera pointing straight down the stretch has a large focal length of like 400 meters or more, and it's compressing the entire 100 meter depth of field down to almost nothing.

Try changing the focal length of your camera while looking at the top view, and you will see the cone angle change. Then change back to the camera view to see how the change affects the "zoom" of the camera.

-Jim Sherwood

---