This read might be a touch lengthy.
I'm a tad stubborn (if you couldn't figure it out just from the fact I'm making my own game engine) and the key to some of my more impressive successes is also one of my major downfalls. I very much refuse to believe that I can be wrong until I can see it for myself; when the entirety of stack exchange tells me not to code a certain way, I tell them I'll code how I damn-well want and find out its downsides myself. When someone tells me some computers just aren't powerful enough to run games, I create my own engine to prove that's not the fault of the computers, but the fault of the developer. Often, this will lead me down long rabbit holes to new and creative solutions, and sometimes this will lead me down long rabbit holes that abruptly end with a dirt floor and wasted time.
In this case, I found myself in the latter. For a supreme amount of time while designing my engine I knew that swapping buffers in OpenGL can be an expensive operation, so there was render-time to be saved from a process of model concatenation - stitching models together back to back when they're all going to be rendered at the same time, and with the same shaders and textures and uniforms. I had myself convinced that this would hyper-speed my creative building game, and all it needed was some clever structures, mapping techniques, and linear render-queue baking.
Finally, after much deliberation about how to cleanly implement all I wanted to, I had an up and running example project with hundreds of separate objects, and hundreds stitched together into one, and I was abruptly confronted with the realization that I was - god forbid - wrong. Or rather, I was right, and it did indeed save render time, but saved significantly less than I'd expected. I'd expected a 50-60% increase in frame rate, and I got hit with a 12%. Now don't get me wrong, 12% is non-zero, but here's where the kicker comes in. The very minor increase in frame-rate implies something greater about my graphics, and that is that it is primarily fragment bound and not vertex bound... meaning there was quite possibly different render time to be saved by instead rendering the scene from front to back to enhance the effects of depth-based fragment culling. I ran a test, and there was the massive frame increase I'd been looking for. Not in model concatenation, but in render order. Heart-broken, I've left the model concatenation code to stagnate in a header I'll likely eventually remove.
I'm disappointed, I won't lie, but this does give me a greater understanding of what to do moving forward. I'm imagining some more x-y-z order-based part storage to allow for ordered rendering, and hell, maybe even proper frustum culling, and better collision optimization. I'm upset, but that's okay, progress is sometimes best made through being wrong.
