Today I dug into some heavy 3D math with rays, planes, and bounding boxes and found myself deep over my head in a heady swirl of algorithms that I'd never heard of before, let alone seen implemented...
When making past projects in Unity, I had been aware of engine terms like "culling", "frustum", and "bounding box", but since I rarely had to deal with them to complete my projects, I'd never really paid attention to what such terms actually represented. So now, when I found myself implementing things like collision detection for planes and culling functions for an oriented bounding box, it was all I could do to keep up with the high-level concept of what was going on and the purpose of the function, let alone try to understand the complex algorithms used to actually cover all the bases for the calculation!
This leaves me with a bit of a dilemma. Do I go back and try to understand these algorithms in detail? Since this is a learning project, I feel a certain obligation to do so if only for the sake of completeness. However, I'm certain that such an endeavor could take me a very long time indeed and would distract me from the overall goal of completing this game engine.
Thankfully, this is one arena in which the authors of 3D Game Engine Programming were quite thorough. For anything remotely complicated, Zerbst and Duvel note in detail what algorithms are being implemented, who wrote them, and in some cases where the original source materials can be found. Therefore, I do feel comfortable moving on to the next part of the project, as I will be able to easily return to this section of the book for a deeper dive if I so choose. Furthermore, I was struck by a further area for possible upgrading once the engine is complete. Are these algorithms outdated? Have more efficient ones been developed by others in the years since my reference book was published? I do not know, but if I do choose to revisit this topic, this question will become central to my pursuit of deeper understanding of the algorithms I'm using.
I'd also like to leave a word on code styles. More so than in the past, the code examples I saw in today's work were clearly written by two different people. Moving from example to example, I often found that while the code was very similar, there were small differences in naming convention, amount of commenting, etc. that became apparent to me as marking code written by one of the two authors (though obviously I can't tell whose code is whose!). Not only did this observation provide a welcome exercise for sharpening my ability to identify different coding styles, but it also gives me another task for future visits to this code: cleaning things up and making sure that everything across the entire project is standardized!
While I'm excited to continue my delving into the depths of 3D mathematics, it will likely have to remain on hold for the next couple weeks. I'm happy to say that I'll be attending Game Developers' Conference this year, and thus much of my free time will be taken up with preparation for the trip. And then, of course, there will be the joyous, energizing meeting of wonderful people that is the conference itself. This will be my second time attending, and if my experience at GDC 2013 was anything to go by, this year will be an absolute blast! I hope to see many old friends again, and meet many new ones (perhaps even some of the few that read this blog!).
Progress So Far: Implemented classes for rays, planes, and both oriented and axis-aligned bounding boxes