August 31st, 2003 - Rendering Engine Is Winnah?
If you look below a post or two, you would see me list my initial tasks to make this pass as an FPS engine. Foremost on that list was to make the rendering engine faster. Hohoho, twas with ignorance that I did put those words to pen. I stand before you a greasey, stinky man, having sought this goal for a week. Here entails my travels, from my frail, handkept journal that doesnt really exist but makes this somewhat funny:
Day 1
My intentions are to strike a balance between speed and flexibility, by having the octree be capable of partitioning and rendering any number of meshes. The meshes are stored as a linked list. Data is randomly generated, then passed to the octree to be added to its list. The octree partitions it - the nodes store a vector list of 3 indices (mesh, group, triangle) - and then render it by working through all of the nodes, looping through the visible nodes' index lists and rendering each individually. Any time the texture changes, or the mesh changes, I stop rendering and adjust accordingly. I get approximately 30 fps with 20k polygons... work must be done.
Day 2
I have found some success! By using vertex and texture coordinate buffers, I was able to up my tolerable polygon count to 50k polygons! It believe that the rest of my problems lie with my code, because when I don't render my fps is still a bit low, but where am I losing those cpu cycles? I have made small optimizations all over (like putting meshes in a vector list instead of a linked list, a no-brainer). My goal is to be able to render 130k polygons at a minimum of 30 fps.
Day 3
Finding little inspiration, I turned to IRCnet's #opengl channel, where I have found many good suggestions, but little real help. There have been mentions of "vertex buffer object" extensions (VBO), but I really don't think the rendering speed has anything to do with my problem...
Day 4
I decided to restructure the engine so that the meshes can exist completely seperate from the octree, but still use its functionality - something I would prefer anyway. I added a byte to every triangle called the "rendering frame". The way it works is that the octree has its own rendering frame byte which it increments every frame, but skips zero on the loopback. If a triangle is visible, its rendering frame is set to the octree's current rendering frame. Then during rendering, the non-current rendering frames are set to zero and not displayed. That allows me to have a visible flag without having to clear the flags pre-render. However, I got little boost from the procedure, which is enough to drive me crazy. There must be something I am missing! In utter desperation, I have been trying to get people in #opengl look at my engine. Naturally, I get little help that way. I am so low right now... nothing I try works. Is there no end to the insanity!?
Day 5
I resolved to try VBOs, and guess what? It ran slower! I was baffled until I decided to completely bypass my octree code and render all of the 130k triangles using the glDrawArrays command, and guess what? I got 60 fps! I was really excited until I noticed the terrain was a little funky. Then I realized that there was an issue with the way my terrain mesh was generated. See, first a flat grid of vertices are generated. Then, triangles get their indices set to those vertices. The problem? My triangles share vertices. That worked fine with my old code, because I drew each triangle one at a time, but now that I am drawing in bulk, it just wont work. I have to redesign this terrain generator to make 3 vertices for every single triangle... time for restructuring (*shudder*).
Day 6
Hooooly crap, I am stuck with some serious math here. I have to reinvent all of these generation algorithms to accomidate the new design, and that is no simple task. The horrors of the first time have come back to haunt me again, and this time it brought friends. I can generate a level field pretty easily. It is when I try to set the heights of the points that it gets really hard. Why? Well look at the math. In a 5x5 field, there are 25 different points, but 30 actual vertices. In a given point, there can be anywhere from 1 to 6 different vertices sharing its position, and it is specific to the position in the field! Not only that, but the relations between the given point and the actual answers ALSO vary by position! It is a mathematical nightmare! There must be a mathematical model for this...
Day 7
Success! I decided that finding a mathematical algorithm to calculate these positions would prove nearly impossible, so I managed to come up with a programming solution! See, when the field is generated, the positions of the vertices are calculated using the point position in the field. So there was a direct relation of the position with the index! So I was able to calculate the index in reverse - I would cycle through all vertices and discover which point it related to, and then set the height accordingly. After that, it was a matter of making my octree render the nodes in blocks by using glDrawArrays. Fortunately, the actual data used for rendering is stored in a seperate buffer from my terrain data. So what I did was build as usual, but post-build, I would cycle through every leaf in the octree and add its vertices consecutively to the buffer. Then, I would store in that node where its triangles started in the buffer and how many there were, so that I could use glDrawArrays in the node render. It worked without a hitch on the FIRST COMPILE! I am so excited, I think I will put this in my weblog!
And that brings us back to here. Like how I kinda made it fit into this log at the end? Yeah, I rock.
So now the other tasks on my list below. I think I will actually start by making the UI even more robust, via a window-type system. That would be quite nifty...
