O'Reilly logo

GPU PRO 3 by Wolfgang Engel

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

4
V
Designing a Data-Driven Renderer
Donald Revie
4.1 Introduction
Since the advent of hardware acceleration, rendering 3D graphics has been almost
entirely achieved through the use of a handful of APIs. It is thus accepted
that almost all engines that feature real-time 3D visuals will make use of one or
more of these. In fact, as computing complexity and power increase, it becomes
inconceivable that a single development studio could create proprietary code to
access the abilities of hardware or implement all the newest techniques in fields
such as physics and AI. Thus, engine development focuses more and more on
integrating functionality exposed by APIs, be that hardware, OS features, or
middleware solutions [Bell 10].
Each API is built using its own model and paradigms best suited to a specific
problem domain, expressing in higher-level terms the structures and concepts of
that domain. Graphics APIs are no different in this respect, typically expos-
ing the hardware as a virtual device that must send relatively large amounts of
information to the hardware when rendering each frame.
The engine itself can also be thought of as an interface, exposing a superset of
the functionality found in all its components in a consistent manner. This inter-
face forms the environment within which the core logic of the game or simulation
is implemented. Thus, the engine must adapt the concepts and functionality of
its constituent APIs to its own internal model, making them available to the
game logic.
This chapter explores designing a renderer to bridge the gap between the
logical simulation at the core of most game engines and the strictly ordered
stream of commands required to render a frame through a graphics API. While
this is a problem solved by any program used to visualize a simulated scene, the
solution presented here focuses on providing a flexible data-driven foundation on
which to build a rendering pipeline, making minimal assumptions about the exact
rendering style used.
291
292 V 3D Engine Design
The aim is to provide a solution that will decouple the design of the renderer
from the engine architecture. Such a solution will allow the rendering technology
on individual projects to evolve over their lifetime and make it possible to evaluate
or develop new techniques with minimal impact on the code base or asset pipeline.
4.2 Problem Analysis
So far we have defined our goal as exposing the functionality of a graphics API in a
way consistent with our engine, placing emphasis on flexibility of rendering style.
As a top-level objective this is sufficient but provides very little information from
which to derive a solution. As already stated, every API is designed to its own
model requiring its own patterns of use coinciding to a greater or lesser extent with
that of the engine. To determine this extent and thus the task of any renderer
module, both the API and the intended engine interface must be explored in
detail. Discussion of these matters will be kept at a design or conceptual level,
focusing on the broader patterns being observed rather than on the specifics of
implementation in code. In this way the problem domain can be described in a
concise manner and the solution can be applicable to the widest possible range of
graphics API and engine, regardless of language or other implementation details.
4.2.1 Graphics API Model
Most graphics APIs belong to one of two groups, those based on the OpenGL
standards [Shreiner et al. 06] and those belonging to Microsoft’s Direct3D family
of libraries [Microsoft 09]. At an implementation level, these two groups are
structured very differently: OpenGL is built on the procedural model informed by
its roots in the C language, and Direct3D has an object-oriented structure using
the COM (Component Object Model) programming model. Despite this, the
underlying structure and patterns of use are common to both groups [Sterna 10]
(and most likely all other APIs as well). Above this implementation level we can
work with the structures and patterns common to all graphics APIs and define a
single model applicable to all.
No doubt many of these concepts will be very familiar to most graphics pro-
grammers, however in programming how a thing is thought about is often more
important than what that thing is. Therefore, this section is intended to achieve
a consensus of view that will form the foundation for the rest of the chapter. For
instance, this section is not concerned with what the graphics API does, only the
patterns of interaction between it and the application.
Graphics device. The graphics API is designed to wrap the functionality of hard-
ware that is distant from the main system architecture, be it an expansion card
with self-contained processor and memory or a completely separate computer ac-
cessed via a network connection; communication between the main system and

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required