Bsps in Practice

occlusion culling

• in practice a portal engine seems the right choice for this
• perhaps a software rasterizer running on the RSP could be used to draw a low-rez conservative z-buffer that you could test objects against
  • problems: needs special occluder geometry, gains unclear

making overdraw hurt less

working in caches

• L1 8 KiB data cache (16-byte cache lines), 16 KiB instruction cache
• 64-bit registers can be used for caching in tight loops

painters algorithm vs zbuffer

• zbuffer incurs a performance hit of 20% experiment
• painters algorithm could draw some objects 20% faster
• in practice you need to sort triangles. slow

BSPs

• in theory can be used to draw everything back-to-front
• would work perfectly if using vertex colors only OR a single texture
• upsides:
• downsides: can’t batch by texture, preprocessing cost, extra vertices because of splits, some memory cost
• with a zbuffer you can batch by texture instead. with BSP you need to draw back-to-front and then maybe try batch by texture
• in theory could batch by texture if polys don’t overlap in screenspace i.e. draw in visibility order and not literally back to front
• in practice texture swapping is a major hassle. texture cache is very small and can’t use atlases. i think you need to stall the RDP while updating a texture. that adds a bubble to your pipeline and will hurt performance.
• software renderers had more freedom. thats why BSPs worked in Quake (1996) and Thief: The Dark Project (1998)
• could use z-buffer for objects that intersect