This certainly beats what I had before, still not quite right though…

There is a walk animation in there somewhere…
This certainly beats what I had before, still not quite right though…

There is a walk animation in there somewhere…
I am so close and yet so incredibly far from having a working skeletal animation prototype.
I have implemented all the essential code to generate an animated sequence, my stumbling block is now attempting to pinpoint the location of the error(s) which are preventing the model from be rendered correctly whilst also being animated. What really takes the biscuit though is the number of areas in the code where the problem could originate, or any combination of those areas.
So what to do?
Keep plugging away…
I have diagnosed the problem which has been holding me back for the last while, my method of extracting the data from Assimp’s data structure was not the issue. The problem was instead with setting the bone matrix array in the vertex shader using a uniform array. This method works fine when using a Geforce 9200M in my laptop but does not work as it should when using the AMD Radeon cards which are available in the University Games Labs.
For the moment I will continue to develop using my laptop and get the hardware skinning approach working, once this is completed I will also implement software skinning. To do this I will change the vertex array object to a dynamic array and calculate the bone matrices on the CPU and send the transformed vertex positions and normals to the GPU for rendering.
On to building the Animation Controller.
Ok so for the last week or so I have been struggling with some decisions I made earlier during the data extraction stage from the COLLADA scene. So with the aim of rectifying those choices I am currently in the process redoing the extraction stage with the aim of having all the data present and correct so that I can then concentrate on the animation controller.
Stressful is insufficient to describe the last week, fortunately some small relief can be discerned from the manipulation of the root bone from my skinned mesh as you can see.
Despite being ripped apart by a temporal distortion of some kind, this indeed is a sign of better things to come. Once I have figured out how to manipulate each individual bone in addition to the root bone, which you see ripping apart this poor latex sprites pelvis, I will be a stage closer to implementing a simple animation controller.
The scene also benefits from much more pleasing environmental lighting, as well as a host of other back-end changes which improve the ability to expand data structures without massive refactoring and use of smart pointer makes to name a few, this small piece of visual progress a larger step than it may appear.
So my last attempt at loading a model ended up with a nasty bunch of spaghetti type mesh, I have partially solved the problem and certain areas of the mesh are now rendering properly.
[EDIT]
So its the end of the day and I have one rendered asset imported, as it turns out I had enabled too many bitwise options when importing the file which cut out portions of the mesh, how foolish of me.
Over the last four months or so there have been a number of occasions when I have compiled code when writing a modern OpenGL application that compiles fine in Visual Studio but does not render as desired, worse yet nothing renders at all. The tool that has saved the day an uncountable number of times for me now is gDEBugger which is a tool for debugging modern OpenGL and OpenCL applications. I will not be going into the OpenCL side of things today, what I will be showing you is how to set up and debug your first ‘broken’ OpenGL project.
For the purposes of this tutorial I will assume you already have Visual Studio running with your ‘broken’ solution built and ready for debugging.
You will first need to download the latest version of gDEBugger, this is the direct download link for 32 bit Windows. http://www.gremedy.com/downloading.php?platform=windows32
Once installed you will want to select the Free Licence and start it up.
The first thing you that will appear is the Start dialogue, select Create new project…

Select OpenGL project.

This next step is important that you set these folder locations properly. By default Visual Studio’s folder hierarchy has the Executable in the ‘Debug folder and the Working directory is the location of the source code, in this case the ‘game’ folder.

So you should have something that looks like this with you directory path in place of #yourpath#

Click next and this will appear, you can leave this as it is and go straight ahead and press Finish.

The first thing you want to do when you enter gDEBugger is go to the Breakpoints menu and enable the following breakpoints so that we can decipher what is ‘broken’ about your application.

This next step is important, go to Visual Studio and BUILD not DEBUG your project. Make sure that your application is not currently being debugged (running) in Visual Studio and go back to gDEBugger and you ready to debug your application.
You can do this either by pressing this button
or by pressing F5 as you would in Visual Studio.
As an example I have made my application call a deprecated function which breaks the debug session, like a breakpoint in Visual Studio and give you access to a whole bunch of information of what is going wrong. The following four sections contain the important information when a problem like this occurs.

The yellow arrow is pointing to the problem function call.

Here the yellow arrow is showing where the application stopped on the call stack, this is not so clear as to where the problem is coming from other than that it is happening in glutMainLoop() somewhere but this still gives us a much clearer idea of roughly where the problem is occurring.

This pane give us detailed information of the problem, namely that the function is deprecated, can anyone see what else is wrong with the statement?

Finally here we have the log of all the process events, if you turn off the breakpoints in the menu, those events will still be logged here so you should make a habit of checking the whole list every now and then.
Probably the most useful feature though is the ability to view the data loaded into the graphics RAM. To view this your debug session must be PAUSED. Get to this viewer using the brick icon or using the menu View/Viewers/Textures, Buffers and Images Viewer.
As you can see when you zoom into these two images it is possible to view any loaded textures, Vertex Buffer Objects which hold the mesh data used for rendering as well as a number of other buffers.
There are other such viewers that you can explore in your own time that let you view the objects that are loaded into graphics memory that can prove very useful such as the Source Code Viewer which can be used to pinpoint where an illegal functional call is in your source code and the Shader’s and Kernal’s Source Code Editor. Have a look around and become familiar, they will be your friends before long.
So this week I began my attempts to building a working skeletal mesh animation environment and I have had mixed progress.
I have successfully loaded a slim selection of static meshes with no trouble but finding reliable skeletal meshes has been a problem. Having looked around I found a model supplied on the Collada Test Model Bank which contains a single humanoid walking animation set. When loading the model using the Viewer tool supplied with the Assimp SDK the model loaded correctly and the animation was playable.
My problem came when loading this model using my own framework, the output I got was the dreaded spaghetti. Having viewed the model with Assimp’s own tool I know it is not a corrupt file so I am going to have to review the method I am using to store and render the data and try again.
An alternative solution that I will also attempt in the coming week will be to seek out an md5 model and attempt to render that mesh. There are actually not many file formats that Assimp can load that support skeletal meshes, instead the more common method of the available formats is key frame animation which is not the focus of this project.
I have also looked into loading the asset on a separate thread so that the application does not hang whilst parsing the model from file.
Just spent the weekend making my game with Unity which is about a dead astronaut better know as Ghostronaut who flys through planets to get powerups whilst being chased by death in the form of a snake who eminates from the black hole at the centre of the galaxy and eats planets.
Had a great time, looking forward to the next one already
=]>
So back at University for the second trimester of my third year Games Development degree. Over the coming ten to twelve weeks I have taken it upon myself to undertake, for my Personal Programming Project module, the animation of skinned meshes to be undertaken using c++ as the development language, OpenGL for rendering, the Open Asset Import Library (Assimp) for asset loading and a good deal of brain juice to stick it all together. Wish me luck!