Gorgeous Reflections!

I'd had the idea of parallax corrected cubemaps as a method for quick rendering reflections in my head for a while, but wasn't sure how possible it would prove. The answer? Not just possible, gorgeous! All that I'd hoped for and more. I'm already toying with layered cubemaps - especially close to the camera - to better engage with the depth of the ship. I'm not 100% on how much strain this will put on major ship updates, which may leave me finally implementing a non-vital update thread on the fourth and final unused core of my cpu - but it does bring my resource management engine's abstraction to the forefront of my ram-saving plans moving forward, with parts in like-environments sharing cubemaps.

Was that technobabble? Maybe a little, I'm a touch over-excited about this working as well as it has!

Being wrong is heart-breaking

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.

These examples imply that front to back rendering is more important than concatenation. Separation is slower than concatenation, but will also guarantee render order and allow for culling, making it the best option moving forward.

Buffer optimization

I'm about to embark on dynamically combining pre-warped ship parts into singular models for decreased render calls and increased performance. I don't like having to rewrite and refactor important code, so I decided it was best I check which buffer layout renders fastest BEFORE writing my (admittedly pretty straightforward) model combination code.

Imagine being so hellbent on achieving peak graphical performance you literally write four different model classes just to see which one will render fastest. You'd have to be- (water begins cascading down forehead) -like a complete maniac or something. For anyone wondering, the most optimal technique seems to be to store all vertex attributes (position, normal, texture coordinate, tangents, etc.) in one long buffer, and access it via an index buffer and an offset. Conveniently, this is how the PLY model format reads, making it incredibly easy to use .PLY as a standard model format for my game. Less conveniently, PLYs take too long to load and I already decided in the long run it was best to just byte-stream data in and out of the program. Yes, I'm worried about malformed model files crashing the program and am tossing up how much error checking I want to include. I'll fix that later, I hope.

Pictured: Render times for 100,000 draw calls from each format of the example model; two separate linear buffers without indexing, two separate linear buffers with indexing, one mixed data buffer with indexing and offset, and one mixed buffer with no indexing with offset.