Sunday 26 June 2011

Hidden secrets

The first optimisation path I tried when I had a world made of blocks was a block-based occlusion scheme. Since I know whether each block is occluding or not, its easy to check the six neighbours of a block and mark it as occluded.
Occluded blocks are removed from the visible set, and their vertex data is ignored for VBO construction so they lighten the load on the GPU at the cost of a small CPU and memory overhead.
In early versions occlusion data could be frozen - allowing you to manually check for problems and the scene could be rendered in wireframe, which again shows up if too many blocks are rendered. Both of these visual tests were removed when I changed from regular uniform cubes to irregular cuboid blocks, and somewhere along the line the occlusion check broke too.

Secondly, I'm rendering quite a lot of large Vertex Buffer objects and have just added a vertex dot product check to only render the ones that are a bit onscreen - this is all simple stuff but does serve as a reminder that I've built a lot of code from scratch and the rendering - until now - has all been placeholder.

As I'm approaching prototype, the graphical look and feel and specifically the framerate are turning up as items that need to be addressed as the project shifts gear from a whimsical code experiment to a functional tech demo. Thrashing the GPU with millions of polys isn't quite acceptable, and 100ms CPU spikes for vertex transforms or perlin noise gerneration are being smoothed out too.

The usual suspects are being wheeled out in the form of LOD models, fog, environment skybox et. al. in preparation for a prototype release. Like the previous development, each of these will only have to exist in its crudest state so I can cross them off as bug-free and feature-complete, two thirds of the development trinity. Agile Homebrew has the advantage of hiding the third "on-schedule" bar of the triangle and turning it into a non-issue. As with everything, it'll be done when its done.

The entire of Sprint 14 looks like render optimisations with no end in sight, but I'll probably get it running a bit faster and then cast my eye at the next set of tasks. I'm already drafting a list of what I want to see in Sprint 15.




No comments:

Post a Comment