Elements of Game Engine Rendering

Purpose of this document

This is a document that outlines the pros and cons of whether to use software clipping, LODs on polygonal terrain, or Dynamically Tessellating Terrain using Bezier NURB Patches for any given level on a project.  In addition, a general list has been created that affects the balancing of three elements in game asset allocation: frame rate, memory, and overall CPU usage.

Questions and Answers to define the issues


What is the CPU?

CPU stands for Central Processing Unit and is often, simply called, the processor. The CPU is a microchip that is installed on a motherboard and acts as the computer’s brain by performing calculations and coordinating the hardware components.

What is a GPU?

GPU stands for Graphics Processing Unit and is a special processor dedicated to calculating the graphics in a game. A GPU allows for better looking console games and takes the load off of the CPU during game play. Think of it as a video card in a PC, but for consoles.

What is the guard band, and how does it work?

The guard band is a buffer of renderable area off screen at a fixed size that is built into the hardware. It prevents larger polygons that are partially off screen from disappearing, which would result in holes appearing in a 3D environment along the edges of the screen.


It does this by extending the renderable area outside the viewable screen.  Thus, a larger polygon that is only showing a portion of itself on screen will not drop out as long as the rest of the polygon does not extend past that extra renderable buffer.




(Notice that the diagram shows the viewable area in blue.  The purple polygons that are partially on screen will not disappear while in the viewable area, because the entire polygon falls within the edge of the guard band, while the orange polygon will disappear while in the viewable area, because the entire polygon does not fall inside the edge of the guard band.)

What is hardware clipping and software clipping, and how do they differ?

Hardware clipping is functionally the same as software clipping, in that they both clip off the parts of triangles that extend past the edge of the guard band.  Hardware clipping is the GPU doing the work for you, while software clipping is you having to do it manually on the CPU before giving the (clipped) geometry to the GPU.

Since the software clipping uses CPU rather then GPU, it is a much larger hit on performance than hardware clipping, possibly resulting in lower frame rate, and allowing less room for things like additional characters on screen, effects and environmental props.


Note: (above) the blue line indicates where the software clipper dissects the polygons along the edge of the guard band, as depicted in the green polygon, adding edges to the scene in perspective view.  The yellow dots represent the added verts, from where the blue line intersects the pre-existing poly edges. The orange corner of the green polygon gets dropped.  Within 3D world space from a top down, orthographic view, the added intersection would look like this.  (See picture below)


What are clip planes?

Near and far clipping planes are imaginary planes located at two particular distances from the camera along the camera's sight line. Only objects between a camera's two clipping planes are rendered in that camera's view. Any parts of objects in the scene closer to the camera than the near clipping plane, or farther from the camera than the far clipping plain are not rendered.

If part of an object is in front of the near clipping plane, then only the part of the object beyond the near clipping plane is rendered. Polygons that touch the far clip plane get dropped, but since they are far away, it is aesthetically of no consequence.

How do the previously explained phenomena tie together in one issue?

Hardware clipping is desirable, because it is a reliable method in preventing large polygons in the foreground from dropping out on screen, without a high cost to processing, since hardware clipping is handled separately by the GPU (or video card on the PC) rather then the CPU.  Currently, all Sony products do not support hardware clipping, because the processor chips are cheaper to manufacture, resulting in large polygons dropping off screen, in the foreground within the viewable screen area.

Sony’s stand on this is that they see no reason to cut into their bottom line or drive up the unit cost to the consumer and possibly losing market share, just to make it easier for game developers, when there are other solutions at the game developer’s disposal to alleviate the problem.

However, all Sony consoles do have a guard band built into their hardware and unlike pervious Sony products, the PSP supports near clip planes as well.  Near clip planes address two things.  It prevents visual phenomena, where things that are against or behind the camera lens severely distort the perspective.  It does this by clipping out the scene at a set distance from the camera lens at the programmer’s discretion.  The near clip plane’s default distance for the PSP is of a meter.

The second thing the near clip plane can do is clip out foreground polygons from the screen’s view before they have a chance to disappear and create a hole in the terrain on screen (AKA poly drop).  Moving the near clip plane out means that triangles cannot get as close to the camera before they are clipped off and therefore they do not get as large on the screen (due to perspective).  That in turn keeps them from touching the edge of the guard band and dropping out.  This lets us use bigger triangles.  If the near clip is two times farther away, polygons can be two times bigger without dropping out.

