Wednesday, April 16, 2008

Adaptive Quadtree

I tried hard to optimise my code but in the end I just don't think a quadtree is suited to very large terrain. Here are some of the things I tried:

  • The quadtree is now adaptive meaning it only creates children if it needs them to render a more detail
  • I tried to Dispose() of unused resources on the fly but this really slowed down FPS
  • The quadtree now uses a shared vertex buffer reducing the number of calls to the device (before each patch would have its own vertex buffer and its own index buffer)
  • I tried using NProf to do some performance analysis on my code, but it didn't help me target anything in particular

I'm not 100% sure but I think the main problem is the number of objects needed to render a quadtree increases exponentially when the terrain size increases. With CLOD the number of objects is pretty low in comparison. For a terrain length 256, I use 16 CLOD patches but I would need over 20,000 quad patches. It's a shame, I think quad is neater in the same way that binary search trees are neat. Check out some comparison shots of a large (1024 * 1024 vertices) terrain:

1024QuadWire 1024CLODWire

1024Quad 1024CLOD

They look similar enough but for the quadtree I was getting about 4 FPS and for with CLOD I was getting between 20-30 FPS. I'll stick with CLOD for planets I think.

1024ClodLandscape

No comments: