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.

Archive for February, 2011

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

A fun feature

Came up with a fun idea, for something you can use your agents for.
Graphical artists will no longer be needed, since our AI can do their entire work in much less time.
Just tell the agents that you want a picture of something and, voila! There it is…

Or maybe, it just shows us how much you really need those CG guys after all…

// Johan Forsell

A week of OpenCL and problems

This week was supposed to be about implementing the intelligence, but that did not happen. Instead the week became about implementing two more algorithms on the GPU. These two rather simple steering behaviors, Flee and Cohesion, that from start seemed to be an afternoons work turned out to keep me occupied the whole week. The implementation of the flee algorithm actually went pretty smooth, I just had to add one more cl::Buffer, but the cohesion needed three more cl::Buffers.

Thats when all hell broke loose, then after adding the three cl::Buffers and writing the OpenCL code I started having “random”, or so it seemed at the moment, crashes. After spending a whole day testing separate bits of the CL code I still couldn’t understand what was wrong, mostly because I didn’t get any debug information more than “Your program has stopped working”. After another day of frustrating debugging I found that one of the cl::Buffers was created with an array that was allocated but not initialized.

After this was fixed I had some problem with the AI not behaving as it should, this on the other hand was easy to fix, the problem was some minor mathematical errors.

So the week has been a real pain, but now all the steering behaviors, that we will need for this simulation, is implemented and running correctly on the GPU. This means that next week will actually be about giving the AI intelligence, which is the fun part.

//Johan Österberg

AI Progress

Things are getting along pretty well. I’ve added the ability to load images as discomfort fields allowing for quick map setups, having a threshold value for solid objects where agents will never be able to walk. Basic group behaviors are implemented, however it still lacks the high level control we’d like to have. That will be the goal for next week.

Yesterday I managed to enable a forced non-overlapping feature, earlier, a large group of agents pressing towards the same goal would after some time start to overlap and the crowd compression rate would be too high. For this I’m using a simple constraint method, simply setting the agents who overlaps with another agent position to the nearest position that does not result in an overlap. In theory they still can stand on eachother when part of a large group and it happens all the time, but it is hardly noticeable and in this project it is the visual aspect that matters the most. The method adds very little weight to the already implemented algorithm since the distance to agents within the separation radius is already known, for those overlapping we move them apart by -(agentRadius-agentDistance)*normalizedAgentDiffVector.

New York Streets

What’s next is having the agents stop the staggering effect when in a dense crowd where in reality most peolpe would stand still when there’s no room for further advance. Right now the crowd acts more like an enraged mob where everyone lacks any feelings of empathy and thinks only about themselves trying to reach a set goal. Other than that a smoother turning rate for our tetrahedron-man agents is also on the list for todays implementations.

Not to forget, we witnessed a rather cool effect resembling a fluid simulation when agents max speed were set to high values, resulting in vicious vortices. Our efforts not only seem to result in a greater knowledge base but also in abstract live art, beautiful… :)

Fluid simulation?

// Johan Forsell

Animation – skinning

I’m very happy to say, that I’ve finally got the skinning working! This results in an animated Seymour (as previously used), where the entire skinning process takes place on the GPU. Despite it working though, there seems to be a problem with performance. Since I wanted to get it working, I haven’t really focused on getting it fast, so there’s a lot of work to be done there. An example would be that the shader now makes 37 texture fetches per VERTEX, which is a lot! Loads of these values are constants, so I might as well send them as attributes instead. Also, the matrices, they are stored as pixels, where each matrix is stored as 3 pixels. This results in 3 * 8 (maximum of 4 influences per vertex) texture fetches for each vertex. I got a tip that one could use quaternions instead, resulting in less texture fetches, which is awesome! I also have to work on a distribution system, so I don’t need a separately animated skeleton per agent. I bet you want some kind of proof of what I’ve accomplished, well, you’re in luck! There’s a video!


Bullet, more entity handling and UI struggling.

This last week I have successfully integrated the Bullet Physics Simulation system with our application. The entity manager can create a rigid body, insert it into the dynamicsWorld and the simulation takes over from there.  They’re not rendered yet, but that is coming along as well. The entity manager has also been extended to alllow for the selection of multiple agents at the same time. This allows for attribute changes to be applied to several agents at once, which is useful for testing and observations.

I’ve been scouring the web for a way to make the window decorations show on my embedded widgets, but alas, nothing helps. It seems like it might be a bug in Windows 7, but there are not enough people with the same problem for me to be able to corroborate that. Also, all the examples I’ve tried have showed the decorations, which only heightens my confusion. I will continue trying to pass window flags with appropriate names, but I don’t think that’s the problem.

Anyway, the project’s making headway and we’re all having fun. It’s impressive how much juice you can squeeze out of the circuits if you just try. :)

// Joel

Pushing the AI to the GPU

The conversion from fixed-point to floating-point math is now done, and Johan Forsell has optimized the AI code.

After fixing some bugs we tried simulating 8000 agents, now using floating-point. The simulation ran with 60 fps like before. So we did a rather optimistic test with 50.000 agents expecting zero to one fps, but to our surprise we had 30 fps. We continued for a while just amping up the number of agents, when we reached a million agents without the program crashing we were very satisfied. The simulation with one million agents only had 2 fps, but we were still a bit amazed that the memory didn’t run out.

Next week we are going to start adding the intelligence, I am in charge of single agent behaviors and Forsell is in charge of group behaviors.

//Johan Österberg