Rendering & Exporting Video

A video is an illusion built from still frames shown fast enough that the eye reads continuous motion, and frame rate - measured in frames per second (fps) - is how many stills make up each second. This is the first decision because it sets how many frames the engine has to render, which drives everything downstream.

For architectural walkthroughs the practical range is narrow. 24 fps is the traditional cinema frame rate and gives a slightly filmic, cinematic feel; it is a perfectly good choice for a polished archviz film and renders fewer frames than higher rates. 30 fps is the common standard for online and broadcast video, reads as smooth and clean, and is a safe default. 60 fps is very smooth and is used for fast games and sports, but for a slow, contemplative architectural move it is usually unnecessary - and it doubles the frame count versus 30 fps, so it doubles the render time for the same clip. Because your walkthroughs should be slow and eased, 24 or 30 fps is almost always the right call; higher rates buy smoothness you do not need at a cost you do not want to pay.

The key insight is that frame rate multiplies your render bill directly. Total frames = clip length in seconds x frame rate. A forty-second film at 30 fps is 1,200 frames; at 60 fps it is 2,400. Choose the lowest frame rate that looks right for the piece, decide it before you render, and keep it consistent across every shot so the whole film cuts together smoothly.

Resolution is the pixel dimensions of each frame, and after frame rate it is the biggest driver of render time - because it sets how much work the engine does on every one of those frames. The two you will use most are 1080p (Full HD, 1920 x 1080, about 2.1 megapixels) and 4K (UHD, 3840 x 2160, about 8.3 megapixels). The crucial thing to notice is that 4K is not twice 1080p - it is four times the pixels, because you double both width and height. That means, very roughly, four times the render time and four times the file size for the same clip and frame rate.

So resolution is a genuine cost-benefit decision, not a 'more is better' slider. 1080p is the workhorse of architectural animation: it looks crisp on laptops, phones, tablets, in presentations and on most social platforms, and it renders and uploads far faster. 4K is worth it when the film will play on a large high-resolution screen, a projector or a big display where the extra detail is actually visible, or when a client specifically requires it. For the vast majority of walkthroughs - shown in a meeting, sent as a link, posted online - 1080p is the right choice, and paying the 4x render cost for 4K buys detail nobody will see.

A useful discipline is to render test frames at the final resolution early. Render a single frame at your intended 1080p or 4K, look at it hard for noise, aliasing and quality, and time how long it took - then you know exactly what the full sequence will cost before you start. Deciding resolution and frame rate together, up front, is how you avoid discovering three days into a render that you picked settings you did not need.

Once frames are rendered they have to be stored and played, and this is where codecs and formats come in - and where a simple two-stage habit saves a lot of grief. A container format like MP4 or MOV holds the video; a codec like H.264 or H.265 (HEVC) is the compression scheme inside it that shrinks the enormous raw data to a shareable size. H.264 in an MP4 is the universal delivery format - it plays on essentially every phone, browser, laptop and TV on earth, which is exactly what you want for a file you send a client. H.265 compresses better (smaller files at the same quality) and is ideal for 4K, but is slightly less universally supported, so H.264 remains the safe default for maximum compatibility.

The professional habit, though, is to separate mastering from delivering. Rather than have the engine encode straight to a compressed MP4, render your animation as an image sequence - a numbered folder of individual frames (PNG or a high-quality format), one file per frame. This is your master, and it has two big advantages. First, it is a safety net: if the render crashes or your machine dies at frame 700 of 900, you keep all 700 finished frames and simply resume, instead of losing an entire encoded video. Second, it is lossless and future-proof - you can re-encode it to any format later, grade it, or drop it into an editor without re-rendering. You then encode that image sequence to a compressed H.264 MP4 for delivery, either in the engine, in an editor, or with a free tool.

So the rule of thumb is: master to an image sequence, deliver an H.264 MP4. For most single-shot walkthroughs you can let the engine export an MP4 directly and be fine - but the moment a render is long, expensive or important, the image-sequence master is cheap insurance you will be glad you bought.

The last and most practical step is to treat the export as a budgeting problem, because animation render time is where projects quietly blow up. The formula is blunt: total render time = number of frames x time per frame. Real-time engines like Lumion, D5, Twinmotion and Enscape render each frame in seconds, so a 900-frame clip might export in tens of minutes to a couple of hours - one of the strongest reasons archviz has moved to real-time for motion work. Offline engines like V-Ray and Corona can take minutes per frame, which turns the same 900 frames into days, the domain of overnight runs and render farms. Either way, the discipline is the same: render one frame first, time it, multiply by your frame count, and you know the real cost before you commit - so you can adjust resolution, frame rate, length or quality while it is still cheap to do so.

A few practical habits keep exports safe. Render the animation while you are not using the machine for anything heavy, since it will consume the GPU. Keep effects that are expensive per frame - heavy depth of field, dense reflections, thick atmosphere - in mind, because they multiply across every frame, not just one. And whenever a render is long or important, prefer the image-sequence master so a crash costs you minutes, not the whole job.

Finally, match the delivery to where the film will actually play. A client review link, a social post, a big-screen presentation and a website hero each have different ideal resolutions, aspect ratios and file sizes. A reasonable H.264 MP4 at 1080p with a sensible bitrate plays smoothly almost everywhere and keeps file size manageable; push bitrate and resolution up only when the destination genuinely benefits. Thinking about delivery before you render - not after - means you export once, at the right settings, instead of re-rendering because the file was the wrong shape or too big to send.