Bouncing Polygons!

Finally!  I've got stuff moving on the screen.  It seems that I was over-thinking things with my previous attempts at getting the cube to move around.  All I really needed to do was pass the data into the vertex shader and let it handle the rest.  Whatever, It's all working now.

With this we wrap up two topics.  Textures will be done; well more done, my texture code was done after the UV coordinates.  As well as transformations and animation.  Or at least the basics of animation are done, this just shows how to move and distort meshes, actually making it look like real movement takes a bit more planning and effort.

Loading Textures in GL

I've got colored polygons on the screen.  Flat colors like that really aren't all that visually appealing.  I'm sure you could arrange enough of them to make an interesting picture, but it seems like a lot of work.  What would be a lot easier is if we could just take some image data and stretch that across the polygons.

My Model Class

Next thing to clean up is the code for managing models.  What it needs to accomplish:

• Load all necessary information from OBJ files
• Remember the buffer objects to store the data needed for rendering
• Track the changes to the model data and only update buffers when changes happen
• Perform all the work needed to render the model

Once again this class will likely be kept in a large array, one element for each model I have a need of drawing.  Eventually this class will need extended to be able to manipulate the object, or at least track transformations that it'll need when rendered.  I haven't dealt much with movements yet, but that's going to have to happen soon.

My Shader Class

In an effort to start organizing the code needed in an OpenGL program I began building a few classes to manage some of the work.  The first one I put together was the GLShader class.  It's job is the following:

• Remember which files hold the source code for a particular shader
• Be able to load the source code from file then compile and link the program
• Remember a list of all Uniform and Attribute variables that this shader will use
• Assign specific ID's for those variables when the shader is compiled

I envisioned an array of this class being created when the application loads.  Each element will be given the source files and variable list from some configuration file which it will then maintain.  Then as needed switching between the various compiled shaders at run time to render my scene with different effects.  Also I'd like to be able to reload shaders without restarting the program, to make it easier when debugging shader code.

Shader Attributes

We've passed data to our shaders, but it's one size fits all data.  There's going to be situations where we need different information for each vertex, and pushing all this in uniform blocks just isn't going to work.  It's time to try shader attributes.

These are arrays of data, each element of the array should correspond to one of the vertexes.  When the shader executes it will only read the element that corresponds to the current vertex.  This is handy for things like locations, colors, normals and so forth which need applied individually to each vertex.

Talking to shaders

I've finished create the most basic of shaders, and they work in the sense that they get polygons onto the screen.  Let's step them up a bit.  To do that we'll need to pass data to the shaders, perhaps a color and maybe the model projection matrix to start moving away from those deprecated attributes.

I'd like to move up to a newer version of OpenGL, but I'm limited to version 3.0 (GLSL 1.3) since that's the highest version I can reach with all the machines I work on.  I'll make an effort not to use any features that are removed in later versions, I can't make any promises since it's not always easy to know what features those are.

Adding shaders to your program

We've got some code that draws a pair of triangles using vertex buffer objects (VBOs).  They can only be seen on some video cards, and if you do see them they are plain white.  Adding a shader will get them drawn everywhere and let us apply some colors.

The first step will be adding some code so that our program can load shaders and get them to be applied when drawing polygons.  So lets start there.

Triangles drawn by VBO's

It took me a while to figure out Vertex Buffer Objects, they get pretty involved and throw you into some complicated stuff.  I'm not sure I fully understand all the stuff I had to do to make them work, but the program does what I want it to do and that has to count as some kind of success.

There's a lot of stuff to cover on this one, and with the hopes of keeping the posts at reasonable sizes I'm going to break them up into a few posts.  In this one I'm going to cover how to use VBO's to get your polygons on the screen.

Shapes and colors in GL

Previously I went through how to create a Windows form with an GLControl in it.  Nothing was drawn in that control, and really whats the point of having OpenGL accessible in your program if you don't actually draw anything?

There are several ways you can tell OpenGL to draw polygons.

• Immediate mode is the oldest and probably the slowest method of drawing.  They are not included in OpenGL ES, which is what Android and iOS devices use.
• Vertex Arrays was introduced in version 1.1.  This allows you to pass chunks of data to OpenGL in a single function.  All the data is stored in program memory which means that it needs passed through to video memory in order to render anything, this hampers performance quite a bit.
• Vertex Buffer Objects were released with version 1.5.  This moved the information needed for rendering into video memory which boosted performance.  I believe this is the preferred method of rendering objects currently.

When I was first working with OpenGL my machine had an integrated Intel video card in it.  The drivers only provided OpenGL version 1.4 which blocked all of my efforts to figure out vertex buffer objects.  Fortunately, that video card has been replaced with something better and I can play with modern methods.  I'm still going to take some time and go over the old methods just for completeness.

Tinkering in GL again

A long while ago I had puttered with drawing in OpenGL via .Net.  It was an interesting diversion for a while, but I ended up quitting that since I couldn't envision it really being viable.  Since .Net is an interpreted language you've got the run time environment causing some delays in executing your code.  For games you need to be rendering the screen 30 times a second, I had a hard time believing that this would be possible within the .Net environment.

I should have known better since this has been done in Java, which is essentially the same sort of setup.  Sure enough I was proved wrong.  I got into the Hex: Shards of Fate alpha from being a Kickstarter backer and soon discovered not only was this game written in .Net but it used the Mono framework as well.  The graphics appear to be going through the Unity graphics library as well.  All of the .Net parts they are using can be used on mobile devices as well, presumably this is how Hex will be getting onto those platforms as well.  From a technical standpoint I'm very curious how this game will end up.

From a more personal standpoint its rekindled my interest in using OpenGL within a .Net application.  With that in mind let me dust off that old code and see if I can't figure out how to make it work again.