Thursday 30 June 2011

Quantum Bricks

New brick occlusion code is in - well, actually old block-based occlusion has been updated to correctly work with bricks. Its sub-optimal at the moment - and could be sped up by caching and reusing previous results to significantly reduce the work it does.

Also, the brick template doesn't have an occlusion cache, which I'm going to add in future brick data so it doesn't have to be derived from the brick collision. This will also make supporting transparent blocks easy too.

Being GPU bound, the occluded bricks have taken a lot of load off of the poor GPU at a very small CPU overhead so really makes a difference. They also reduced the VBO construction CPU spike as it iterates over fewer bricks to build the buffer, this has a huge impact

In general development, each baseplate object represents a 16x16 studded area with an AddBrick()/RemoveBrick() interface, as well as a smart pointer to the surrounding four baseplates. It has containers for AllBricks and VisibleBricks, as well as block data used for occlusion and collision. While it seemed like a good idea at the time, this one class is now running most of the game (VBO+Rendering, Collision, Occlusion, Streaming...) and I'm uncomfortable about it having so many responsibilities even if a lot of the work is done by external classes. In general, its a non-issue as the baseplate is constructed and configured by a factory, and managed as needed by the correct system(s) but the part of me that knows its wrong wants to fix it before it breaks rather than after.



No comments:

Post a Comment