6
\$\begingroup\$

I have a rough idea: real-time is approximated with little or no global illumination. But how would you otherwise explain why offline rending takes so much longer? You hear things like "number of passes," et cetera...

Can you explain the difference in simple terms?

\$\endgroup\$
9
\$\begingroup\$

There is no inherit reason why offline rendering takes longer than real-time rendering.

It is just that when you render offline, the rendering process is usually much less performance-critical, so you have the option to use very expensive rendering techniques which would be too slow for real-time rendering. When you are free from the constraint that each frame must render in less than 20ms, you can use a lot more complex geometries with a lot more expensive rendering techniques.

Which techniques exactly are used for each scenario differs. Global illumination, for example, is often too slow for real-time rendering, but not always. When the geometry of the scene is simple enough, it can be pulled off in real-time. And while offline-rendering can use global illumination, it doesn't have to.

There are countless other rendering techniques which are more or less performant and give more or less beautiful results depending on the exact scene geometry. Depending on the circumstances, almost any rendering technique can be used both for real-time and offline rendering.

Raytracing, for example, is usually considered too slow for real-time rendering. But when you have a scene which only consists of perfect spheres, any polygon-based renderer would cry in despair while a raytracing engine can do this in real-time.

\$\endgroup\$
2
  • \$\begingroup\$ "But when you have a scene which only consists of perfect spheres, any polygon-based renderer would cry in despair while a raytracing engine can do this in real-time.` This is particularly accurate. Even a software based rasterizer will be faster. \$\endgroup\$ – concept3d Feb 11 '14 at 16:53
  • 2
    \$\begingroup\$ This answer is overall correct, although it does ignore the fact that real-time rendering often relies on fast approximations to speed up the rendering, whereas offline rendering will takes its time being completely accurate. Ambient occlusion is a good example of this. \$\endgroup\$ – jhocking Feb 11 '14 at 18:34
2
\$\begingroup\$

"Real-time rendering" is calculated at the instant you ask for your whatever solution to generate the images (different technologies are used to achieve this target). "Off-line" rendering is not necessarily the contrary of "real-time". The term is often used when speaking about configurators and especially web-configurators. Sometimes people also use the term "pre-calculated".

"Off-line rendering" is not submitted to the time constraint. Basically a scene is prepared and then a series of pictures is generated ("pre-calculated") and ultimately assembled into a sort of a video clip that then is viewed ("off line"). The choice of type of technology used ("real time rendering" or "ray-tracing") depends on secondary criteria (complexity and type of geometries and materials to be rendered). There are excellent software packages for both technologies out there.

Where "ray tracing" is often claimed to be "physically correct", "real-time rendering" uses various "tricks" to generate images that appear to your eye (and more importantly to your brain) like real, "photorealistic".

Thus said, the fact that you need calculating images in less than 20ms eliminates many solutions because of this time constraint. Two typical examples here are "immersive solutions" (like CAVE systems) or "web-configurators" high combinatory, impossible to pre-calculate. In both cases there is no way to predict the image required by the end-user. And pre-calculating all different possibilities would simply require too much time (often years, even at a speed of 20 ms per image).

\$\endgroup\$
0
\$\begingroup\$

Its just that when you view the animation, if your PC is powerfull enough to compute all the casts, shadows, textures, everything and etcetera, you are looking a live rendered view... but if you got some drops on the FrameRate, you shoud use the offline rendering which is the exact same of the other but, this will take the CPU to the limit because obviously it will try to render it as fast as it cans but obviously cant do it in real time, so this process will save each frame in a buffer (or a file) (like PRE-RENDER) when each frame has rendered completely, this way you can see everything rendered at full detail but when the process of rendering each frame has finnished...

\$\endgroup\$
1
  • \$\begingroup\$ I'm not familiar with any examples of "offline rendered" animations that are distributed to consumers in their source format to be rendered by the consumer's PC into a temporary buffer prior to viewing. Usually this kind of thing would be rendered on the producer's hardware and distributed as a video file the consumer can play directly. Can you provide any examples of 3D content that's commonly distributed to viewers in this "parbaked" fashion? \$\endgroup\$ – DMGregory Sep 28 '17 at 11:32
0
\$\begingroup\$

The key difference between realtime and offline rendering is how much of a time budget you have to render a frame.

A realtime rendering situation needs to get everything done in a fraction of a second so it can keep up with user input (if there is any (eg. Demoscene productions are real-time rendered but rarely interactive)). If 25fps is the minimum to be considered playable, then that gives you 40ms to get everything done. Input processing, simulation state updates, mixing audio, drawing the frame, and putting it on screen.

Offline rendering can take as long as you like per frame (limited only by your patience), as it doesn't need to keep up with any inputs. It just takes a file as input and produces a file as output. Big budget films can take the better part of a day to render a single frame.

The tight time constraints of realtime rendering pose similarly tight limits on the complexity of what can be rendered. What kind of complexity you decide to favour is up to you, but there will be a trade-off to make between complexity of rendering method vs the complexity of the scene's construction. You can spend just as much processing power on a hundred-million-polygon CAD model with simple shading as you do on a near-photorealistic game with only a hundred-thousand polygons on screen. Oh, and the bloke using the CAD software will probably be more forgiving if the framerate drops a bit than the one playing the game.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.