Whew, where do the days go? Better start from the beginning.

First of all, I decided to start messing around with more extensions. Currently - vertex programs, aka, vertex shaders. Boy, those can do some nifty things. I finally understood the difference between per-vertex lighting and per-pixel lighting last night, not to mention exactly how each worked, as I stared at the vertex shader version of OpenGL's rendering code. It is fascinating to know this stuff after so long thinking I should never understand it. Here is a screenshot of the fruits of my labors:

I know it is hard to tell from that pic, but effectively the VP acts as a simple diffuse light. I still havent tried it on a high poly count (to test the speed of these things), mostly because of a reasons I shall outline further in this post. I think the best purposes for VPs will come with things like camera effects. First of all, you are controlling geometric position, texture coordinates, and vertex color, which lacks the precision of some of the cooler effects. But I bet with a little clever thinking, you could come up with some real cool stuff. Also, the universiality of it (it is inside OpenGL's rendering pipeline) means that if I want everything to turn blood red all of the sudden, I just have to put a vertex program into place that will change all of the vertices' colors to red. Essentially, it allows me to be lazy with my rendering pipeline, knowing that I can just mess with OpenGL's further down the line ;).

Now, why haven't I tried a high-poly VP test yet? Well the most despicable of bugs surfaced to me, of the crashing variation. A bug that not only refused to reveal the offending code to me, but was occuring in OpenGL's code. I had no idea what was causing that bug. The only clue I had was that it happened when I tried to render the world. It is like a puzzle, you know? So I uncomment the world rendering code... and still a crash, just as cryptic, just somewhere else. WTF?

I had really thrown myself for a loop on this one. Turns out that there were not one, but two different bugs. Of course, what I immediately thought had happened is that in my previous night's ventures, I had edited some code that was fatally affecting mine. Enabling/Disabling some state in OpenGL, something like that. Turns out that the VP tests had nothing to do with it. The problem with the world rendering happened to be with my VBO code. I didn't know it (since I worked from documentation, not example), but I needed to get OpenGL to give me a valid handle for my VBO. I had previously just been using constants - 0 for vertices, 1 for texture coordinates, 2 for normals. So eventually I found that out and fixed it. The other problem was with something in the UI I had put in the night before I started messing with VPs, that I never got to test. It was by some amazing coincidence that both of those bugs surfaced at the time they did, and it is certainly one to go in the record books.

Now I am off to test the shader on my world! Aie!

Windows in the UI!? Prepostorous!

:D

I got the screenshots working, and so ensues. They may be a little... dark. Sorry.

I got rid of the fake lighting (lower areas were darker) because one of my next tasks is to add REAL lighting. I expect that I will use lightmaps, at least for the ambient lighting, but who knows? I may even go back to my "fake" lighting, who knows. Happy labor day!

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...

CrazyFrazee911: mr thomas is an incompetant bafoon
Samim04: whgo the hell is he?
CrazyFrazee911: the fact that he is allowed near computers is frightening
CrazyFrazee911: the BCP teacher
Samim04: lol
Samim04: oh haha
Samim04: what did he do?
CrazyFrazee911: well first of all
CrazyFrazee911: I havent told you this, have I?
Samim04: no lol
CrazyFrazee911: I am pretty sure the moron doesn't know how to program... at all. He doesn't even know visual basic
Samim04: haha
CrazyFrazee911: I walked up to him and asked him, and I quote, "how do I make a subroutine return data?"
CrazyFrazee911: he said, what?
CrazyFrazee911: I figure he just doesnt know C/C++
Samim04: haha yea
CrazyFrazee911: since other functions, including visual basic, do something like <function_name> = <data> for returning data
CrazyFrazee911: I say this time, more slowly and hesitant this time, "You know, when you want a function to evaluate to some specified data in an expression?"
CrazyFrazee911: and he says to me, "I don't think I understand the question"
CrazyFrazee911: clearly, he doesnt understand where he is on top of that
CrazyFrazee911: that was monday
Samim04: lol yea
CrazyFrazee911: so today I am working away on my self-designated project, which is a data archiver so that I can password protect my projects
CrazyFrazee911: more for the experiance than anything else
CrazyFrazee911: so I am working away on that, and having just completed the folder and subfolder enumeration routine, mr thomas sneaks up behind me
CrazyFrazee911: "have you finished the lesson 1 assignment?"
Samim04: lol
CrazyFrazee911: now clearly on the screen is something much more complex than he can even fathom
Samim04: haha yea
CrazyFrazee911: and I figured that by then he figured out that I was beyond him
CrazyFrazee911: but he must think I don't know what I am talking about
Samim04: lol
CrazyFrazee911: heh, and I had previously shown him screenshots of my RTS engine
Samim04: lol
CrazyFrazee911: he couldn't even understand what "3d Real Time Strategy Engine" meant
Samim04: hahaha
CrazyFrazee911: like, he had no idea what an engine was
CrazyFrazee911: I ended up letting it slide
Samim04: yea lol
Samim04: dipshit
CrazyFrazee911: no joke
CrazyFrazee911: so eventually he was like, "well, go ahead and get back to lesson 1"
CrazyFrazee911: I think, well fine, I can push buttons like every other fucking monkey in here
CrazyFrazee911: so now I am a button monkey... a trapped code monkey :)

*Sigh*, another possibility for expanding myself drowned by an incompetant

See, I knew I could never finish Xion because, well, RTSs are a lot of work, especially without the help (if you remember, my inability to find good work is what killed the project). Besides, I was having trouble getting excited about the RTS... so then I thought, hmm, I wonder if I flipped that camera forward... how Xion would pass an FPS engine? Well, guess what? It was somewhat passable. So then I started tweaking the code, and now... well, it isn't all bad. I still want to get this thing to render 13k polygons of terrain with absolutely no hit to my fps, but that will be difficult. I added an end to the viewing plane (masked by fog, of course), but it isnt very close, so don't sweat it.

Here are the things I need to do:

• Make the terrain engine run smooth as honey. I mean, molasses. Shit.
• Redesign the UI system to allow multiple concurrently open UIs, giving me many more possibilities (as in, like, a windows system) and freedom
• Rewrite ExEs, the script powering the particle system, to make good use of a really good expression evaluator I wrote in my recent days, seeing as ExEs is pretty much just an expression evaluator, and the one in place just blows
• Replace the network engine with a version that spawned from it and was developed in another project of mine. I still have problems to fix, but the new version is, like, a hundred times better (manually builds packets, but so much cleaner it isn't even funny)
• Go from there

So I have much ahead of me, but that is all good, since I am excited once again. I originally thought about making Zombies! (an old mod of mine) on the engine, but later decided maybe not, so I am just going to concentrate on making the engine, and then worry about the actual game.

I don't know if the engine will remain open source or not. It isn't exactly like that many people know about it as it is. I won't release any new source until I know for sure :).

Laters.

Next we have a mini-comic of Valor, inspired by FLCL's tv boy. Wee?

That about sums that one up.