3D Graphics

Realtime 3D graphics 1
Realtime 3D graphics
- Overview
- The goal
- The problem
- Primitives
- Solution
- Algorithms
- Complexity
- Cons and pros
- Conclusion

Overview
• The whole idea of 3D graphics arose in
90’s when the hardware began to become
strong enough to render realistic 3D
images on a 2d screen retaining
acceptable FPS to create smooth
animation. First application that comes to
mind is Wolfenstein 3D, which became a
real masterpiece and starting point in 3D
game industry.

The goal
• The goal
The goal of any graphics engine (3D
graphics engine in this context) is to
simulate real world on a 2D screen, creating
feeling of reality and presence in a given
world.
Two affecting factors are speed(FPS) and
image quality.

The problem
• So, to the bottom of line, the main goal is
to render a realistic image in as high
quality as possible in as less time as
possible. When speaking of “realtime” we
assume not less than 10 FPS with
acceptable image quality (for comparison
movie is 24 FPS)

The problem
• 3d world can be defined as a huge number of
polygons (n), but we can never really see all
these polygons,
since :
- Closer polygons may cover farther ones,
making them invisible
- About half of them are not facing towards the
point of view (POV) and thus don’t need to be
rendered.

The problem
- About ¾ of the polygons can’t be seen
because they are not in our Field Of View (FOV,
90 degrees)
• - The polygons are too far from the POV and
may be omitted
• - Other minor factors that won’t be discussed

The problem
• These factors reduce to the main problem
in 3D graphics : How do we know what’s
visible and what’s not ???
In our language:
Visible Surface Determination (VSD)

Primitives
Before sliding to the solution of the VSD problem
let’s define some primitives used in a 3D scene
Any 3D world is rendered on a 2D screen as a final
set of primitives like polygons, pixels and such,
no matter how complex it is.
In this presentation we’ll discuss a 3D scene
rendered as a final set of convex flat polygons, or
triangles, to simplify the implementation

Primitives
- Pixel – Picture element
Single point on a screen. Usually defined as a
combination of Red Green and Blue components to
define any color

Primitives
- Plane
Imaginary flat surface, defined as ‘Normal’
and translation along this normal from
(0,0,0) of the 3D axis system.

Primitives
- Polygon (triangle)
Convex closed polygon lying on a single
plane. Defined as a set of vertices in
clockwise direction, which makes the
rendering simpler and faster.

Primitives
• Clipping frustum
Clipping pyramid defined by set of planes
used to eliminate invisible surfaces that
are not in our field of view (FOV)
Visible
Invisible
Invisible

Solution
• To solve the VSD problem and render only
what we want retaining acceptable,
realtime FPS we’ll discuss 4 algorithms:
- Painter’s algorithm
- BSP (Binary Space Partitioning)
- Portal rendering
- All the above together

Painter’s algorithm
• Brute force approach
Since some polygons may cover the other
ones we want to render them from farthest
to closest.
To achieve the order we’ll have to sort
them by distance from the observer (POV)
to each polygon

• Complexity
The complexity of this algorithm is defined
by sorting algorithm and is O(nlogn)

• Pros
- Very simple
- Takes little memory
- Retains the world dynamic, polygons can
be moved, modified at runtime

• Cons
- Becomes too slow for large (n)
- Very big overdraw for large (n)
- Doesn’t solve the problem of overlapping
and intersecting surfaces

Binary Space Partitioning
• Algorithm based on Divide & Conquer
technique which divides the world into 2
halves, then each of these halves into
their 2 halves and so on until no polygons
are left to divide in a given half
(subspace), thus creating a binary tree in
which left subspace lies on one side of the
splitting plane and the right subspace
space on the opposite side.

A
B
C
D
C
A
BD
E E

CalculateBSP(SubSpace)
{
DivPolygon = Polygons[0]
for each Polygon p in SubSpace except DivPolygon
{
if p is on one side of DivPolygon’s plane
add p to the Left Subspace
if p is on the other side of DivPolygon’s plane
add p to the Right Subspace
if p intersects DivPolygon’s plane
{
split p by DevPolygon’s plane into 2 new polygons p1,p2
add p1 and p2 to Left and Right Subspaces respectively
}
}
If Left Subspace is not empty
CalculateBSP (Left Subspace)
If Right Subspace is not empty
CalculateBSP (Right Subspace)
}

• Complexity of BSP tree calculation
Assuming none of the dividing polygons
intersects any other polygons the
complexity is a regular D&C : O(nlogn)

• Walking the tree
Once we have the BSP tree calculated,
traversing it (rendering) takes linear time.
Depending which side of a given node(polygon)
our POV is we know which subspace to
draw first. If the POV is on one side of the polygon
then draw the other side’s subspace first, then the
polygon itself, and then the opposite side’s
subspace

