Short post today.  After the latest round of profiling, I’ve tracked down a few more performance problems and squashed them.

The screenshot is looking across a single MMO region, peppered with 1000 trees.  1000, because it’s a silly number of objects.  Trees, because they’re by far the most expensive model in the game right now.  The screenshot was taken on my almost-five-year-old laptop, and with all these trees being rendered, it’s still holding 30fps.  So I call that a victory.

There were two big slow bits to fix:

First, the material batching system was using templated container classes to store its batching information, and wrangling that data via the template implementation was much slower than it needed to be.  I switched to a hardcoded linked list implementation, and performance improved a lot.

But far bigger than that was the expense of collision testing.  Previously, every object in the region was being tested for collisions — both for the GraveShip and also for the user’s cursor.  With a thousand highly complicated tree models in the scene, that’s a lot of ray-vs-triangle testing.  So I’ve modified the collision testing to be performed using the region’s quadtree, so only the objects which are vaguely along the path being tested will actually do polygon-level collision checking.  So even in this absurdly busy scene, collision testing doesn’t show up at all in the profiling any more.

There’s still a little more that I could do.  For the most part, level placements (such as trees, buildings, etc) don’t move around, and so I could merge them together when they’re not being moved.  That might make a big difference.  Or it might not.

I’ve also played with doing level-of-detail calculations on the terrain, but reducing the number of terrain triangles doesn’t seem to actually lead to a faster render time.  I’d really like to get the frame rate up to 60 on this old laptop, but I’m happy enough with a solid 30 that maybe it’s not worth really fussing over too much.