Culling the battlefield Data Oriented Design in practice

Http://publications.dice.se/attachments/CullingTheBattlefield.pdf

 

This article introduces how dice works with cull.

 

 

Scene data, battlefield often has more than 15000 objects. The new method is used to obtain the data:

• 360: 1.55 Ms
• I7: 1.0 ms
• PS3: 0.85 ms
• SPU: 0.63 (SPU is abnormal)

Use a simple grid for Division. AABB uses the bounding sphere to add the grid OBJ list and frustum culling it.

Grid is divided into several categories:

• Render dynamic
• Render static
• Phyx static
• Phyx dynamic

When you add or subtract OBJ

• Add prealloc data.
• Use swap and count -- to efficiently maintain data closeness.

Then, the data is easy to die, and the culling process is also very violent, directly a few for, wood tree structure operations.

There are many condition judgments in the culling function. This is very expensive, so we use the vmx or SSE code to optimize it. It is equivalent to the hardcore (this part is written down first and will be studied later ).

 

 

 

Project to screen space

This is great. It will take the AABB or bounding Sphere Project to screenspace. If the area is small enough, Skip will be directly used. I never thought about it before, nice!

This avoids the generation of subpixel.

 

 

Software occlusion

In some big buildings, the terrain class uses the occluder pre-installed by art, and then the CPU makes a render target of about 256*111 to get the bounding sphere, query (CPU-side operations) is no longer included in the skip.

After a time test, this action has always been awesome.

The previous figure shows the scenario.

The corresponding software occlusion is as follows:

It is useful to write software Renderer.

In this case, both the CPU and GPU can be saved (if there are many cull instances)

The last two sentences are quoted, and recent work experience greatly agrees with this:

• It's all about Data
• Simple data often means simple code