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

Animations wrap-up

This week has been stressful. Not only did I realize I had made some mistakes in the animation system that would only allow you to use one skin, but also that you have to queue the animations per agent, not per chunk, and that all animations are looping. What I’ve fixed is the ability to enqueue a chunk of agents to use an animation, and also to use multiple skins. This allows us to have both the new and pretty costume man, as well as the penguin. The way I solved this was by using a texture containing vertex positions for each skin, so that I didn’t have to update all previous strides when queuing an animation using another skin. The result would be that they were mixed together in the vertex positions texture, so that the first could be the man, and the second could be the penguin, which made everything unnecessarily complex (This solution should be credited to Viktor in the second year). I will have to test the looping part when we get the animations that shouldn’t be looped, which should be in the weekend.

Also, after some research it turns out that the Nvidia development drivers for the GTX 570, as well as the newest commercial release of the GTX 570 driver has a major performance issue when it comes to aquiring and releasing OpenGL objects using OpenCL. We saw pretty early in development that the GTX 260 had better performance with the application than the GTX 570, even though the 570 has the edge when it comes to raw power. We can’t definitely prove it, but we hypothesize that the OpenCL drivers for the new high-end graphics cards might not be as optimized as those for the older ones. This is unfortunate as we want to max out on everything when we demonstrate what we can do.

Goal chaining, and optimizing.

This week I’ve implemented functions for pre-generating a flow field. It is very slow but it works. I also added some extra features to the map loading, so that you can mark out specific chokepoints the agents should know about. That is to ease up the preasure on A* calculations.

I myself and Simon also managed to remove unnecessary data transfers between the GRAM and RAM, by having OpenGL and OpenCL share memory where you update and store the agent orientations. Gustav helped us to set up the kernel so that the memory could be shared. So now we don’t need to update the orientations with OpenCL, write the data to RAM then save it to a texture which in turn is written to the GRAM again. That will save us some valuable time, however a bug appeared, and agents face the wrong direction in most cases.

You can also assign several goals to agents, which they will follow up in given order. However, goal chaining can not yet be done through real-time interaction. But adding the functionality should not be much of a hassle since the structure and logics are already finished, all you need is a user interface.

A heartbeat functionality has been written which can be used to update some states at set time intervals, instead of every frame – optimization.

Also, when a group needs to calculate a path, only the agent with most leadership within the group will do it and share the result with the rest of the group members.

We’re closing in on deadline and only a few more things remain. Hopefully those can be adressed and implemented/fixed tomorrow.

// Johan Forsell

Short update

This update will be a bit shorter than usual, a bigger one will be posted on Sunday.

The behaviors are starting to look pretty good, there are still a bit of adjustments to be done but its mostly small numerical changes. I have under the week been sitting mostly with making the agents act less as mindless idiots and more like actual human beings.

More info to come!

//Johan Österberg

UI coming to a close.

The user interface is almost finished. I have added a start menu of sorts that lets you enter various parameters before the simulation is started.  The general UI has gotten more stuff to enable further interactivity. There is not much left to implement, which is good since the project deadline is coming up.

Bullet has sprung a few more problems at me, but most of them are handled. One problem that remains is that Bullet does not inherently support spherical friction, but this will be solved by making the projectiles explode or some such. All in all, everything is looking as if it will come together nicely.

//Joel

Behavior week

This week has been a bit of a hassle, in the beginning of the week I implemented the behavior structure that I decided on last week. Then when I was done it wasn’t as good I thought it would be, so I changed the design. When the new design was done and implemented, it too wasn’t good enough. So I sat down again to really think it through and come up with a new design that would be what I wanted.

But that went very slow, so I decided to try and fix a memory leak connected to the OpenCL code instead. With a little help from Johan Forsell the leak was fixed yesterday around lunch. So after that I started with the behavior design again, with a slight morale boost after the leak fix the design work went by smooth.

The implementation on the other hand turned out to be a bit harder than what i had anticipated, but now it is place and a feel really good about this design so hopefully my colleagues will feel the same.

//Johan Österberg

Animation – OpenCL and LOD

This week I’ve been focusing on porting the skinning to OpenCL to avoid skinning in a shader. This has worked out pretty well, as we now can animate and skin the characters without any loss of performance. However, this performance increase raises a problem…

