Physics

This represents the time spent on physics code. These days the BGE only uses Bullet for physics, so this stat mostly represents the time spent in Bullet. To reduce the time, you’ll need to simplify your physics so Bullet doesn’t have to do as much work. This can include using simpler physics shapes for objects. For example, if you have a complicated mesh for a character and you set the physics type to Convex Hull or Triangle Mesh (the default if no other bound type is explicitly set), Bullet has to do physics calculations with the complicated mesh, which is just a waste of time. Instead, try to see if something simpler like a sphere or box can do the trick. If not, at least setup a “proxy” by creating a simple version of your mesh that is invisible and is used for calculations instead of the complicated mesh that is used for rendering.

Logic

Time spent on logic is time that is spent on logic bricks and Python code (excluding code run through KX_Scene.pre_draw and KX_Scene.post_draw; those times show up under the Rasterizer). If you want to reduce this, you’ll need to simplify/optimize your logic bricks and Python code. I’m not going to give a tutorial on optimizing Python code, but this talk by Mike Fletcher (known for PyOpenGL) describes profiling Python code and some tips for optimizing. Remember, always profile your code before attempting to optimize it! As a last resort, you can also try moving some of your Python code to C/C++.

Animations

Under animations you have the time spent in Blender’s animation code, which the BGE makes use of. This includes things such as looking up pose data and interpolating key frames. However, be warned that sometimes things like calculating IK can show up under the scenegraph when calculating bone parents. Also, this category does not include the time spent to do the actual mesh deformation, this time is recorded under the Rasterizer category. To reduce the time spent on animation try to reduce the bone count in your armatures. You can also try switching your armatures over to iTaSC (set to simulation) for IK solving instead of the Legacy solver. iTaSC can be faster than the Legacy solver. In my tests I’ve seen 1.25~1.5x speed improvements when using iTaSC, but I’ve heard that 4x is not unreasonable.

Network

This might come as a surprise to some, but the BGE actually has some networking code. However, this feature was never really developed, so now it is mostly a stub that can send messages over a loopback interface. This is how Message actuators and sensors (and the corresponding Python API features) work. It’s doubtful that this category will ever be a time sink, but if you’re having problems, take a look at the number of messages you’re sending and see if you can reduce them.

Scenegraph

The scenegraph keeps track of objects’ position, orientation and scale (and probably a few other things I’m not thinking of at the moment). This also includes updating parent-child relation ships (e.g., bone parents). As mentioned earlier, the time for bone parents can include getting updated pose data, which possibly means calculating IK. If the scenegraph is really high, try reducing the number of objects in your scene. You can also try using iTaSC (mentioned under Animations). The scenegraph also handles culling (frustum and occlusion) calculations.

Rasterizer

The rasterizer is responsible for actually rendering the game. This includes rendering geometry, shaders, and 2D filters. Since the BGE makes use of double buffering, the rasterizer also has to swap the buffers, which can give really high readings if vsync is enabled (SwapBuffers() blocks while waiting for a screen refresh). To reduce the time spent in the rasterizer, you can try to simplify your geometry and materials. Also make sure you don’t have too many lights casting dynamic shadows. Each shadow cast requires the scene to be rendered. So, if you have three spot lights casting shadows, the scene is rendered four times (three for shadows and once for the actual scene)! 2D filters can also suck up some time, so even if that bloom, depth of field and SSAO look nice, you might want to consider removing them or trying to reduce the number of samples they use.

Services

This is the time spent processing various system devices (keyboard, mouse, etc). You shouldn’t have a problem with this category taking up time.

Overhead

This is probably one of the most mis-leading category names. The “overhead” is all the text drawn on top of the game screen in the top left corner. This includes the framerate, profile, and debug properties. So, the time spent on this category should be reclaimed when running your game in a more “release” configuration (i.e., you’re not drawing all that debug/profiling text to the screen). If you want to reduce the time spent here while profiling, try reducing the number of debug properties you display.

Outside

This is time spent outside of the BGE’s main loop. In other words, something is taking time away from the BGE. You really have no control over this area. If you have a lot of other programs running, you can try to close some.

I hope people find this useful.

Cheers,
Moguri

You can grab the new version from here.

Requirements:

• Blender 2.5+ (2.61 is fine)

There is also a Getting Started guide in the wiki.

Cheers,
Moguri

class ImageButton(Widget):
	"""A clickable image-based button."""

	theme_section = 'ImageButton'
	theme_options = {'DefaultImage': (None, 0, 0, 1, 1),
					 'Default2Image': (None, 0, 0, 1, 1),
					 'HoverImage': (None, 0, 0, 1, 1),
					 'ClickImage': (None, 0, 0, 1, 1)
					 }

	def __init__(self, parent, name, default_image=None, default2_image=None, hover_image=None,
					click_image=None, aspect=None, size=[1,1], pos=[0,0], sub_theme='',
					options=BGUI_DEFAULT):
		"""
		:param parent: the widget's parent
		:param name: the name of the widget
		:param default_image: list containing image data for the default state ('image', xcoord, ycoord, xsize, ysize)
		:param default2_image: list containing image data for a second default state, which is used for toggling ('image', xcoord, ycoord, xsize, ysize)
		:param hover_image: list containing image data for the hover state ('image', xcoord, ycoord, xsize, ysize)
		:param click_image: list containing image data for the click state ('image', xcoord, ycoord, xsize, ysize)
		:param aspect: constrain the widget size to a specified aspect ratio
		:param size: a tuple containing the width and height
		:param pos: a tuple containing the x and y position
		:param sub_theme: name of a sub_theme defined in the theme file (similar to CSS classes)
		:param options: various other options
		"""

And here is an example of how to use the new class:

self.audio_button = bgui.ImageButton(self.win, 'ab', sub_theme='Audio',
								size=[0.05, 0.05], pos=[0.75, 0.05])

And the relevant theme data:

[ImageButton:Audio]
DefaultImage=img:audio.png, 0, 0, 0.5, 1
Default2Image=img:audio.png, 0.5, 0, 0.5, 1

Now time for some questions. First off, the theme file is formated as img:filename, x, y, height, width. Should this instead be img:filename, x1, y1, x2, y2? If I changed this, I would also change the *_image arguments in the constructor. Also, should some sort of mechanism be added for user defined states? Currently things are kind of limited, but I’d think users could subclass if they wanted more flexibility. Any other feedback?

Cheers,
Moguri

What did you do this week?

I have written a migration guide, which can be found here. If I find more items that require user action, then I’ll make sure to note them there. The guide can also be moved eventually.

Per user request, I’ve increased the max number of layers from 4 to 8. I have also fixed an issue where the user could attempt to use layer n+1, where n is the max number of layers. This of course caused a crash and has now been fixed.

I have also changed lamp and camera IPOs so that lamps and cameras are not stuck to only their active action. The Blender UI seems to be a little restrictive in this area and doesn’t seem to allow multiple actions for lamps or cameras. But, if you have two lamps with actions, either of the actions can be used on either of the lamps.

What do you plan to do next week?
Next week I plan to start figuring out what I need to do to merge my changes into trunk.

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

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

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

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

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

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

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