Previously I discussed a problem with my heightmap collision shape and how several objects wound up falling beneath it, forever to stay mole-like in their habitats. Today I set out to resolve this and in doing so discovered I would likely be better off restructuring my entire handling of the heightmap in both terms of rendering and collision handling. So as I began rewriting it, I naturally tested it all, and I was confronted with this:
Regardless, I kept going and got a few more things accomplished. I added a physical object to which the camera is tied. What this does is it allows Bullet to take care of the player bounding along the ground, falling, jumping and interacting with other objects. So that's crossed off the to-do list (item #14... currently).
I also added some optimization regarding z-sorting. In other words, I've implemented a simple system that sorts everything based on the object's z-coordinate after coordinate transformation per the camera's position and orientation. By doing so, I can selectively render only objects that would appear on the screen and nothing that is behind the camera. I know that seems like it should be something automatic, but it's not. Graphics libraries (OpenGL, DirectX, whatever) will still attempt to draw every pixel in a polygon regardless of where it lies relative to the drawing window. So now I've optimized that bit.
So pretty! As you can see in the screenshot above, I also added a teensy polygon counter which came in handy while working on the aforementioned optimization. As you can see, there's not a terrible lot on the screen, yet there's still more than twenty-one thousand polygons being rendered. One of the reasons for this is that the sphere's I'm using each have 600 polygons (proooooobably more than necessary at this level). Another reason is that the optimization is still not quite as good as it could be.
Even though I'm clipping out everything behind the camera, that's not everything that's outside the cone of view. Look at this:
Here, the white area is the cone of view that the player actually sees. The dark gray area is everything that I'm already selectively not rendering. That leaves the light gray area as filled with land and object polygons that are still being rendered in the GPU. This is something that I will tackle at another time.
Yet another reason that the poly count is so high is because I'm not employing any sort of Level Of Detail (LOD) for the ground. LOD is a term used to describe a method by which the renderer will omit details of objects or land when they are far away from the camera. After all, you can't really discern them anyway. But currently I don't have any of that yet implemented. I intend to, but it will be some time. I actually intend to do a much larger map than I'm currently using, set up as a 3x3 array of heightmaps. The player will always be in the center map. If (s)he moves to an adjacent one, that one becomes the center map, any non-adjacent maps are dumped and new ones are loaded on the fly. That's the plan. By doing so I'll be able to implement LOD for adjacent maps, while keeping the current one somewhat higher in detail.
On a side note, my business cards came in! I'll be passing these out at PAX East in less than two weeks (aiee). Have I mentioned that I am ridiculously excited for PAX? Last year's was crazy amazing and this year will only be bigger, having proved our city's worth to developers and would-be panelists.
Maybe I'll see you there, maybe not. Hopefully I have enough of Rustbot completed by then to demonstrate it as at least a proof of concept.
I'm going to relax now, as I've been chugging away at this work for the past eight and a half hours. Adios.
No comments:
Post a Comment