I am rendering some animation for a DVD.  Is there an ideal resolution  I should render at? 

My machine is not so good so i really don't want to spend the next several weeks rendering at super-high rez.

Thanks for your help.
 

Depends if you render for Pal or Ntsc.
NTSC resolution is 720x480 pixels, frame rate is 29.97, and PAL outputs to 720x526, at 25 FPS
The pixel per inch parameter has no importance here, so you can render at screen rsolution.
If you need very high quality renders ( and avoid sky banding that can occur frequetly), I suggest to use 16bit TIFF.

Quicktime (Animation codec) or AVI (Cinepak Codec by Radius, or Microsoft DV) is what I'd suggest - at the normal resolutions described above by Bruno021.

You're going to bring the finished animation into another program to convert the video to create a DVD (which will also create menus, etc.), so don't worry about formatting it "for" DVD when rendering the animaton.

Good luck - hope this helps-
-Lew ;-)

I really suggest you render an iamge sequence, not a video from Vue. It's better to have a non compressed format. Any avi or mov use codecs to compress video, and these codecs are different from the standard mpeg2 used for dvd format. Better render an image sequence and use a video editing software to create your dvd.

I dunno - I've had a lot of great experience with Quicktime - specifically the Animation codec - not Sorensen (which has also worked very well). The Animation Codec is a close to uncompressed as it gets - incredibly clean with good crisp blacks and sharp details. And at standard resolutions (NTSC - noticed you were in Oregon) it doesn't take that long (the second you jump up to 1280x720 or bigger, good luck on the times!).

And no matter how you cut it, both formats I've mentioned above (even both versions of AVI) are higher quality than mpeg2 at its best - and you'll be bringing in the final animation into ANOTHER program anyway to create the DVD, so as long as you start with higher quality video, it'll look great when you're done.

This discussion, however, has NOT covered render settings in Vue - which you shouldn't be skimping on the settings in the first place if you're actually going for quality - I realize you were only asking about resolution size, but tis really needs to be covered as well or no matter WHAT res you  have it'll just look like junk when you're done. I've done a number of exterior moving background renders for video (for outside the windows of car driving scenes), with Vue settings of Superior, rendering in the Quicktime Animation codec, and they have all been fantastic.

Go for Superior - NOT Broadcast quality! I know this is adding to the render times, but it will NOT be blocky muddy shadows, and it will not have the dull highlights. The resolution is actually quite manageable (720x480) and will go faster than you might think. The final video will be much more crsip to bring into After Effects or Premiere or Final Cut Pro for editing and/or color grading, to match/integrate with video footage, etc.

Hope this helps-
-Lew ;-)

I will have to disagree again about render settings, sorry, lol!
All render prsets have their pros and cons, but they mostly have cons, imho.
For instance, the advanced effects quality slider at final is set to 46%, and above 50% for braodcast, this is way too high, 40% is more than enough and will cut render times. On the opposite, the AA settings for both presets are too low, and no preset use the texture AA and texture filtering options, wich are absolutely necessary to avoid flickering in the materials.
So you should always use your own render settings to lower the advanced effects quality, add texture AA and texture filtering to avoid flicker, choose your own AA settings, and also, get rid of unwanted features like motion blur or dof that broadcast uses by default, even if you don't want blur in your anim.
As for quicktime, I'm not saying the compression codec is bad, I'm just saying that it is already compressed, and that converting a mov file to an mpeg2 file will add more quality loss.
It is better to convert once, and only once. This goes for movies, photos and sound files alike.
Each time you convert or compress, you lose quality.

True - very true about the render settings - except I keep motion blur on as it looks much better for moving footage - yeah, it takes longer, but looks fantastic in motion. While most people are looking to maximize their render settings to get faster renders with the least negative effects, I don't really care about that. More often than not, I just set it to Superior, and the format to the Animation Quicktime codec.

