Copy rot constraint does not update bone local axis for ensuing constraints/drivers #39456

New Issue

Hadrien Brissaud · 2014-03-27T13:51:47+01:00

Hadrien Brissaud commented

2014-03-27 13:51:47 +01:00

System Information
w7x64 gtx680

Blender Version
Broken: (2.70 release)
Worked: (optional)

Short description of error
I'm not sure what is going on here so the title might be misleading, apologies.
Drivers or constraints that affect location of a bone and come after a copy rotation constraint do not move the bone according to the constrained rotation (as if the bone was not rotated), even though drivers or constraints are set to local space and are arranged in correct order.
It can be worked around by using an offset bone (parent takes Z rotation, child moves on local Y) but one of the big upsides of Blender rigging system is that you don't need them (thanks to local vs. transform space).

I also noticed the units in the "transformation" constraint do not change along when the transformation type is changed to rot or scale (it stays in meters and centimeters).

Exact steps for others to reproduce the error
RotateZ the top bone (Bone.001), the small joint bone (Bone.002) should move along its local Y (constrained) axis, instead it just moves horizontally. In the example I used a transformation constraint but I tried with a driver on LocY and it's the same.

Hadrien

constraintLocalSpace.blend

**System Information** w7x64 gtx680 **Blender Version** Broken: (2.70 release) Worked: (optional) **Short description of error** I'm not sure what is going on here so the title might be misleading, apologies. Drivers or constraints that affect location of a bone and come after a copy rotation constraint do not move the bone according to the constrained rotation (as if the bone was not rotated), even though drivers or constraints are set to local space and are arranged in correct order. It can be worked around by using an offset bone (parent takes Z rotation, child moves on local Y) but one of the big upsides of Blender rigging system is that you don't need them (thanks to local vs. transform space). I also noticed the units in the "transformation" constraint do not change along when the transformation type is changed to rot or scale (it stays in meters and centimeters). **Exact steps for others to reproduce the error** RotateZ the top bone (Bone.001), the small joint bone (Bone.002) should move along its local Y (constrained) axis, instead it just moves horizontally. In the example I used a transformation constraint but I tried with a driver on LocY and it's the same. Hadrien [constraintLocalSpace.blend](https://archive.blender.org/developer/F82945/constraintLocalSpace.blend)

Hadrien Brissaud commented

2014-03-27 13:51:47 +01:00

Changed status to: 'Open'

Hadrien Brissaud commented

2014-03-27 13:51:47 +01:00

Added subscriber: @hadrien

Bastien Montagne was assigned by Sergey Sharybin

2014-04-10 19:15:31 +02:00

Sergey Sharybin commented

2014-04-10 19:15:31 +02:00

Added subscribers: @mont29, @Sergey

Sergey Sharybin commented

2014-04-10 19:15:31 +02:00

@mont29, you are one of few who're familiar with the bones. Is it something you can help with? :)

Bastien Montagne commented

2014-04-26 12:48:04 +02:00

Added subscriber: @JoshuaLeung

Bastien Montagne commented

2014-04-26 12:48:04 +02:00

Would like to summon you here, Joshua! :)

As far as I know, the whole constraints are evaluated in the org objects’s space (that what makes BKE_constraint_mat_convertspace(), at least).

The same goes for transform (from drivers or fcurves), but this is to be expected (transform orientation only affects transform tools in 3DView, nothing related to animations or so here).

So all this looks more like internal limitation than bug, to me? Though I wonder a bit why not reusing cob matrix in case of constraints, when doing space conversions? That would make constraints behave more like a stack - and open yet another can of worms probably…

Would like to summon you here, Joshua! :) As far as I know, the whole constraints are evaluated in the org objects’s space (that what makes `BKE_constraint_mat_convertspace()`, at least). The same goes for transform (from drivers or fcurves), but this is to be expected (transform orientation only affects transform tools in 3DView, nothing related to animations or so here). So all this looks more like internal limitation than bug, to me? Though I wonder a bit why not reusing cob matrix in case of constraints, when doing space conversions? That would make constraints behave more like a stack - and open yet another can of worms probably…

Bastien Montagne commented

2014-05-12 16:19:05 +02:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2014-05-12 16:19:05 +02:00

Bastien Montagne commented

2014-05-12 16:19:05 +02:00

Closing as archived for now. Anyway, this is not a bug. Might be considered as TODO, but it would most likely break all existing files so…

Hadrien Brissaud commented

2014-05-14 00:55:57 +02:00

Thanks for the clarification Bastien.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Copy rot constraint does not update bone local axis for ensuing constraints/drivers #39456