To get the skinned vertices to the graphics card, I have to save them in a texture. And textures have limited sizes. And I need a set of skinned vertices per skin and per animation. So one might be concerned with running out of memory, for obvious reasons. The simple solution is just to make the texture bigger, and that I can, but one might not want to constantly write to an image with the dimensions 4096 x 4096 pixels every frame, it’s costly. I’m going to have to investigate how many animations I can queue before I lose the performance I gained by using OpenCL.

Also, together with Simon I’ve now implemented skinned characters with LOD. This was fairly simple, as I only have to treat all levels of LOD as a single skin, and just simply pick what level of LOD I want to use, in the GLSL shader.

//Gustav Sterbrant

Animation – progress update

So I’ve been porting the skinning algorithm to OpenCL to avoid reskinning each and every character each frame. So instead I’m going to make it so that a single animated character is only skinned once, and then just moved for each instance. I’m going to use CL to GL interop in order to write the skinned characters calculated in CL to a texture in GL, and then per vertex just set each position. If this works out, I suggest the skinning won’t have a measure impact on the performance of the program.

I’ve had to make some basic mathematical functions for matrices and matrix-vector operations. Also, even though floatnxm is listed as a reserved OpenCL keyword, the compiler complains if one tries to use a float4x4. So I made my own matrix44 struct that contains an array of four float4 vectors. What I’m afraid of however, is that my code is as far from optimized as humanly possible. I’ve read some CL math implementations from Nvidia and AMD, and even downloaded the AMD APPML. To my disappointment, there are were no .cl files in the project, instead, there was just a .lib and a header file containing function calls to CL kernels. What I wanted is the math itself, so I’m going to stick to my own and get it working first, then think about optimizing it, if needed.

//Gustav Sterbrant

Behavior RnD

This week I have mostly read about different modern techniques of implementing AI behaviors. For the moment I only have my behavior structure on paper, I like to have a rough design of my code on a piece of paper, in this case many pieces of paper, before I start to implement it. This often leads to fewer troublesome surprises and strange bugs, so the implementing of the code will start sometime in the middle of next week.

I have also pushed some more code to the GPU, this time I chose to move the position updating functions from the CPU to the GPU. For the moment I only get a slight performance boost out of this, but I believe it to be greater in the future when a bunch of small quirks are present in the AI code.

//Johan Österberg

They behave…

This week most of my efforts have been put to make the agents act less aggressive on their way to reach a set goal.
They won’t push around eachother as much and they will stop when close enough to the goal point.

In addition to that I added so that the agent speed is directly linked with the crowd density, the more people in close proximity the slower they move.
The actual speed scaling might still need some polishing, but that’s nothing more than tweaking a math algorithm for the most realistic feedback.

And lastly, agents can now be assigned goal areas in addition to goal points. For now it’s only basic shapes but it shouldn’t take too long to make it work for any
concatinated area of shapes. The goal areas need some additional programming so that the agents change their behavior while inside their goal area.
That’s first out for next weeks work.

// Johan Forsell

Animation – optimization

After a weekend of relaxation I started working on some optimizations for the animation system. First of all, I made an animated version of tetrahedron man that we now use in the game. We can render 30 000 agents, with animations, rotations and positions, and AI at around 12 fps. The low FPS is mainly because of the skinning shader, which currently takes a lot of juice to render, so there are some optimizations to be done there. I managed to cut down the amount of memory fetching by changing from matrices to quaternions when passing the data to the GPU. This didn’t give a measurable performance increase however, but it does look neater with less pixel fetches in the shader. Also, I found that by checking whether a weight is zero or not could eliminate both unnecessary texture fetches, and matrix multiplications, increasing the FPS by quite a bit. I’ve also come up with another optimization technique I could use to speed up the skinning. One of the major problems with the shader is that it does so much per each vertex, but that isn’t necessarily needed. Seeing as the model actually renders the same vertex several times (one vertex can have more than one texture coordinate and normal), the exact same operations will be done on the very same vertex several times. So to fix this, I though of rendering the vertices separately, save their positions to a texture, and then when the actual rendering is active, just fetch each vertex positions from this texture.

I’ve also worked on the distribution system for the animations. One can now queue either one animation, or a combination of several and bind them to an AI, and that particular AI will move using that animation. I will also add a way to force animations to play using a new skeleton, so that one can choose if two persons should move with the exact same time step or not.

//Gustav Sterbrant