Now assuming it will way more time and size for a normal scene where you have two gen8 characters and an enviroment with props, can anyone help with tips and tricks to optimize the time and size of the animation?
Trick #1 - consider your frame rate. Doing 60 frames per second is nice, but usually way overkill, depending on what you're using the animation for. 30 fps or even 24 fps will usually give you smooth enough motion, and will require a lot less rendering. (Classically, movies in theaters were done at 24fps, and television in the "old days" was effectively 30 fps.) It also means the final animation will be smaller. In a pinch, you can sometimes get away with as little as 15 fps without it looking too blocky.
Trick #2 - Many times, when you render out your animation, you find something isn't right, and have to go back, fix it, and re-render. If you're just looking at "does everything move together well" (at opposed to lighting, etc.) you can use the OpenGL renderer, an option many people don't know about in DS. This is what DS uses to render the viewport when you're not in "iRay Preview" mode. It's FAST - a couple of seconds per frame. Lets you bang out a draft, pull it together into your movie form and check out all the motion without waiting hours and hours.
Trick #3 - Obviously, anything that will slow down an iRay render will hurt your overall rendering time. Reflective surfaces are one - they cause iRay to have to evaluate more light bounces. Make sure your scene is well lit.
Trick #4 - Same recommendation as
MrKnobb made. Take the first frame of your animation and render it manually, watching it converge on the screen. Figure out when it's gotten to the point where it looks pretty good and note the number of iterations it took. You can then adjust the Progressive Render settings to a reasonable number of iterations. Because the animation is, well, "moving", and because of frame-to-frame compression you don't need as much image quality as for stills.
Trick #5 - As
mickydoo said, don't render directly to movie. If Windows decides to update and restart on you overnight (happened to me a couple of times) or if DS crashes or whatever, you'll have to start from scratch. In addition, you only get one shot at choosing your compression level, etc. Render as an image series, then convert to a movie. If something blows up, you can just pick up where things left off. In addition, in the process of converting from the image series to your video format, you can play with the target bitrate, which will let you make "quality vs size" tradeoffs. I do this conversion using FFMpeg, but I'm an old "command line" guy - that application may not be for everybody. I believe VirtualDub (excellent package) will also do this for you.
Trick #6 - Sometimes the animation involves, um, "repetitive motion." LOL Just to keep things G-rated (why? why not. LOL) let's suppose I have an animation in which I raise my arm over my head and then lower it again. Depending on the effect you want to achieve, you might be able to just render the "raise my arm" sequence, and then create the "lower it again" sequence by using the same images in reverse. Takes a little extra work doing the conversion between image series and movie, but could potentially cut your render time in half. Another reason to render to image series. (I've been known to render one pass 123456 but then construct videos that go 1232123454321234565432, if you follow what I mean...)
Trick #7 - when trying to evaluate whether your movie loops cleanly, you typically want to create a movie that has your image series repeated several times so you get a good look at the last-frame-to-first-frame transition. When you generate your final movie, you might only need one copy of everything - Ren'py, for example, usually does a really clean job of looping.
Trick #8 - when you set up your animation in DS, you'll typically want to make the very final frame identical to the first frame so that things will loop cleanly. If you do that, however, you don't really need to render that last frame, and definitely don't want to include it when you build the video, as that will inject a tiny delay at the loop point.
That's what comes to mind at present.
