Latest Entries »

Status report time!

What did you do this week?

This week I worked to make sure actions behaved more like trunk. This involved fixing some blendin and yet more continuous problems. I’ve also added an option so users can choose whether or not they want to lock the animation updates to the animation framerate:

Adding an option to let users choose whether or not to lock animation updates to the framerate. If this option is enabled, animations are only updated at the same speed as the animation framerate. This can give a significant speed up in performance, but at the cost of smoothness in animations. I’m defaulting this behavior to off for now, which is the behavior seen in trunk.

Also, when the user does choose to restrict the update calls, the framerate should now do a better job of matching the user selected framerate:

Animation updates are now handled separately from logic/physics updates. This allows the animations to be updated at the full fps specified by the user. Before, updates were not happening frequently enough. For example, a 30fps animation may only update at 20~30fps, which would cause some noticeable lag. This my not be the best solution since at this point we may be dropping frames (not being in the while(frames) loop), and we’re not updating as often as the physics engine might want for bone parented physics objects.

If the user doesn’t choose the new restrict animation updates option, then the animation updates are still done with the logic/physics updates (the option was created after this commit).

On Wednesday, Dalai and I decided it was probably best to drop the bone physics. This was “extra” anyways, and I was spending a lot of time trying to get the position of the physics shapes right. So, I’ve been focusing on fixing compatibility issues instead. For anyone interested in the work I had done for bone physics can find a patch here (warning: I did not bother to cleanup the patch).

What do you plan to do next week?
Next week I’ll continue to work on reported user issues (there are still some issues with blendin). Also, it’s come to my attention that lamp, world, material and camera IPOs probably are not working correctly, so I’ll look into making sure those are still working. I’ll also write some docs such as a migration guide.

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!

Cheers,
Moguri

Status report time!

What did you do this week?

The current method of recalculating normals after deforming verts for skinning would have been difficult to implement on the GPU, so I wrote a new one as described in my commit:

BGEDeformVerts() now handles normals instead of relying on BL_MeshDeformer::RecalcNormals(), which BlenderDeformVerts() still uses. As expected, the BGEDeformVerts() version isn’t as accurate, but it avoids a sqrt per vertex. This gives about a 15~20% improvement in time spent on the rasterizer in my test scene, which resulted in about 5 more fps. However, the main reason for the new normal code is it will be easier to do on the GPU (doesn’t rely on neighbor information).

I have also been working on fixing issues reported by users: ping pong animations now better match trunk, and I’ve fixed a potential crash when loading older files. There are also some issues with blendin that I still need to fix.

As far as bone physics goes (what I said I’d work on this week), I have a UI option to enable and disable physics on bones (only shows up when the Blender Game render engine is selected). Also, at conversion time, I’ve managed to make capsule physics shapes for all of the bones on an armature and setup bone parents for the shapes. However, some of my math must be off since the physics shapes aren’t quit matching up with the bones yet. I haven’t committed any of the bone physics code since it’s not yet at a usable stage.

What do you plan to do next week?
Next week I’ll continue to work on bone physics and fixing reported issues.

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!

Cheers,
Moguri

Status report time!

What did you do this week?
I’ve added a Game Engine only option to armatures to choose a “Vertex Deformer.” Here is the message from the commit:

Adding a new choice for vertex deformation for armatures, which can be found in the Armature’s Skeleton panel by the Deform options. Before only Blender’s armature_deform_verts() was used. Now users can choose a vertex deformation function that is optimized for the BGE. At the moment it is mostly a copy of armature_deform_verts() with various chunks of code removed, and the BLI_math code was replaced with Eigen2. In my test scene, the new function offered about a 40% improvement over armature_deform_verts() (17~19ms rasterizer to 11~12ms). The only current limitation that I’m aware of is that B-Bone segments are not supported in the BGE version, and I will probably leave it out. I would like to also limit the BGE version to 4 weights to make things easier for a GPU version, but this may just make things slower (sorting weights to find the top 4).

What do you plan to do next week?
I’m done optimizing for the time being (although I might play a bit with the RNA caching again). I’ve talked with Benoit, and I’m going to work on some physics with armatures. The plan is to add options to give bones physics shapes and automatic constraints. This will make setting up things like ragdolls easier.

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!

Cheers,
Moguri

Status report time!

What did you do this week?

This week I was (and still am) on vacation. This means I didn’t get a lot of GSoC done. I got external targets working for the Copy Transform constraint, and I fixed a crash with non-shape actions on objects with modifiers. I have looked into hardware skinning and, while they would most likely help, I don’t know if we want to be pushing more onto the GPU at the moment. We are currently severely under utilizing modern processors (multiple cores) since the BGE is single threaded. This also means that (when vsync is enabled) we have to wait on screen refreshes to continue running code. So, if more is done on the GPU and now we just barely miss a refresh, we have to wait until the next screen refresh. This leads to a lot of wasted time.

