Status report time!

What did you do this week?

This week I worked on optimizations. I tried a few different things, but I only ended up committing one. This optimization involved moving the animation update out of the logic update and putting it in KX_KetsjiEngine::NextFrame() (which now also calls the new KX_Scene::UpdateAnimations()). This allowed me to have better control over how often animations were updated. From here, I only updated animations based on the animation fps setting; if animations only playback at 30fps, then there is no need to update them at 60fps. The defaults have animation playback at 30fps and the logic at 60fps. So, with this default setup, the optimization cuts time spent on animations (keyframes, interpolation, etc; not deformation) in half, which yields about a 100~150% increase in fps. To better monitor animations, I’ve added a new category to the profiler: Animations. This records the time spent in Blender’s animation system, but not the time spent in the rasterizer due to deforming the mesh. I would like to have this time recorded under animations, but there doesn’t seem to be a clean way to do this at the moment.

There are also a couple of things that I ultimately dropped: caching RNA lookups and threading. I had created a hash table to reduce the time spent on RNA lookups in Blender’s animation system. However, with my test with aboutĀ  7 armatures with almost 70 bones a piece resulted in well over a thousand cache entries and used an additional ~20MB of RAM. I saw around a ~20% fps improvement. I didn’t think this was worth it, especially after implementing the earlier mentioned optimization. However, I may look at this some more in the future.

I took a look at putting the animation update in it’s own thread. However, due to timing issues, I would only be able to put the physics in parallel with the animation, which would only help some cases, and I was looking for more general speed ups. If I wasn’t as strict on timing (animations may be a frame off of rendering and other things), then threading may be more helpful.

I didn’t look at hardware skinning much this week since my initial profiling results showed my test scene spending half of it’s time in Blender’s animation system, so the mesh deformation wasn’t the slowest thing. In my current test scene (19 armatures each with 69 bones with and a 4751 face mesh) I get around 5ms on animation and 17ms on the rasterizer with an fps of around 45. With vsync enabled, I get into the 30ms range on the rasterizer and closer to 25fps. So, now hardware skinning might be a good idea.

For those interested in my test scene, you can find it here. This file works in both trunk and Pepper.

What do you plan to do next week?

Next week I will be on vacation (this was mentioned in my proposal). I will be gone for around a week and a half. However, I’ll have my laptop with me and I’ll try to get some work done. I’ll focus on optimizing (probably try hardware skinning) and getting things more “trunk-worthy”. This includes documentation, cleaning up code, etc.

Are there any problems that will require extra attention and what impact will they have on your proposed schedule?

There are currently no problems.

Are there any builds available?

One of the nice things about working with others in the same branch is that there is more interest for that branch, and you can find plenty of Pepper builds on Graphicall.

Thank you to everyone providing builds!