Page MenuHome

Patch to allow recording of static objects in game engine
Closed, ResolvedPublicPATCH


This patch addresses a limitation in the "Record Animation" feature of the Blender Game Engine, where the motion of static objects animated by logic bricks is not recorded.

The patch allows for recording of the motion of static objects via a checkbox on the Physics panel. All static objects are given a new checkbox called "Record Animation" that appears under the "Actor" and "Ghost" checkboxes on the Physics panel. This checkbox only appears for static objects. When checked, the motion of the static object will be recorded, whenever game-engine recording is enabled via Game>Record Animation.

I've attached the patch as well as a sample blender project. The project is a simple game with a dynamic ball resting on a static cube. When the game is played, the static cube will oscillate back and forth causing the dynamic ball on top to eventually fall off. If you try to record the animation, only the motion of the dynamic ball will be recorded. However if you build blender with this patch, and check the "Record Animation" checkbox in the physics panel for the static cube, both objects will be properly recorded.

Dalai Felinto comment:

My only concern with the patch (and we are better off discussing that in the tracker) is that I would probably have a m_animate property
(instead of objprop.m_static_animate). This way we don't need to check IsDynamic() inside RecordAnimation(). That also means that if you have a dynamic object and temporary disable its Dynamics (via logic bricks) the object will still has its movements recorded, which I think it's reasonable (it may already happen, not sure if the actuator affects the result of IsDynamic() - too late now for me to check the code.

My response:

So you're saying that KX_GameObject::SetStaticAnimate should instead become SetAnimate that would set m_animate member?

But then how should KX_GameObject::SetPhysicsController (how m_bDyna is normally set) interact with the m_animate member? Should it irreversibly set m_animate to true for dynamic objects so that they will be recorded even if the object later loses the dynamic attribute?


Event Timeline

Updated patch (blender-static-animate-2.patch):

Changed variable naming to "record animation" such as m_record_animation or m_bRecordAnimation (removed mention of "static") to better communicate that the flag only controls animation recording, not animation itself. For example, a static object might be animated but not recorded if the new checkbox for "Record Animation" in the Physics panel is not checked.

Decoupled m_bRecordAnimation from m_bDyna in KX_GameObject so that m_bDyna or IsDynamic() do not need to be referenced in order to evaluate isRecordAnimation()

Record animation is now enabled in two places in KX_ConvertBulletObject() when

1. object is dynamic, or

2. object's "Record Animation" checkbox is checked

KX_ConvertBulletObject() only enables animation recording, never disables it, so an object that dynamically changes its physics type during a game engine session will continue to be recorded if it was initially a dynamic object.

Note that "record animation" flag only causes animation recording if the user has also selected game-engine recording via Game>Record Animation in UI.

For an example of what this patch can do, see:

In this animation, all of the moving objects (other than the marbles themselves) are static objects whose motion is controlled by logic bricks.

The patch allows the motion of these static objects to be recorded.

Rebased to 2.69.

This looks pretty good to me, and I think it's a good feature to add. But it has been a while since I looked at BGE code. I would need to look more deeply at ResetPhysicsObjectsAnimationIpo and resetNoneDynamicObjectToIpo before I could say I'm 100% OK with it; hopefully I can do that soon.

At this stage I suggest two changes:

  1. Move OB_RECORD_ANIMATION inside the enum that precedes it, and set it to 1 << 23.
  2. If this feature only makes sense for non-dynamic objects, maybe the field should be disabled in the UI for dynamic objects.

Feel free to object if I've misunderstood anything about your patch :)

Okay, I moved OB_RECORD_ANIMATION inside the enum that precedes it, and set it to 1 << 23.

Yes, the feature only makes sense for non-dynamic objects. The code already hides the "Record Animation" checkbox in the UI for dynamic objects.


Campbell Barton (campbellbarton) changed the task status from Unknown Status to Resolved.Dec 9 2013, 12:34 PM

Committed rB1831c930a5a2144e7941407e2a283cd168897626

Also added Python api access.

Added more comprehensive description to release log: