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:
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.
No comments:
Post a Comment