-1
$\begingroup$

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!?

$\endgroup$
  • 2
    $\begingroup$ 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. $\endgroup$ – Nicol Bolas Mar 18 '17 at 19:03
2
$\begingroup$

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.

$\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.