Page MenuHome

Python constraints, good in 2.46 not working anymore in 2.47
Closed, ArchivedPublic


Resolution: Fixed
Category: Animation system

2.46 was the first version to ever include pyconstraints and always worked for me. In 2.47 they work in Blender's 3D view, but are ignored at rendering time, or simply do not work at all.

Attached image 1: Image showing how it did work under 2.46

Attached image 2: Blender 2.47

Attached file contains armature from my example. The constrained bones copy the Y axis of their targets but not X or Z rotations.

Load in 2.46 (only 2.46), everything works fine. Load in 2.47, all bones which should be constrained are in their rest positions. The console reports no errors.

Event Timeline

Make sure that you've got scriptlinks enabled. Starting from 2.47, all places where pyscripts could be automatically run will only do so if scriptlinks are enabled (for security when running unknown files).

Sorry to bother you again.

Thank you for telling me about the scriptlink part. That fixes the problem in the 3d view, but unless I am missing another option that has to be enabled besides scriptlinks, script constrained bones are still reset to their rest positions at the time of rendering in 2.47.

Reopening report. Confirmed error when/after rendering.

I've tracked the error down to two places:
1) renderwin.c - BIF_do_render() has
which is apparently used to "avoid FRAMECHANGED slink in render callback"... however, this doesn't take into account that many rig elements also rely on this now

2) sceneRender.c (pyapi) same story here...

Assigning this py-related issue to Campbell to solve.

re-assigning to willian!


Improved that old hack, please test again and if you still find problems, report.

PS: now REDRAW scriptlinks also get executed during one frame renders, but that's how it used to be long ago and conforms to what happens during animations (both FRAMECHANGED and REDRAW are executed per frame). Easy to avoid, if needed, of course.


Willian Padovani Germano (ianwill) changed the task status from Unknown Status to Unknown Status.Sep 19 2008, 12:37 AM

This task was automatically closed as archived as part of migration, because the project or tracker this task belonged to is no longer active.