<p>When you offline-render an animation, you take all the 3D information and turn it into a video file: a sequence of 2D images. The video file doesn't have any of the 3D information. A 3D game doesn't work this way because when you run the game, the 3D information needs to be present.</p>

<p>It's quite common to use 3D models for making 2D games. Donkey Kong was a very early example of this: all the characters and backgrounds were modelled and animated in 3D, then rendered to 2D animations. These 2D animations were then used as sprites in the game. It allowed the sprites to look a lot more impressive than could be achieved with hand-made 2D sprites, using 3D ray-tracing techniques that weren't usable in real-time on the available hardware.</p>

<p>More recently than that, it was common for cutscenes in 3D games to be pre-rendered videos. Cutscenes don't need to be interactive like the rest of the game. Using a pre-rendered video means that the artists can use expensive, non-real-time techniques to make the cutscenes look better than the interactive parts of the game can look. This isn't so popular nowadays: video files are big, and real-time rendering is a lot better than it used to be, so doing the cutscenes in real-time gives you lighting and shading that's almost as good, without having a fixed-resolution video file with compression artefacts.</p>

<p>That said, there are some graphics techniques that use an offline pre-processing step to allow you to use techniques that wouldn't be possible in real-time (on the target hardware). The simplest example is texture compression: the compression is typically quite expensive, but it makes the textures use less memory, so you can have higher-quality textures.</p>

<p>If your scene has static lighting, it's common to <em>bake</em> lighting including global illumination and shadows into a texture, or into static light probes. This replaces the expensive lighting calculations with a simple texture look-up at run-time.</p>

<p>However, at the stage you're at, you shouldn't start worrying about any of these techniques yet. All of the rendering you'll be doing will be at run-time, so you need to optimize it to run at the target frame-rate on your target hardware.</p>

CC BY-SA 3.0
2017-03-21T11:10:39.660Z
2017-03-21T11:10:39.660Z
Dan Hulme
<p>I'm using Urho3D on Raspberry Pi, but the following questions apply to all platforms.</p>

<p>What should I do in order to reduce the load of online real-time rendering of the game? Does building/compiling/rendering the game (before running it) makes it easier and lighter to be run afterwards?</p>

<p>When making animations with 3dsmax, we use high-end computers to design the animation and render it. After that, any low-end and simple computer can play the animation. Now can we use a similar approach? Can I build/compile/render the game in a high-end machine and run the game in a low-end machine?</p>

<p>What is exactly the difference between building/compiling/rendering when designing a game, and running/real-time-rendering when playing the game?</p>

<p>Does a game needs rendering after designing? Or all the renderings are left to the playing time!?</p>

CC BY-SA 3.0
2017-03-18T19:03:15.077Z
You seem to keep using the words without any idea of what they mean. While "building" and "compiling" are often used synonymously, I have never seen "rendering" being used as a synonym for them. It's overall unclear what you're really asking about. Perhaps you should get some more programming experience that could better inform you as to what all of these terms mean.
Nicol Bolas
<rendering>
Fundamental Questions: Building vs Compiling vs Rendering vs Coding vs Running?
Omid1989
# Fundamental Questions: Building vs Compiling vs Rendering vs Coding vs Running?

(Asked by: username_0 on 2017-03-18)

I'm using Urho3D on Raspberry Pi, but the following questions apply to all platforms.

What should I do in order to reduce the load of online real-time rendering of the game? Does building/compiling/rendering the game (before running it) makes it easier and lighter to be run afterwards?

When making animations with 3dsmax, we use high-end computers to design the animation and render it. After that, any low-end and simple computer can play the animation. Now can we use a similar approach? Can I build/compile/render the game in a high-end machine and run the game in a low-end machine?

What is exactly the difference between building/compiling/rendering when designing a game, and running/real-time-rendering when playing the game?

Does a game needs rendering after designing? Or all the renderings are left to the playing time!?

**Tags:** rendering

> **Comments:**
> **username_1**: You seem to keep using the words without any idea of what they mean. While "building" and "compiling" are often used synonymously, I have never seen "rendering" being used as a synonym for them. It's overall unclear what you're really asking about. Perhaps you should get some more programming experience that could better inform you as to what all of these terms mean.  

---

## 1 answers

### Answer by username_2 on 2017-03-21. Score: 2

When you offline-render an animation, you take all the 3D information and turn it into a video file: a sequence of 2D images. The video file doesn't have any of the 3D information. A 3D game doesn't work this way because when you run the game, the 3D information needs to be present.

It's quite common to use 3D models for making 2D games. Donkey Kong was a very early example of this: all the characters and backgrounds were modelled and animated in 3D, then rendered to 2D animations. These 2D animations were then used as sprites in the game. It allowed the sprites to look a lot more impressive than could be achieved with hand-made 2D sprites, using 3D ray-tracing techniques that weren't usable in real-time on the available hardware.

More recently than that, it was common for cutscenes in 3D games to be pre-rendered videos. Cutscenes don't need to be interactive like the rest of the game. Using a pre-rendered video means that the artists can use expensive, non-real-time techniques to make the cutscenes look better than the interactive parts of the game can look. This isn't so popular nowadays: video files are big, and real-time rendering is a lot better than it used to be, so doing the cutscenes in real-time gives you lighting and shading that's almost as good, without having a fixed-resolution video file with compression artefacts.

That said, there are some graphics techniques that use an offline pre-processing step to allow you to use techniques that wouldn't be possible in real-time (on the target hardware). The simplest example is texture compression: the compression is typically quite expensive, but it makes the textures use less memory, so you can have higher-quality textures.

If your scene has static lighting, it's common to *bake* lighting including global illumination and shadows into a texture, or into static light probes. This replaces the expensive lighting calculations with a simple texture look-up at run-time.

However, at the stage you're at, you shouldn't start worrying about any of these techniques yet. All of the rendering you'll be doing will be at run-time, so you need to optimize it to run at the target frame-rate on your target hardware.


---

