Latest Entries »

What did you do this week?

I’m still awaiting more feedback on the LibLoad thread to figure out which direction I want to go on the interface to asynchronous LibLoad (callback or future object).

I did manage to get some speed ups in the converter for loading non-power-of-two textures by avoiding scaling the textures to powers of two if the hardware has NPOT support. Non-power-of-two textures took about four times as long to load than power-of-two textures, now the times are about equal. However, I haven’t yet committed the change since I haven’t decided if I want to put it in trunk or Swiss.

As for the tracker, with some help from Daniel, I managed to get all of the open bugs organized into the new categories. In the process, I also managed to close 18 bugs this week. One that might be of interest to people is:

[#23375] texture2D in custom 2D filters can get texture outside of game, resulting in ugliness

Essentially, this means you won’t be grabbing the Blender UI in 2D filters anymore.

Tracker stats:

New: 2
Closed: 18 (18 by me)
Net Change: -16
Current: 162

12 more to go until we’re back down to three pages!

What do you plan to do next week?
I would like to get down to three pages in the tracker, which will require me closing 12 more reports. I will also come to a decision this week on how I want async LibLoad to look and implement it.

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

Nope, things are starting to go smoothly.

Are there any builds available?

There are some on GraphicAll.

Cheers,
Moguri

Advertisements

What did you do this week?

I finally got some time to dig into the converter code, and I managed to get around a 35% speed improvement on scenes with lots of polygons. Here is the commit log:

Some refactoring of the Mesh conversion code to make things easier to read. Material conversions are now also cached so they do not have to be redone per face. This results in about a 35% improvement in conversion time in scenes with a lot of faces. I’m keeping the old mesh conversion code around as BL_ConvertMesh_old() for further benchmarking/comparisons. It will need to be removed prior to being merged into trunk.

As for the tracker:
[#28842] Ping Pong mode not working well in 2.60 + backcomp. problem (Fixed)
[#30410] not full conversion IPO Actuator in Action Actuator (Closed)
[#28831] Hitting P key to start GameEngine can crash blender (Not closed by me, but my prompting lead to it being closed)
[#31396] bge.logic.LibLoad fails to import text blocks (Fixed)
[#31792] Character Physics type not detected by near sensor (Fixed)
[#29037] logicbrick relation-lines dont get highlighted on mouseover (Closed/Already Fixed)
[#30726] Runtime memory leak (Rejected)
[#30558] bge.texture doesn’t work (no errors caught) (Closed/Already Fixed)

Tracker stats:
New: 2
Closed: 8 (7.5 by me)
Net Change: -6
Current: 178

What do you plan to do next week?
Based on the discussion of this BlenderArtists thread, I’d like to get the interface to the async LibLoading to work better. I also talked with Dalai, and we agreed that the BGE tracker could use new categories. I will get a list of potential new categories to the mailing list and work with Nathan to get the new categories in place. Then I’ll go through the tracker and get each bug into it’s appropriate category.

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

Nope, things are starting to go smoothly now.

Are there any builds available?

There are some on GraphicAll.

Cheers,
Moguri

What did you do this week?

More of my time got eaten up this week than I had expected. As a result, I wasn’t able to get a large enough chunk of time to dig into the converter code. However, with what bits of time I did have, I continued to poke around in the tracker. I managed to close the following bugs:

  • [#30888] animation blending problem (Rejected/Possible Duplicate)
  • [#31813] bge.types.KX_RadarSensor incorrect attributes (Fixed)
  • [#31276] Action Actuator, Priorities higher than 1 break Playback (Fixed)
  • [#31468] Game Physics incorrect on Motion Rotation (Duplicate/Alread Fixed)
  • [#27472] preserve volume for armature modifier does not work (Fix with code found in the report)
  • [#31671] Keyboard Sensor blocks Quit Game Key Binding (Fixed with a patch from Jay Parker)

I also have a new fix for the issue involving LibLoad and text datablocks. I think it is a lot cleaner than my previous attempt, and I’m currently waiting on review/confirmation from Campbell before committing it.

Tracker stats:
New: 12
Closed: 7 (6 by me)
Net Change: +5
Current: 184

What do you plan to do next week?
I’ve wrapped up all my school obligations and the other stuff that was taking up my time. Therefor I will  be in the clear next week to do some serious catch-up work. I’ll try again to play with some converter optimizations I have in mind. I’ll probably also have the LibLoading text blocks bug resolved by my next report. There is a problem with pulse mode on the Action Actuator that seems to be generating a lot of bug reports, so I’d also like to get that fixed next week as well.

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

I cannot build Swiss at the moment, but I’ll talk to the other members of Swiss in the next couple of days to get that sorted out.

Are there any builds available?

There are some on GraphicAll.

Cheers,
Moguri

What did you do this week?

Well, I did some bug fixing, but I didn’t get any of the animation ones solved this week. When doing some debugging I stumbled across some heap corruption issues due to SDNA issues with the Blenderplayer. That has now been fixed, but it took some time to track down. I have also fixed a bug that was causing textures to get uploaded to the graphics card twice, which caused the VRAM usage to almost  double. I also have an uncommitted fix for LibLoad not loading text datablocks. However, I wold still like to find a way that doesn’t involve editing Blender data (right now the loaded text datablocks are temporarily loaded into Main and then removed at exit).

Tracker stats:
New: 4
Closed: 1 (0 by me)
Net Change: +3
Current: 179

What do you plan to do next week?
Next week I’ll have some more time, so I’d like to work on a bigger issue: per material versus per face conversion. I’ve got some ideas for this and I’d like to sit down and try them out. My plan is to get some speedups by not converting materials per face.  Hopefully I can also get the bug tracker down some more too.

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

Now that schools is just about wrapped up (I have some stuff to do for finals next week, but not much), I should be able to put more effort into GSoC.

Are there any builds available?

There are some on GraphicAll.

Cheers,
Moguri

 

What did you do this week?

This week I poked around at some more bugs. I fixed a “bug” where Preserve Volume on the actuator modifier wasn’t working in the game engine. I think I managed to close at least on other, but I am currently unable to access projects.blender.org to get exact numbers. I have also figured out the problem to [#31396]  “bge.logic.LibLoad fails to import text blocks.” However, there are still some memory leaking issues that I need to address before committing the fix; I hope to have this committed by tomorrow evening.

I also committed, to Swiss, a Cucumber patch from Daniel Stokes (Kupoman) to add VBO and multiple UV layers to the BGE. This will help to avoid potential merge issues later if Alexandr or Jason go playing in the BGE’s rasterizer code since the patch did some major refactoring of some parts of the rasterizer. Also, I worked off of the multiple UV layers code to start cleaning up the mesh conversion code. Here is my commit log message from the corresponding commit:

Changing the mesh converter to stop using BL_Material as a temporary place holder for rgb and uv data. This is the first step in getting rid of per face material conversions, which are taking up a lot of time.

What do you plan to do next week?
Next week Dalai said I should try to tackle some of the animation bugs, and I’d like to get at least a couple closed next week. Also, I would like to try and find time to try out some ideas for refactoring the mesh conversion to get rid of per face material conversions.

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

Things (mostly school) kept me more occupied this week than I would have liked. However, next week is the last week of instruction, so I should be able to really focus on GSoC after that.

Are there any builds available?

Nope, not yet.

Cheers,
Moguri

It’s once again time for Google Summer of Code status reports.

What did you do this week?

This week I got started on asynchronous library loading. Here is the message from the commit log:

Adding the start to an async option for bge.logic.LibLoad(). The basic threading works, but there are still some issues that need to be addressed:
* Memory leaks when canceling a thread. I’ll try to fix these with more cleanup callbacks like the one used in async_convert().
* The user has no way of knowing when an asset has been loaded. I’m thinking some sort of Future object would work here.
* Only works for scenes. It will be simple to support Mesh and Action as well, but I want to do it in a such a way as to minimize code duplication.

I’ve also done some digging through the BGE tracker to get an idea of where we stand. Over the past week or so the bug tracker has gone from about 184 bugs to 179 bugs. One bug I actually fixed, the rest where just bug reports for issues that have since been fixed. I also fixed an animation bug, but I have yet to close the report since the user has found more issues (I’m tempted to just have the user make a new report for recording purposes).

What do you plan to do next week?
Next week I’d like to work more on library loading. This means addressing at least some of the issues mentioned in the log message and tackling some LibLoad bugs. I will also be adding more bugs to my task list.

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

I still have class for the next few weeks, so things will go a little slow until then.

Are there any builds available?

Nope, not yet.

Cheers,
Moguri

BGE Profile Stats and What They Mean

Many people are familiar with the “Show Framerate and Profile” option in the BGE and the mess of text it displays on their screen. However, not as many people truly know what the different statistics mean. This article aims to help improve people’s understanding of the profile stats and how to change your game to get those numbers down (less time spent is better for performance). Aside from the FPS, the profile shows nine stats: Physics, Logic, Animations (only in newer versions of Blender), Network, Scenegraph, Rasterizer, Services, Overhead, Outside, GPU Latency (only in newer versions of Blender). To get the most accurate readings, I recommend turning off “Use Frame Rate” and using your graphics card drivers (or the UI option in the render properties on newer versions of Blender) to force vsync off.

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). This time is now represented in the GPU Latency category. To reduce the time spent in the rasterizer (or the GPU latency), 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.

GPU Latency

This category is new to r59097, and will be in Blender 2.69. This category represents the time spent waiting on the GPU. This category used to be entirely within the Rasterizer category, so the same tips from there apply to this category. However, time spent waiting for vsync will show up here now instead of in the Rasterizer category. Also, this category is a bit different from other categories in that it is idle time (the CPU is just waiting on the GPU). This means this is time that can be used by the CPU (e.g., physics, animations, logic, etc.) without affecting the framerate. This also means that if the GPU Latency is high, trying to optimize CPU time is pointless as it will, also, not affect the framerate. If this value is low, it is still possible to be GPU bound. Various OpenGL calls (usually some form of glGet) can cause a sync event in which the CPU has to wait on the GPU.  These sync events can cause odd profiler readings depending on which part of the codebase they occur in. For example, if overhead is suddenly taking up a large amount of time, odds are that the font rendering triggered a sync.

I hope people find this useful.

Cheers,
Moguri

Bgui 0.07 Released

A new version of Bgui is way overdue, so here it is. Bgui 0.07 brings quite a few changes including ImageButtons and memory leak fixes. It will also work for newer versions of Blender (such as 2.61). For more details on the changes, take a look at the changelog.

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

Bgui ImageButtons: Request for Comments

I currently have ImageButtons implemented in my working copy, but I would like to get some feedback on some details. Here is the constructor and theme options for the new class:

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

Time for my final status report for GSoC 2011!

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