Software Occlusion Culling Update 2

This update consists of a couple of more rasterizer optimizations. The optimizations were implemented by Fabian Giensen and have been integrated into the sample. These 2 optimizations improve performance in terms of frame rate by ~13% and in terms of total cull time by ~ 27%.

Coarse Depth pretest :

After rasterizing the depth buffer, we create a coarse depth buffer. To create the coarse depth buffer we summarize each 8×8 block of depth values by determining the most distant Z coordinate (smallest z value in this case). Then, for each AABB, we loop over all 8×8 pixel blocks covered by the box. If the nearest Z value for the whole box is behind the farthest Z value of all the blocks covered by the box in the coarse/summary depth buffer, then we are sure that the box couldn’t possibly be visible. We mark such AABBs as occluded and avoid rasterizing and depth testing them. 

Binners store triangle data:

In the previous version during the triangle binning pass each bin stored the triangle Id for the triangles that belonged to the bin. However this caused an extra gather during the rasterization pass because the triangles had to be looked up by their ids and gathered. To avoid the extra gather in this update the triangle bins directly store the triangle data.


The performance for the Software Occlusion Culling sample was measured on a 2.3 GHz 4th gen Intel® Core™ processor (Haswell) system with 4 core / 8 threads and Intel® HD Graphics GT3CW. We set the rasterizer technique to SSE, the occluder size threshold to 1.5, the occludee size threshold to 0.01, and the number of depth test tasks to 20. We enabled frustum culling and multi-tasking and disabled vsync.  
The castle scene has 115 occluder models and 48700 occluder triangles. It has 27025 occludee models (occluders are treated as occludees) and ~1.9 million occludee triangles.

The time taken to rasterize the occluders to the depth buffer on the CPU was ~0.79 milliseconds, and the time taken to depth test the occludees was ~0.46 milliseconds. The total time spent on software occlusion culling was ~ 1.25 milliseconds.

No Optimizations

Multithreading +

Frustum Culling

Multithreading +

Frustum Culling +

Depth Test culling

Frame rate (fps) 25 60 190
Frame time (ms) 40 16.67 5.26
# of draw calls 23279 7360 1831

Read more >

Virtual Trackpad


When games specifically built for PCs are run on a Win 8 tablet without a physical mouse, the tablet’s small screen and finger’s large touch area makes it difficult to select the correct GUI element when they are placed close together. The goal of this sample is to demonstrate how to implement an on screen virtual track pad and use it to control small UI elements in a game in the absence of a physical mouse.

The sample uses a Windows message hook to intercept WM_POINTER messages in the message queue. If the users touches the screen inside the on screen track pad region, the sample generates appropriate WM_MOUSEMOVE, WM_LBUTTONDOWN / UP, WM_MBUTTONDOWN / UP and WM_RBUTTONDOWN / UP messages. Here is the screen shot of the sample.

As shows in figure above,

  • TP: represents the track pad region and can be used to move the mouse cursor.
  • LB: represents the left mouse button
  • MB: represents the middle mouse button
  • RB: represents the right mouse buttoon

Virtual Track pad usage model:

  • To move the mouse cursor: Touch inside the TP region of the on screen track pad and move your finger in the direction that you want the mouse cursor to move on the screen.
  • Left mouse button click : Single tap the on screen left mouse button
  • Middle mouse button click : Single tap the on screen middle mouse button
  • Right mouse button click : Single tap the on screen right mouse button

Left mouse button click + drag: The click + drag event can be used to move the slider or the camera in the scene.The conventional usage model for a click + drag is to hold the left mouse button down while moving the mouse cursor. This two finger usage model is difficult to use on a touch screen and so we provide an alternate usage model in addition to the conventional usage model. If the user holds down the on screen left mouse button down for a small duration of time (1000 clock cycles) then, even when he release his finger the message hook procedure simulates a WM_LBUTTONDOWN for the user. This is shown in the figure below where the LB region of the track pad is darker in color than the other regions. The user can now use the TP region of the track pad to move the mouse cursor and generate the click + drag event. When the click + drag event is completed the user will have to again single tap the left mouse button to simulate a WM_LBUTTONUP message.

Use the show track pad checkbox to enable / disable the display of the virtual track pad. When the track pad is disabled the sample disables processing “touch” events

Read more >