With very little changes to the original ManualObject code, it is easy to make it work much faster in the VS debugger. After measuring which parts of the code slow down too much I found that it happens in copyTempVertexToBuffer(), where STL iterators are accessed. (I don't get it why STL containers are used in core parts of a library where performance is essential, but that's beside the point.) The only change I made is allocating a small array of const VertexElement pointers. Instead of getting them many times for each vertex when calling position() from the STL container, I put them in the array, and use that for any further calls, until end(). This only happens in debug mode because VS takes extra caution in its STL containers and that causes very bad performance. In release code you can still use the original ManualObject (though not necessary).
With this I achieved 500fps when modifying a ManualObject with 4096 vertices 30 times per second, instead of the 2fps I got without this. I read that in previous posts people advised not to use the debugger for "measuring performance". That is a valid point, but most of the time you will be running your code in the debugger (until it is ready
) and such slowdown is not really bearable.Modifying the original code is easy if you download the source (you'll only need the OgreManualObject.cpp and .h), but for your convenience I have attached my version. For instructions see the top of the .h file. (You don't need to recompile Ogre, just include the header and use ManualObject2 in your project.)
01.02 UPDATE: I have added new functionality to the ManualObject. (See v2 attachment.) You can now replace part of the geometry if you call beginReplace instead of beginUpdate. Changing the position, color or texture coordinates of a vertex required rebuilding the whole geometry originally. With beginReplace, you can now really update them, instead of having to send the data of all vertices again. The code is not thoroughly tested yet, I haven't created subsections or checked whether changing texture coordinates really works or not, but as I find bugs I'll keep this updated. Please post if you find any problem with the code.
With this modification the number of vertices in the geometry no longer matter. Only the number of vertices replaced can influence the performance, but for the few vertices I needed to change so far there was no measurable slowdown at all.
