Game Development Reference
In-Depth Information
The first pass is for all the user interface elements that are displayed directly on the screen,
butthatmaybeaffectedbythegame'spostprocessingeffects.Inthispasswewouldrender
any user interface elements that we want to be in the frame buffer at the time the post pro-
cessing system applies the effects. When would we want to do this? In many games the
HUD is part of the game's immersion, it's a part of the player somehow, as a helmet's in-
teriororacyberneticeye,somepostprocesseffectsmayimpairvisibilityorcreateaneffect
when the player takes damage; it's important to understand your game's rendering goals
and how post processes are used to make sure this pass is done at the right moment.
The next pass is for anything that should NOT be affected by the post processing effects,
this could very well be the HUD if the game's design calls for the HUD to be “always on
top” or it can be used to display menus when the game is paused, anything that requires
direct player interaction should not be affected by post processes, after all the player needs
to be able to read and interact with the UI.
There is another pass, this one is interleaved with the game rendering pass as it is usually
dependent on some game mechanic, a camera for example. This is a pass in which we may
render any sort of interface into a render target, and then use this render target to display
the interface “in-world”. This is a special case, and not every game requires it. The reason
why this should be considered a separate pass is that by coupling the rendering of the UI
witharelated worldobject,weensurethatwecanrendertheUItoarendertarget,thenuse
this render target directly within the object that owns it. This can be used to render the UI
for game objects, keypads, computer displays, basically anything you can imagine with a
UI that exists as part of the game's universe.
