Hey. Moguri recently made a commit that adds multithreading for playing back armature animations. Hurrah! Grab a build from the buildbot or build from source and check one of your armature playback-heavy games to see how it’s working. Report back with your findings if you so wish.
Yaaaaaaaay!
Personally, I’m not sure if this deals with the conversion process when ‘P’ is pressed or it’s actually multithreading the action actuator for much faster playing.
I await seeing just whether it is the former or the latter.
And is it gpu, or cpu powered?
Really nice feature. Now just the build bot to do its duty!
So, what does the “Multi-threading animation updates and skinning” means for the bge = that we can have more characters with lots of bones and ik on screen?
this IS hardware armature skinning, however, is it handled by the cpu or GPU?
Don’t try to benchmark your scenes yet, me and Mahalin just found a couple of bad regressions including a crasher. This is to be expected when big changes are made and the release Cycle is still on Bcon1 so no need to panic.
(though there’s a build by Tungerz on Graphicall that has this change so if you want to inform Moguri of any more possible bugs, feel free to try it).
Moguri just fixed the regression that I found and reported as a comment to his commit on the developer site.
http://lists.blender.org/pipermail/bf-blender-cvs/2014-April/063229.html
I also needed a followup since it exposed other flaws in how the BGE handled animations.
http://lists.blender.org/pipermail/bf-blender-cvs/2014-April/063230.html
Reading the jargon used, it really does seem like the animation system in the BGE is now multithreaded, which means that Moguri just went a long way to resolve one of the biggest headache among BGE users working on big projects.
<----Wonders if Jig dancing is in order yet?
Tested a resource .blend by someone else who simulated ocean waves by using a armature with over two dozen bones in the April 8 buildbot build.
The time required by the Rasterizer in that scene went from 0.33 to 0.22 milliseconds (but it contains just one animated object so I’ll have to test with more objects).
The multi-threading is based on objects. In other words, pose updates for objects are run in parallel as are skinning updates for objects. So, one large skinned mesh isn’t going to benefit much from this update, but a scene with many skinned meshes will.
So pardon my ignorance but I don’t have much experience with the buildbot. Is the fixed version of this included in the current download (blender-2.70-9b60174-win64.zip) ? And is there a way to check that it is included?
(Til now I’ve only used stable builds but i REALLY want to test this new feature.) Thanks!
1. We have a scene with multiple actors @ the beginning of the game fleeing for there lives, this is a HUGE + for us.
2. Also what if a armature is based on objects positions?
3. Is it possible to use a rigid body as a armature bone somehow?
as I don’t really need IK solvers as the rigid body skeleton is already calculated…
Actor Rig =
Animated armature’s bones are used to manipulate a Rigid body riggdoll, and then I have a armature using the riggdoll as IK targets to drive my GFX mesh.
My videos are Creative commons btw.
I just tested with a homemade bench file (192 rectangular solids with 11 bones doing crunches) and the Rasterizer time nosedived from 22 milliseconds to 4 milliseconds (an improvement of nearly 6x).
I agree with BPR that this is a huge deal for BGE users (one of the number one reasons that a BGE project gets canceled or moved to another engine was slow animation). You’re still not going to get the massive animation seen in the Total War series, but any animation you see in a Unity or mobile game should now be doable.
That was with an i7 processor (quad core hyperthreaded).
I’m not entirely sure just how much of the CPU is being used since the fan usually turns up at full load.
Ive been testing this patch and Ive sadly been getting worse performance on a single animated mesh. 2.7 official gives me around about 76 frames where as after this patch goes down to 69 ish frames on one animated mesh. Its quite high in polycount to stress test with, 72k with about 70 bones but none the less shouldn’t go down in frame-rate from 2.7.
Is this just expected multi-threading behavior? as it seems to scale slightly better when you have multiple animated meshes, nothing like 4 times the speed with my 3570k quad however.
It seemed with 4 of the same animated mesh dropped the frame-rate down to 24 in 2.7 but down to 27 with this patch. Profiling the 4 cpu’s showed a slightly more leveled out workload but still quite centric on one core. Removing the 4 armature modifiers brought the frame-rate up to 180 if you were wondering if it was the rasterizer taking the hit
Also wasn’t the game engine standard gpu skinning a part of this project?
Just to add also, there’s a crash if you play an animation on the camera. Be it with the action actuator or using the python api, blender just instantly crashes on game start. Empites and object animations seem fine however.
This is great news for all BGE users! Would you mind if I asked how many hours you spent getting this feature added?
I’m not sure about that zip file, but for future reference, source code builds work based off of revisions of code. If you want to know if a build contains a feature or fix that was added with a specific commit of code, check to see if the build’s date and time is later than the date and time of the commit. If it is, then the build was compiled after the code was committed, and so should have the code present in the build (the feature should be there). Before the source moved from SVN to Git, you could also check the revision number (i.e. build was r5000, commit was r4990). That no longer seems to be possible, though, with Git’s revision numbers.
Ace’s test case sounds like it’s far more useful for multiple armatures, which makes sense. Multithreading probably isn’t going to be of much use for a single armature. Also, you’re talking about a difference of just a few frames, which isn’t that much when you’re talking about real-world applications (in which you generally wouldn’t have that many bones for a single object, that many polygons for a single object, or so few objects in a single game). You might want to try a more generalized real-world example benchmark (more reasonable polycount, less bones, and more objects) to see if multi-threading impacts a single object more-so than not.
After confirming that the issue does continue to happen with the most recent version of Blender (after the changes Ace mentioned), please submit a bug report to the Blender developer site (if you wish).