And I know I'm harping about the Quicktime codec (keeping in mind I'm a Windows user - not a Mac guy). The "Animation" codec specifically is lossless (though there's a slider if you DO want compression - just keep it all the way up to the highest quality), and this is what it's really made for -animation. So you can have the best gradients and lines and clariy fo creating animations.

The only downside is that your video files will be enormous in comparison to anything else. One recent video ended up being just over 1111MBs for the same duration as the 23MB DV file I was incorporating it into

-Lew ;-)
.

Ah, ok, I didn't know there was a lossless quicktime codec.
There is also a lossless avi codec, but after a few trys, it doesn't look lossless, I can see compression.

My patented screed on animating to codec..... This is the result of a lot of experimentation, and reflects more than a few months of learning the hard way. One of the seemingly neatest things for animators is the ability to have your preferred 3D application render with a codec, so you just go away and have movie file of some sort waiting for you when you get back. But if you've noticed, a lot of animation troubles seem to get back to the fact that the image output was codeced as it was rendered. One of the most common being pixellation or mosaic artifacting as the movie file is played. The absolutely best method to deal with this (and a host of other issues) is to -not- attempt to create a codec compressed animation straight from a rendering program. Render your animation as uncompressed frames (bmp's, tiffs or targa's. png's....and more and more apps have .psd output, so you get the option of output in photoshop layers, which can be a godsend for postwork. Or if you have After Effects of Combustion, there is rla/rpf format...) and assemble them in a video editor. A quick search will reveal the existance of several freeware apps that work well; if you go the purchased route, the less expensive end is the Magix line of software or the Quicktime Pro application. If you want more power, either Adobe Premiere or Final Cut, After Effects or Combustion. And there are others. While this does add a stage or two to your rendering pipeline, the benefits far outweigh the cost. 1). by doing frame rendering, if something causes the render to abort, in most apps you can simply advance the frame counter to the frame just past the last good render and start from there. If you are doing codec compression as you render, and something bombs, you have to start from scratch. 2). You have uncompressed frames that you can take into a graphics program and perform work on. Say you render a scene and find that you miscalculated your amibient light levels, and things look a bit washed out (or too dark. Or there was a color level glitch. Or you get the idea....). You could import the first frame into Photoshop (or your app of choice; I still use PaintShop Pro), fiddle with it until it looks right, then batch process the rest of the frames, instead of wasting the time rendering the scene over again. 3). You have a raw source to save your butt with. Once you have those frames and are satisfied, you just burn them to disc or back them up to a safety drive. If something happens to that scene later in postwork, you have the raws to reload, instead of having to render it all over again. 4). Video editing apps tend to give you far more control over what a codec is doing. The halfway decent ones give you the options on pixel shape, screen ratio, compression rates, and a bunch of other things. And this lets you experiment with settings until you are satisfied. Don't like how one compilation turned out? Just do another one with a different codec and screen ratio. Find that your output has mosaic artifacts? Change the compression rate slightly. You can do anything regarding the final output, and still have your raw frames to start all over again if you goof. 5). It is far, far easier to add sound to uncompressed frames than it is to add them to compressed video. A lot of codecs assume that you are wanting 'television' kinds of video output, so they take some liberties to get that. One of them is 'tweening' which is filling the gaps in a video stream by averaging between two compressed frames. If you are trying to synchronize a sound effect to something, it is possible that the 'frame' you want as your sound start doesn't really exist, except mathematically. So you can get a slight timing error. It might not be noticeable....or it might be just enough to blow the whole scene ( ready example is to open Poser, import a character, set a pose at frame 0001, then go to frame 0030 and set another one, then run the animation. If you look at the animation pallete, there should only be keyframes highlighted at the first and last frames; there are no 'real' keyframes in fields 0002-0029, but since the figure has motion through that timespan, all the elements that make up keyframes are there. In animation that is called interpolation, but it is also an example of tweening, as the computer takes the values between the two keyframes and averages it 'between' all the others. If you tried to add sound in that 'tweened' timespan, you would be utterly dependant on your ability to fiddle with things until it sounded and looked right, and this is an aquired skill). 6). Post effects work is far easier with frames. Particularly if your applications support .psd layer output, or one of the embedded alpha channel formats. You can get your alpha mask as a layer (the white on black 'light' layer that can be used to 'cut out' sections where things exist in another animation, so you can composite the two together) for example. The whole problem with codecs in general is that render applications are memory hogs. But so are codecs. And when one gets into a fight over the memory pool with the other, one or both stutter, pause, and tend to get a bit unstable. And codecs assume that they are going to have all the resources they need for the compression part of the work. And pausing a compression, or even slowing it down, can create artifacts that are impossible to get out. This has been my experience. Additions and comments are more than welcome, as animation is such a complex process, the ways to accomplish the task are sometimes daunting

