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 deﬁned our goal as exposing the functionality of a graphics API in a
way consistent with our engine, placing emphasis on ﬂexibility of rendering style.
As a top-level objective this is suﬃcient 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 speciﬁcs 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 diﬀerently: 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 deﬁne 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