Something to keep in mind, if you are working with a first person camera scheme, your ability to adjust the near clip plane distance from the camera will be severely limited in comparison to a third person camera scheme, because a first person camera scheme requires that the first person model remain relatively close to the camera to maintain an orientation to the world that feels right and promotes good game play mechanics.  Specific elements that affect the way a player is oriented to the world are:

        Field of view (fov) - this affects the degree of fore-shortening of objects in the scene and the amount of peripheral vision, a first person view should have a fairly wide fov, this gives the player good peripheral vision to see attacks coming form the sides and it also makes environments feel more spacious.  A standard fov for a first person camera scheme is about 70 degrees.

        Camera turn radius - the distance between the camera lens and the point that the camera orbits around, is determined by the distance of character model to the camera, the farther your character is from the camera the wider your camera turn radius is going to be.  The near clipping planes must reside some where between the camera lens and the character.

  • Character model position – How is the character is framed in relation to his environment and the interaction between the player’s character and the player’s set objective? 

        The position of the character to the near clip plane is also critically important. Usually the least problematic location for a third person camera scheme is to have the character just ahead of the near clip plane to minimize the possibility of environmental objects blocking the player’s view of their character.  On the other hand giving the player’s character too much lead in front of the camera with the near clip plane so close behind the character may cause foreground objects to clip out to early, so programming the camera to move in closer on the near clip plane and the character in tighter quarters should solve this.  In a first person camera scheme, the orientation of the character model’s shoulders always remain flush in a fixed position to the near clipping plane, thus the character’s pivot, the near clipping plane, and the camera’s orbit, occupy the same 3D space.

Software clipping, which is a game engine feature, gives you the flexibility to render large polygons reliably in the foreground, without fear of the dreaded “poly drop”.  However, do to the fact that the software clipping method of subdividing polygons along the edge of the guard band, and the fact that it utilizes the CPU rather then the GPU, puts a 25% hit, overall on performance.  This could possibly result in a slower frame rate if you are close to your limit in CPU usage or rendering.

Another trade off with rendering time unique to Sony consoles is that rather then ceasing to scan parts of polygons that are off screen the GPU continues to finish scanning the whole polygon within the entire guard band.  The larger the polygon the longer it takes to scan in the image.  In this regard smaller polygons are an advantage because smaller polygons move off the screen in their entirety faster, and once they are completely off the screen, the GPU stops drawing it.  This results in less surface area of the guard band being scanned.  But with software clipping on, the CPU is running a check on each polygon on a per object basis to see if any polygons fall outside the guard band while still on screen, so the more polygons an object has, the longer it takes the CPU to determine if it needs to clip the object.  There is some good news in that the engine programmers can set a threshold based on the longest edge of a mesh to determine whether or not an object is eligible to skip this process.  However, as a whole if you are going to use software clipping you will need to keep your polygons big.  Just make sure that if you do tessellate a mesh to try to take advantage of skipping this checking process, and that you tessellate the whole thing as evenly a possible and don’t leave any edges longer in the mesh then the threshold number set by your team’s programmer. Otherwise, it won’t skip the process and the added polygons will slow down the rendering even more.  So for instance, if the engine’s threshold has been set at a 2 meter max edge length, and if a mesh has a hundred polygons, and ninety-nine of those polygons are 1 meter long, but one of them is 3 meters long, that mesh won’t be spared of the CPU running the check on every polygon of that object because of that one, 3 meter long polygon.

The 25% hit from the software render, however, may be offset by savings in much more sparsely tessellated assets without fear of poly drop, do to the software render, which allows artists to only add edges where they need to fill volume or better define an objects silhouette.

Another thing to keep in mind is ones reliance on a certain amount of tessellation to accommodate the level of definition of light and shadow that is desirable, whether it be dynamically lit or baked in lighting. Shadow maps or light maps can assist in making up for the courser lighting definition, but adding such things will cause second or even third rendering passes, furthering to close the gap in offset gains made from lessening the mesh density.  If you can, try to combine your layers of detail (such as base texture and ground shadows) into a single texture to increase efficiency.  To pull this off, you will need to plan your layers to work at the same UV scale.