Well, DaleB, this is a neat post. Very informative, and I hope it convinced thlaly to render an image sequence, and not a video out of Vue.

If not, then a few 4 digit sequences getting bombed from a power flicker will....particularly as it usually happens about 3/4ths the way through the job... Or the completed job done with DivX, and the compression ratio being one of the magic 'you shouldn't have done that' numbers that turns the output into a mosaic wonderland. Rendering to codec is an excellent feature for outputting a quick and dirty test strip to see about scene integrity....but for final output, it just doesn't provide the consistent quality you need.

I do understand the process, and consequences of compressed codecs - power outages in the middle of a render, etc. I really do.

Keep in mind also that rendering to an "image format" is also controlled by a codec - jepgs being compressed, and TIF, Cineon, Targa, etc. being uncompressed types of formats - it's the software using a set of image code to create a viewable image from theoretical data (3D data we're talking about) that an editing or viewing (still or motion) application will have to de-code to view - hence the term "codec" - code/de-code - its a "process" - not a specific definition of what defines a "video" code, therefore making it compressed because you're using a "codec". Get it?

I'm also taking this from the point of view of what I do - create moving (or still for mattes and extensions) 3D elements for video. When rendering stills, I make them TIFs, and when I render out motion, I use the Quicktime Animation (QA) format - because it's an uncompressed moving TIF. And there's a setting for rendering a QA as RGBA - yes, the A stands for exactly what you think it does.

I'm not creating image sequences for the next Ice Age or Shrek movie, so I'm not gonna generate enormous Cineon files - I'm putting stuff out that will end up on versions of Youtube and up to standard-def  DVD quality. And since I'm now doing FX for HDV productions, I do the same thing.

And if there's a bad frame (or a power outage and you only have half the movie file), you can go back and render just that frame (or the rest of the movie file starting from the first frame lost) and insert it into your timeline - I have the complete Adobe Production Suite for all my post production in case you're wondering - as you were mentioning apps above and what you can do with them. And when I finish the elements in After Effects, I render them out as QA (RGBA if it's going to be an extra visual) files for Premiere to edit.

Because again - it's being integrated in DV footage(5:1 compression), or HDV footage(same high compression, but higher res so it breaks apart even faster!), and will be output at incredibly compressed formats (MPEG-2 - or variants of teeny file sizes for the length of footage)). While there are NO artifacts in what I do and create, there WILL be in the final output format that will be viewed. So generating something like a TIF sequence is overkill.

Yes, I realize this dove WAY OT, but here we are.
-Lew ;-)

Thanks for all of your input.  Interesting differences.  I have been rendering uncompressed frames as I will be editing them and compressing for final on DVD.  

If I weren't post working the frames I might be tempted to use a lossless codec but as stated in the discussion, stopping a codec render means starting the whole thing over.  Been there, done that.

I always remember the time I recorded an mp3 off my sound card and saved it as an mp3.  By doing this I had taken away so much sound info that it sounded like a speaker in a tin can.   Original mp3 had 90% compression and then copied and lost 90% more.  Multiple compressions kill!! 

Thanks again for your ideas.  I was going to render too large.