Optimize tracing by removing redundant BSP brush planes at load time?

[slipher]

I've noticed that BSP brushes always have the full set of 6 possible axis-aligned bounding planes, even if some of those planes don't form part of the resulting convex hull. This was apparently done so that simplified in/out tests for the plane can be performed by just comparing a single coordinate, rather than doing the whole dot product. Then dot products could be skipped if one of the axis-aligned ones allowed a collision to be ruled out. Presumably this was faster on machines of the day which had slow floating-point ops. But we found in #1142 that in the BoxOnPlaneSide function, it's faster to just always use SSE vectorized code, even for axis-aligned planes. (Although I'm not sure about something... did we ever test with the old code for axial planes but SSE for non-axial?) Anyway, for tracing, SSE vector instructions are not so relevant since compiler toolchain technology to build with vector instructions in the VM is lacking. But we have decently fast float instructions regardless. So we should try pruning planes that don't bound the convex hull at load time to see if that makes it faster.

So far I've only spoken of tracing, but it's possible this stuff could apply to the renderer too (for frustum culling etc.) since it has its own BSP loading code. The BoxOnPlaneSide function from #1142 is used in the renderer.

[VReaperV]

So far I've only spoken of tracing, but it's possible this stuff could apply to the renderer too (for frustum culling etc.) since it has its own BSP loading code. The BoxOnPlaneSide function from #1142 is used in the renderer.

Renderer uses it to cull against frustum planes, not surface planes. The mins/maxs of the box come from the surface.