Optimization, Multithreading, and KillZ

While I would like to tackle something much fancier, I noticed a severe performance drop when implementing Recast. Thus, it was time to hit the profiler in Visual Studio! (Debug/Performance and Diagnostics, start profiling in the Performance Explorer) There was a bit of a problem where the application directly needed D3DCOMPILER_47.dll, but that was as simple as taking the actual dll out of the Windows Kits 8.1 bin folder and placing it in the application for extra packaging.

When noticing the profiler, I noticed a single function that ate up most of the profiling time: navMesh.GenerateNavMap(). When jumping into those functions, I unfortunately came across a profiling nightmare; API being responsible for the performance drop. What to do? Luckily enough, there were a few settings I adjusted before running it a second time. When running rcBuildPolyMeshDetail, the function can take up a lot of processing time unless you allow for a little more error. 0.1 was a bit much for this simple function, so I raised a bit higher. Similarly enough, the rcRasterizeTriangles method also took up a lot of space, so by reducing the triangles (increasing maxEdgeLength for the navigation mesh) definitely helped.

For one last shot at fanciness, though, I did indeed take a look into multithreading and set the world geometry setup/navMesh setup into a thread that was run separately from the rest of the function. Luckily enough, there was a high enough performance raise to warrant its creation.

So far, I think that's the most I'll get optimized for now. The bottlenecks lie strictly in third-party API zone at this point, with Bullet's stepSimulation taking up Render()'s time and the rest of the init code being taken up by Assimp's file reading. If anyone has any other recommendations for optimization, I would most certainly love to hear it. Onto fog for our next round...

Oh wait, forgot to mention; I setup a KillZ point to restart enemies and players upon falling too far.