Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.

Skeleton, animations and instancing

Progress report for the skeleton is that I’ve managed to load everything I need from COLLADA (finally!)  and also save it just the way I want it. That is for the exception of animations, but I’ll come to that later. What I’ve managed to do though, is to load a skeleton, and put it into bind pose, or whatever pose it was left in when saved. This means not only that the linear hierarchy structure I talked about later actually worked, but also that I’m well on my way to start animating them.

The picture shows the carefully Seymour_anim2_triangulate.dae example file from the model bank. You can see the nodes, with the red node being the root node, the yellow being one foot, the purple being the other, and the cyan being his head. What you are seeing is the skeleton in bind pose, and each joint’s corresponding local coordinate system. I’ve got the math down for the animations as well, but here’s where the tricky part comes. To preserve memory space I’ve saved the skeleton and animation clips, and each AI will have their own set of joint matrices. If I want every single AI to be able to be in their own time frame with their own sets of animations, this is how I have to do it. Each AI will use their associated skeleton’s bind pose, animate it, and save the matrices received as their own. If I batch this it should be fast, maybe not 50000 AI’s fast but fairly fast.

The only problem is that if each AI can have several animations playing, that means each joint can be in several frames at the same time. So I have several AI’s that should be animated, and each of them have a set of joints (19 for this model) that all can be in several time steps, but I do not want to process them one at a time. I want to apply every interpolation of every joint of all characters in one function call. But I’ve saved each animation frame in an array in each animation clip, so I can’t really send all the animation frames I want to a function without copying them to a new array, thus allocating memory each animation step, and I do not want that! I’ll have  to rethink. Also, you might wonder why i’m doing this all on the CPU when I’ve made a rough design of how animation data will be stored on the GPU. The answer is that I want to get all the math down, and by all I mean everything from getting a skeleton correctly structured and rendered to animate it and skin it. When I’ve done that, I can start working on how to sort it on the GPU.

I’ve done some work with the rendering engine as well, even though it’s not my territory. I did that because I have an ATI graphics card at home, and it seems that the Nvidia cards we have at the university are a bit more forgiving when it comes to messing up your VBO’s. So I took the opportunity to fix it so that it works on ATI cards as well. We figured as soon as yesterday that we made a much to big VBO than we needed to, and also drew a lot of triangles that simply wasn’t there, giving us a poor frame rate. The important part is that it seems to work now.

//Gustav Sterbrant

COLLADA – the first steps

I’ve been working on getting a content pipeline for COLLADA into our system. This has resulted in using the COLLADA DOM version 1.4 using COLLADA files of version 2.1. I’ve written an import class that can parse a COLLADA file, extract vertices, normals, texture coordinates and vertex influences, and save them to a render-friendly format. Features will of course be added for reading animations in the close future.

//Gustav Sterbrant

Research for the render engine

I’ve been doing some research and planning this week together with my teammates, and have found some interesting articles with techniques which probably will be of use. One of them is geometry instancing, which is basically having one source for geometry (a mesh) and this geometry is rendered for each instance, this will reduce the number of draw calls to the number of geometry instead of number of objects. The only drawback is that every object look the same.

Mostly I have looked into general data oriented design for better understanding of the performance boost it gives (we will need this), and for the scenegraph I’m going to do. We did a practical test for a data oriented structure with the math library we are going to use and the result is looking promising :). We’ve also talked about how the frustrum culling will be done and we have some ideas that I think will work really well.

I’m really looking forward to this project and I hope everyone is as exited as me.