I'm thus reading up on the 3.1 spec. I already handle all transformations for my scenenodes manually by calculating local and global transform matrix per node based on parent/child relationship, so all I need to do here is to pass it to the vertex shader through a uniform instead of doing the glMultMatrix before drawing, like I do now.
I need to start calculating the projection and modelview matrices manually though, and also do the gluLookAt and gluUnProject myself. Will be interesting to see the performance increases that hopefully will result from porting this to a 3.1. I also found that the glDrawElementsInstanced is supported by opengl 3.1, this is perfect for a Tower Defense game where you want many identical units on screen at the same time! Although the performance benefits aren't quite as great as it is for DX, it will be interesting to try it out.
The ability to only update a range of vertices in the buffer also sounds great. I can imagine that the animated meshes can benefit from this, unless I can manage to extract the joint transformation matrices instead and send it as attribs to the shader and do it there...
The possibilities for what I can do now though is huge. The project description states we have to create animated water for the scene, where the grid is created in CUDA/OpenCL, but displaced and animated in the vertex shader. We also need to use multitexturing for implementing a terrain displaced through heightmap and then have one texture that covers the whole terrain (this I have already implemented in the fixed function version), but then we should have a second detail texture that tiles at every grid cell. Will be cool to get this in with normal mapping and everything! We also have to do per-pixel lighting, environment mapping and implement a skybox.
First off though, I have to fix some issues with my engine, some bugs I found, before I start porting to 3.1.
1) Need to rewrite the node wrapper for ms3d meshes. The texcoords and normals are not converted correctly, and I do not support mesh groups and multiple materials/textures for a model. I should also look at exporting the joint transformations for the AnimatedMs3dNode scenenode wrapper. Maybe each group could get its own scenenode?
2) Look into ways to optimize VBO usage. Right now every single object gets it's own vbo for index, vertex, normal, texcoord and color arrays. Maybe I could benefit from implementing these in the same VBO and using offset in the buffer to access the different arrays. I've also thought about having each object hold only one VBO, no matter the number of graphical scenenodes is attached to it... but this sounds like it could get bogus... (especially thinking of the towers here which consist of 3 modules). I have to keep in mind that I want to do the glDrawElementsInstanced too though, and will have to look into how I can get this set up properly. Probably the factories must pay attention to which nodes are instanced multiple times. Maybe I need a factory for the INodeRenderInfo object, which holds the actual render information. Since this is the info I'll be instancing anyway... hmm, yeah, that should probably do it! This RenderInfo factory would need to keep count of the amount of instances a specific node type have requested, and store it for use when doing the instanced drawing in the renderer. If anyone have any comments/insight on this matter it would be greatly appreciated!
3) Where possible, I should resize the vector lists before pushing in data. Right now I just do a headless push_back for all vector lists, where resizing first could probably create some speedup. Especially for meshes with thousands of vertices!
4) Need to implement finite state machine at the object core. During writing the gameplay the last week I saw that this would give me some huge benefits when writing logic and connecting logic in different systems. Feks changing animations intuitively based on the state of the object, instead of having to tell it explicitly which animation to play. Also I saw that in the railgun code I did a ton of if checks to get the cooldown functionality and everything to work. This would be a perfect candidate for FSM.
5) Need to restructure my object-object, object-component, object-node and component-node relationship and clean this up into a more strict code habbit. I found that I did some bad decisions during the last week of crunch that gave some headaches the last day of development.
6) Write factories for loading textures and ms3d meshes. Loading especially meshes took quite a bit of time, and I shouldn't load the same mesh or texture more than once into memory! The factory should be able to sit on the instance of each loaded mesh/texture and give out a reference when needed. Might have to look into how this will affect the joint transformations in the ms3d loader for animated models. I might have to seperate that functionality so that the vertices, normals, etc can be reused for all nodes using the same mesh. Not sure if this is how it already works however.
7) Rewrite for using Glew instead of Glee, as Glee has no 3.1 support at current time.
8) Need to clean up a hack in the ObjectFactory, where I now do a PostInit explicit call for registering some object types with the factory after the Level1 gamestate has been loaded due to some dependency issues here. Such dependencies should not be present at all! This was introduced after I added instancne pooling in the object factory. This allows the factory to pool up some instances of an object at initialization. So I have two options. Either all pooling is done as the last step of the core manager's initialization process, or I pool up at least one instance of every object type, so that the Level1 gamestate will only use pooled instances, and then make sure that other objects does not require any dependencies at construction. Should probably make it so that the initialization step can be extracted from construction in the factory... obviously I need to look more into this before I find a good solution...
After these are in place, I can start on the OpenGL 3.1 implementation! What a great school project though!!!!