If you don’t use software clipping, then in the areas where the player has close access, you will need to tessellate your terrain and any props that are significantly large in scale relative to the player’s character, for example, buildings, wall/barriers, large bombers planes, and so on.  Max size of the polygons depends on the minimum distance the camera will be from the objects in question.  In most situations and assuming you are using real world scale and your character is 2 meters tall, then a terrain with a polygon grid size of 2 meters should suffice.   Even if for instance, your character goes prone and the camera is half of one meter off the ground with the camera looking out, you are unlikely to see the polys drop out, do to the near clip plane.

Depending on how dense your world terrain gets, you may find that your frame rate will drop if there are either too many verts and or too many meshes showing on screen.  The number of verts showing on screen can be combated with LODs, and clever culling to help frame rate, but you will need to consider the amount of terrain you will need to break up, what size units to break the terrain up into, which will affect the amount of LOD groups, in which case, depending on the number of meters your level covers, may balloon your res file size for the level past your set budget if you are not careful.  This is largely because each LOD group node has a certain amount of overhead. (Approximately just over 1k) That doesn’t seem like much, however if you have a small res budget of 1000k.  And you have 350 LOD groups for your terrain, than half of your res budget is just in LOD group nodes.  Even though the actual additional geometry for the lower levels of detail may only add an additional 15% to your total vert count.  So if you can limit your number of LOD group nodes down to say 32 LOD groups for your terrain, or you have a much larger res file budget say 5000k, then using LODs becomes a viable option.

Dynamically Tessellating Terrain

Another game engine feature that one can consider is using a terrain tool that utilizes Non-Uniform Rational B-Spline or NURB in the form of Bezier patches, to change terrain geometry density in the engine in real time based on distance.

The terrain tool can create vast malleable geometry out of a series of parametric surface squares (Bezier Patches) that are quilted together.  The shape of a Bezier patch is controlled by 16 control points distributed uniformly over the surface.  The corner of each patch shares a control point with each adjacent patch.

The advantage of this tool is that it takes up a fraction of the memory of its polygonal counterpart.  The larger the distance of the terrain the greater the margin of savings you’ll make in memory.  Since the mesh changes density

based on distance, there is no need for LODs or subdividing of terrain, saving both time and resources.

There are limitations, to the tool.  For instance:

        You can not add additional edges to the patches to cut in features rather you will have to replace terrain with polygonal features and landmarks on a patch by patch basis.

        You must only manipulate the topography of the terrain patches by either translating or scaling the control points along the Z - axis.

        You can only use unitized or planar mapping on the Z - axis, so if you pull up terrain features that go too vertical, you will get noticeable UV stretching.

        Because of the nature that B-Splines behave, the terrain tool will not be able to create angular structures.  Instead, things like walls, buildings, mine shafts, reinforced trenches and so on, will have to be built over or into the terrain using polygons.  This will take careful planning on the part of the environment artist to maximize the use of the tool where they can, while making aesthetically smooth transitions in sowing the polygonal features in with the Bezier patch terrain.

        Because the terrain surface dynamically changes as the player traverses the terrain, the geometry will require light maps to define the terrains shading to maintain a consistent appearance, as oppose to burning in vertex color information.

In addition there is a possibility of a performance hit, but unlike Software Clipping, where the performance hit is consistent and steady, the performance hit is tied to the tessellation changing on the terrain.  The faster you travel across the terrain the faster it has to update.  If this occurs while there is a lot of other things going on in the scene it could affect frame rate.  If your stationary, then the terrain is cheap as …… well dirt.

(See game asset allocation list on next page)

Things that affect frame rate (rendering issues for entire scene)

         Number of verts on screen

         Number of objects on screen

         Percentage of screen space drawing multiple layers of geometry

         Objects with alpha

         Number of layers of alpha

         Number of rendering passes for layered textures  

         Number of characters on screen

         Number of effects on screen

         Number of shader assignments which effects object count


Things that affect res size (memory)

         Number of verts

         Number of textures

         Texture sizes

         Number of LOD nodes

         Complexity of lighting information

         Amount of wiring nodes

         Number of group nodes

         Scale of objects

         Number of effect nodes

         Number of bones


Things that affect CPU usage (calling functions and events for entire scene)

         Number of verts loaded in the level (but for the most part, only if software clipping is enabled)

         Number of objects loaded in the level

         Number of bones per character

         Number of effects going off at once

         Amount of wiring events being called at once

         Number of animation keys

         Number of dynamic lights



back to the top