@ MrV - Thanks!
@ Jamez0r - The choice was based on a combination of the things you mentioned (speed, compatibility, utilities). Speed was the deciding factor, I could have lived with less support for other things. And it wasn't even the rendering speed, it was the processing speed of everything. It took just as long to process the game as it took to render a frame (stress test with 100 units). Perhaps that's a sign of poor code (you can check the source), but I knew that even if I managed to double or triple the speed, most of the planned mechanics would be too much for DBP to handle.
I've looked into a few and have settled on Ogre3D. It's the most supported, still being actively developed on, and pretty well documented.
For 2D games in C++ I recommend looking at SMFL.
I was looking for a complete RTS engine, and a few exist (best known is "SpringRTS"), but from what I could find out about them, they aren't as dynamic as I hoped they'd be. PonyCraft is a hybrid between an RTS and RPG, and has other special needs that can only be programmed directly.
So I had the choice to either learn how SpringRTS works internally, or I had the choice to just learn how to use a graphics engine, which would benefit me far more in the long run.
So will I be building it "from the ground up"? That's a tough question to answer in C++, because the defining level of "the ground up" would be to start with assembler. I will certainly be programming most of it using existing libraries.
Thank you!
@ Sergey K - Thanks for the very kind words.
@ Chris Tate - A tough question to answer. The workflow is very different, and since I'm not yet accustomed to most of Ogre3D's power, it's hard to judge. Some things are much, much faster workflow-wise. I was able to get an XML parser up and running within 10 minutes (RapidXML). 3D pathfinding with navigation meshes? No problem! Looking for a way to project decals onto a terrain? Ogre has you covered!
As to the structure, it's far more complex and takes a while to get your head wrapped around the different design patterns (Listeners, factories, singletons, inheritance etc.) and the big problem with the language is that it allows you to do anything - including doing everything wrong.
I'm happy with the decision though, in the long run everything will turn out. I may still prototype things in DBP just because it's faster to set up, but that's it.
TheComet