Blender Internal rendering tips

Most guides right now focus on Cycles or occassionally Eevee. But a lot of you still use 2.79 and Blender Internal. Here's what I could tell you... (Suggestions welcome)

Render as an image sequence

It's of course convenient to render straight to MP4. But MP4 has this annoying quirk where the video will not play unless you render everything in one sitting. Look up what "moov atoms" are, if you want to know why that is exactly.

So in heavier scenes you may find that you can't exactly do that for one reason or another, for example if your computer crashes mid-way through. And you have to start the whole render all over again.

Image sequences don't have this problem—less convenient yes, but the very least it can provide is being able to continue where you left off. Having the Overwrite checkbox UNCHECKED is especially useful for this.

In terms of formats, here's what I recommend:

OpenEXR - best used if you ONLY plan on using Blender. I usually use DWAA or DWAB compression here, gives a good balance between file size and quality.
PNG - best used if you want to use the render with other apps. For fast renders, set compression to 0% though it will take up some disk space. But hey, at least not as big as uncompressed AVI.

This is especially applicable if you plan on post-processing your render with other apps, hey what's the difference anyway?

Use the command line to render

Because when rendering something, you might also want to reduce overhead from also rendering the UI.

You can use this in conjunction with rendering as an image sequence.

On Windows, write something like this in Notepad:

"C:\Program Files (x86)\Blender Foundation\blender.exe" YOUR_FILE.blend -b -a
pause

Replace "C:\Program Files (x86)\Blender Foundation\blender.exe" with wherever you find the Blender program at. It should be placed in a similarly named directory, I don't remember the details.

In any case save this text alongside your project file, and rename it to render.bat. (Ensure file extensions are shown on Windows Explorer settings) Double click this file, and do your other things.

Leave thread count at auto-detect

Or at least, when setting them at Fixed, that they match the number of cores your operating system sees.

These threads represent actual operating system threads, which should occupy one core of your processor each.

It's because Blender is smart enough to throw another tile to a thread once a thread is done with rendering another, so no thread goes to waste here. Any more threads than what your processor can handle, and the operating system has to juggle them, thereby increasing bookkeeping overhead—and you want that overhead to be as little as possible.

Adjust your tile size before rendering

Before you render the whole thing, go to the frame with the most complex stuff happening in there, and try to render it with different tile sizes, like:

16×16
32×32
64×64
128×128
256×256

And see which one is the fastest.

If you want something to calculate: look closely at the "Part 1-48" status while rendering. The "48" of course signifies how many tiles Blender ends up having to render.

The number of tiles you have there should be multiple times your thread count, but not too much.

At least 4–10× that amount, but too many (like, hundreds more). If there are too many, there will be more overhead from allocating said tiles than it is to render them.

But if the number of tiles to render are the same as the amount of threads, well what if one tile happens to render a part of the image with tons of reflections? Nothing else can render in the meantime, and will end up slowing things down. So you want to reduce the "slack" there.

Dynamically disable render layers you don't need

Your graphics card is not that important

Because Blender Internal, being a renderer from the literal 1990s, does not use your graphics card in any way, shape or form. It only runs on your CPU.

This is also why 2.79 can run favorably on even your potato crapbook, but not so for modern (2.80+) Blender. The only times it will use your GPU is to render the viewport, and for OpenCL if you have it enabled for the compositor.

So if you only plan on using 2.79, consider looking for the latest and greatest gen CPUs you or your parents can afford.

Disable anti-aliasing if you have motion blur enabled

Anti-aliasing (AA) essentially works by rendering parts of your scene multiple times, wiggling the camera a bit each time—smoothing across space.

Sampled motion blur works by rendering your entire scene multiple times, one for each time sample—smoothing across time.

But did you know that sampled motion blur, when AA is disabled, can give you both smoothing across space and time?

Apparently the motion blur algorithm also wiggles the camera a bit when calculating your motion blur, giving you pretty much the exact same effect as enabling AA, and improves with more samples.

It seems to give slightly better render times than with both AA and motion blur enabled, since it's not doing the smoothing twice.

You can of course try this yourself with a simple scene at low res: disable AA and enable motion blur and see how the scene smooths itself out anyway.