What do you plan to do next week?

I’ll be back home late on the 28th of July, which doesn’t leave me much time until the next report. However, I’ll continue to work on much the same stuff: cleaning, documenting, optimizing. I’ll talk with one of my mentors to see what to do about hardware skinning.

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!

Cheers,
Moguri

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!

Cheers,
Moguri

Status report time!

What did you do this week?

This week I cleaned up the code and added some comments. I also updated the docs to reflect the changes to KX_GameObject. I’ve added preliminary support for using layers with shape actions. Shape actions in general seem to still be a little weird with blending. I’m not entirely sure if it’s my code, or existing oddities, so I’ll need to run some more tests there. I’ve also fixed various bugs related to compatibility with older files (making sure they work the same). From what I can tell, most things are working the same, except my action actuator behaves a bit differently when it comes to pulses (my actuator only tries to play an action on a positive pulse while the old actuator kept trying to play an action from when it got a positive pulse until it got a negative pulse). I have also started a thread on Blenderartists to start getting some feedback, but I haven’t gotten a lot of responses.

What do you plan to do next week?

Next week I will work on optimizing animations. Animations in the BGE are fairly well known for being slow. Hopefully I can find some areas where I can speed things up. I’ll also continue to make my code more “trunk-worthy.”

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 (Win32, Win64, Linux 32, Linux 64, and OS X 32):

http://graphicall.org/?keywords=pepper

Thank you to everyone providing builds!

Cheers,
Moguri

Status report time!

What did you do this week?

This week I got layered animations working  for armature actions. Both adding and blending are supported. I dropped the idea of different blend modes and instead went for a single layer blending value. If this is 0, then it will just be an add instead of a blend. Shape actions currently don’t support layers, but blendin is now supported on shape actions again. I have also fixed shape key drivers, a frame property bug, and a priority bug with continuous actions.

What do you plan to do next week?

I still need to talk to my mentor about a new timeline. For now, I plan to add support for shape action layers and doing some bug fixing. I’ll start a thread on Blenderartists to encourage some users to try using Pepper for their BGE animations and see if they encounter problems. The idea is to not break anyone’s existing animation or logic setups.

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

I will need to talk to my mentor so that I can create a better timeline for the remainder of the project. Other than that, things are going well.

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 (Win32, Win64, Linux 32, Linux 64, and OS X 32):

http://graphicall.org/?keywords=pepper

Thank you to everyone providing builds!

Cheers,
Moguri

Status report time!

What did you do this week?

I got shape keys working again in the test file I had. I think drivers might still be broken, so I’ll have to run more test files. After getting the Shape Action actuator working, I added shape actions to BL_Action and added some do_versions() code to convert Shape Action actuators to Action actuators. I have also added priority options to BL_Actions and exposed KX_GameObject’s SetActionFrame() and GetActionFrame() to Python.

What do you plan to do next week?

I’m not entirely certain on what I will do next week. My plan for now is to tackle layer blending. However, I also plan to talk to my mentor about my timeline, so I may switch to other things (like bug fixing that can be merged into trunk).

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

Nope, things are going fine.

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 (Win32, Win64, Linux 32, Linux 64, and OS X 32):

http://graphicall.org/?keywords=pepper

Thank you to everyone providing builds!

Cheers,
Moguri

Bgui 0.06 Released

It’s been awhile since the last Bgui release, so here’s another one. This one doesn’t contain a whole lot of major changes. However, I wanted to do a release before making some bigger changes.

You can view the changelog here.

You can grab the new version from here.

Requirements:

  • Blender 2.5 (2.57 is fine)

There is also a Getting Started guide in the wiki.

Cheers,
Moguri

Status report time!

What did you do this week?

This week I’ve added the IPO options to BL_Action, et al. and the Action Actuator. This allowed me to finally drop F-Curve Actuators, which are now converted to Action Actuators in Pepper. Also, new F-Curve Actuators cannot be created in Pepper. I have also begun to poke around at shape keys, but there is nothing much to report on that front yet.

What do you plan to do next week?

Next week I plan to integrate shape actions into the new system and to drop the Shape Action Actuator. By the end of next week, I plan to be done unifying the animation logic bricks, and there should be one animation actuator to rule them all.

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

I would have like to have the shape actions done by now, but things are still going fine.

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 branches. At the time of writing this post there are currently four Pepper builds on Graphicall (Win32, Win64, Linux 32, and Linux 64):

http://graphicall.org/?keywords=pepper

Thank you tungerz, Demohero and Fish for providing builds!

Cheers,
Moguri