Another Case for Baking

[doctorpangloss]

Based on your objective of maximizing performance, baking a scene to textures would seem to be among the top priorities.

The number of scenes that would benefit from baking is immense. Many architectural animations have camera moves where the lighting doesn't change. Currently, to render such scenes in an adequate amount of time, we use direct lighting anyway. So physical accuracy too great an issue. But certainly, we could better achieve physical accuracy with a baked pathtracing pass and raytraced/rasterized reflection, refraction and gloss than direct lighting alone.

Let's analyze the performance benefit of this scene to understand why Refractive may have passed on this feature. Suppose 1/3 of the scene is diffuse materials, 1/3 is glossy and 1/3 is specular--an odd arrangement, but later to be shown not very important. One frame takes k seconds to render to convergence at a generous 16 bounces of pathtracing at HD resolutions on this hardware. Lighting does not change.

In its crudest form, baking essentially saves us computing all the bounces on diffuse materials, 1 of the bounces on glossy materials and no bounces on specular materials. It does so at a possibly great cost of precious video card memory, which we will investigate later.

First though, a rough time analysis. We have two procedures: baking versus not-baking. With one frame of rendering, baking takes no additional time compared to not baking.

Let's figure out how long it takes to render a scene with baked textures. All of the diffuse materials have already been computed, so we can subtract 1/3 k seconds from our time. Only one bounce of 16 of the glossy materials has been computed, so we can subtract 1/3 * (1/16) k additional seconds from our time. None of the bounces of the specular material can be baked, so we subtract no additional time.

With two frames of rendering, baking renders to convergence the next frame at (1k - 1/3 * 16/16k - 1/3 * 1/16k - 1/3 * 0k) = 0.645k seconds, the first baked frame took to render. Let's call the time to render this next frame S, for savings. Your total time is 1.654k seconds.

For N frames, the time to render the animation is (1 + N * 0.645)k seconds--essentially, S*k.

It turns out our savings is dominated by the proportion of diffuse materials in our scene. Suppose we called the proportion of our scene composed of diffuse textures D, for diffuse. S converges to 1 - D, because we basically achieve no savings for glossy or specular textures.

So here's the simple comparison. In a scene where the lighting does not change but the camera moves:

Without baking: N * k seconds.
With baking: (1 - D) * N * k seconds.

The primary factor is D, the proportion of diffuse materials.

Certainly Otoy would kill for a 5% performance increase. Many of you pay very dearly for faster graphics cards, at minimum. Your performance increase is directly proportional to the amount of diffuse textures in your scene. If even 5% of the scene is diffuse materials, this optimization has achieved a "significant" performance increase.

There are some caveats, of course. With respect to time, the major caveat is the amount of a given material is actually visible in the frame (i.e., reachable by an "eye ray") at a given moment of time. In many architectural scenes, I would argue that walls (diffuse materials) make up the majority of the pixels in a given frame, so that empirically the figure is close to 50% of a frame is diffuse. But even if we modestly say 1/3 or even 1/10 of the frame is diffuse, the performance gain still converges to the proportion of diffuse materials versus all the materials in the scene.

With respect to memory, storing all these textures is expensive. It is at least D * memory usage more space-expensive to store the baked textures. This is the greatest caveat.

Of course, this is all assuming we would be naive enough to use the baked textures in Octane's pathtracing engine. Again, we have to use direct lighting anyway for noise-free animations. An advanced raster engine like FurryBall can simulate glossy and specular reflections in a fraction of the time of a raytracer, without any hand-optimization by the user. Internal specular reflections can't be simulated, but I feel like diamonds aren't a common (or frame-encompassing) feature of architectural scenes. In short, given the speed of a typical raytracer or rasterizer--mental ray and Maya's Viewport 2.0, as trivial examples--you can achieve something between direct lighting and path tracing quality at less computation time than direct lighting.

A huge fraction of the time, to be specific. With Maya Viewport 2.0, rendering a frame is instantaneous. Hence, your performance advantage isn't just D. It's N * D--the longer the animation, the signiticantly greater the performance benefit relative even to direct lighting.

This is ignoring all of the benefits to workflows baking to textures enable. This is also ignoring all the other kinds of scenes that benefit from baked textures--like fiction animation scenes, where photorealism is less important.

Judging from Otoy's focus on instancing, it would seem that memory is the number one issue. Supposing that the texture baking implementation couldn't work within memory constraints, and hence requires costly paging of memory into and out of the video card, the determining factor of baking becomes the number of additional frames to render. For an architectural scene, I would guess that it's worth it. For a fiction animation, it almost always is. But I don't think texture baking has to work that poorly.

Please implement texture baking. If it existed today, a render of mine that should take only 1 hour with mental ray takes 44 with Octane, with none of the benefits of the noise-free walls and smooth animation. mental ray already ships with a unified progressive renderer (not iRay, but for its raytracing engine) that gives us the same real-time editing power of Octane with all of the optimizations afforded by modern raytracers (like baking).

The fact that I have to manually cluster Octane renders is annoying too--talk about easy performance increases. But that is for a different post.