RenderBSP(Node, FOV)
{
if FOV is on the left side of Node
{
if Node has RightNode
RenderBSP(Node.RightNode, FOV)
}
Render Node
if FOV is on the right side of Node
{
if Node has LeftNode
RenderBSP(Node.LeftNode, FOV)
}
}

A
B
C
D
E
C
A
BD
E
FOV

• Complexity
Traversing BSP takes linear time,
retaining perfect order (front-to-back or
back-to-front) with complexity of O(n)

• Pros
- Simple
- Perfect order with linear complexity
- Solves the problem of overlapping and intersecting
polygons by definition

• Cons
- Requires precalculation time which may take long depending on (n)
- Required more memory since many polygons are usually split (n grows)
- World becomes static, since every modification destroys the
consistency of the tree
- Although the sorting problem has been solved, every single polygon
must be visited during the rendering, so the overdraw is still there (next
algorithm)

Portal rendering
• This algorithm is best suitable and most
efficient in indoor environments in which the
world consists of 3D convex hulls (sectors,
rooms for instance) connected with each
other by portals (doors). The most intuitive
way to think about it is as Graph, in which
nodes are sectors(rooms) and links are
portals(doors)

Portal rendering
Sector 1
Sector 2
Sector 3
Sector 4
Portal from
1 to 2
Portal from
2 to 4
Portal from
2 to 3
Sector 5 Portal from
2 to 5

Portal rendering
• The algorithm doesn’t require
precalculation like BSP but requires the
world to be build in certain way (sectors
and portals).
Once this is done rendering becomes
trivial.

Portal rendering
RenderPortals(Sector, FOV)
{
for each polygon p in Sector
{
if p is inside FOV)
render p
}
for each portal P in Sector
{
if P is inside FOV
{
create new clipping frustum F from P
RenderPortals(the sector P is connected to, F)
}
}
}

Portal rendering

Portal rendering
• Complexity
The polygons don’t have to be sorted in
any way and/or visited more than once.
In worst case we’ll have to render
maximum (n) polygons, so the complexity
of this algorithm is linear, O(n)

Portal rendering
• Pros
- Simple
- Zero overdraw. Only draw polygons that we can see
- Order isn’t an issue
- The world doesn’t have to be static, as long as the sectors
remain convex

Portal rendering
• Cons
- Requires the world to be defined in certain way
- Although achieves zero overdraw it becomes too slow
in highly details environment due to too many clipping
operations

What now ?
• Ok, we learnt 3 nice algorithms so far.
Each one of them has its’ pros & cons, but
how can we use them to build a real
realtime 3D engine ?

Putting it all together
• Real world can be looked at as a set of
static objects (buildings) and dynamic
objects (people, animals, cars, whatever).
• So, looking back at the 3 algorithms we
can see that BSP and Portals are suitable
for static, and Painter’s algorithm for
dynamic objects.

• We can use:
- Portal rendering for objects like rooms, since
they’re relatively simple.
- BSP for complex but yet static objects in every
room. We’ll create one BSP tree for each sector.
- Painter’s algorithm for drawing dynamic objects
like humans.

RenderPortals(Sector, FOV)
{
for each polygon p in Sector
{
if p is inside FOV)
render p
}
for each portal P in Sector
{
if P is inside FOV
{
create new clipping frustum F from P
RenderPortals(the sector P is connected to, F)
}
}
RenderBSP(Sector’s BSP, FOV)
RenderDynamic(Sector’s Dynamic objects)
}

BSP
BSP
BSP
Portals
Painter’s

• Complexity
The complexity of this algorithm is combined of the 3
former algorithms’ complexities :
O(nlogn) for Painters algorithm +
O(n) for BSP +
O(n) for Portals = O(nlogn)

Conclusion
• Although the complexity remains the same
O(nlogn), large portions of the world with their
BSP trees and dynamic objects (Painter’s) are
discarded by Portal rendering. What’s left is to
render BSP trees and dynamic objects in the
visible sectors.
Although we lose zero overdraw but we win in
not drawing certainly invisible objects.

Conclusion
No matter how big the world is, we’ll still only
draw what’s potentially visible.
In average, this actually makes the
potentially visible set of polygons constant
(c)
So our real average complexity becomes
O(c). Best complexity you can dream of 

Afterword
• (c) is generally defined by today’s
hardware. The faster the hardware, the
more polygons we can draw in one frame
remaining Realtime
• (n) is defined by memory limitations. The
more memory we have, the larger and
more complex world we can load into it

3D Graphics

More Related Content

What's hot (19)

Viewers also liked (14)

Similar to 3D Graphics (20)

3D Graphics