Octrees and terrain... and tutorials.

A small update on what's been going on. My most recent portion of code has been involving the terrain, and how I'm going to be structuring it in the PSP's RAM. My decision was to use an OctTree to display it.

OctTrees 101: We decide on a constant value. This value is how many triangles of a 3d mesh we want as a maximum inside 1 OctTree node.

Now, imagine putting a 3d mesh inside an invisible box. This box is your "root" OctTree Node. Now divide that box in half, 3 times. Once on the X axis, once on the Y axis, and once on the Z axis. This will result in 8 equally sized "child" nodes of the "root" node.

Check each child for the same thing, does it have more than our constant value we decided on earlier? If so, divide that child into 8 smaller boxes and continue doing the same checks/divides until every child has less than or equal to our constant value, triangles inside that box.

The benefit of this is that I can tell the PSP to only draw the triangles inside the OctTree nodes that are visible right now. This saves the PSP all sorts of computing time.

So, OctTree it is. Unfortunately, I'd have to calculate that octTree everytime we load the world map (which would likely be only once or twice per gaming session), and on my example map (which was QUITE small), that was roughly 8 or 9 seconds of waiting. In my opinion, that is unacceptable.

So, as of late yesterday afternoon, I finished writing my "OctTree Serializer" which basically takes that whole tree of OctTree nodes (starting with the "root" node, and all 8 of it's children), and saves all that calculated data (which triangles are attached to which of the imaginary boxes...) to a file. So now instead of loading a 3d mesh and calculating an octTree for 8 or 9 seconds, I will load a 3d mesh, and load an ALREADY CALCULATED octTree and attach them together. I haven't finished integrating it into my game yet, but stand-alone, it is fully functional, and I suspect the loading time will be cut down to likely less than a second.

Something kinda humorous. Typically, programmers will write small programs that will do something for them, to make their programming lives easier, or maybe write simple editors & whatnot to make creating content for the game easier, etc... Normally, regardless of what platform the game will be for, since it's being programmed on the computer, these "supporting programs" will usually be for the computer, since they'll never get distributed with the final product. Well, this is my first "supporting program" I've written for FFVI3DPSP, and what's kinda funny is that I made this program specifically to work ON the PSP, to help me create the content I need for my game on the PSP.

During the time that I was working on that program, it had come to my attention that there was some demand for some tutorials on programming for the game engine I'm using, the LTE Game Engine. So, since I felt I needed a small break, I promised them I would write a tutorial or 2 after I finished my supporting program. So yesterday evening/night, I wrote 2 tutorials on LTE GE Programming. For anybody who's interested. These are posted directly on the LTE GE forums, since that's what it applies to. I hope it's no problem to post these links here.

Creating a "barebones" application in the LTE Game Engine
A Gamestate Handler in the LTE Game Engine

Since I've now got that tutorial writing thing outta my system, I'm going right back to programming, and I'll be integrating an "OctTree Deserializer" (it loads the OctTree from the file, instead of calculating it) into my game now. Maybe, if there's enough interest, I'll be writing some more tutorials at some point, since I can do them relatively quick. But by far my main focus is still my game programming.

With this simple terrain stuff I've been writing, I'm starting to see the limitations of the PSP's CPU. I'm gonna have to start being creative with how many triangles are being rendered at any given time in order to keep the framerate at a respectable level. With RPGs, I believe that a lower framerate is acceptable than for FPSs and such. I'll probably be shooting for a bare minimum of 20-25 frames per second, although ideally I'll want 60, which is the PSP's builtin maximum.