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 March, 2011

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.


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