New dependency graph Spline IK with curve control dependency cycles. #46151

New Issue

Jaroslav Novotny · 2015-09-18T13:42:29+02:00

Jaroslav Novotny commented

2015-09-18 13:42:29 +02:00

System Information
Win7 GTX980Ti

Blender Version
Broken: 2.76 rc1 c586e30

Short description of error

With new dependency graph (blender.exe --enable-new-depsgraph) controlling a curve with Hook modifier that's targeting a bone in same armature that uses the curve for IK spline causes dependency cycle, something I would expect to work in new dependency graph.

The cycle is as follows:

Dependency cycle detected:
'BezierCurve[Object].GEOMETRY_MODIFIER(Hook-Armature)' depends on 'Armature[Object].Bone.008.BONE_DONE()' through 'Hook Modifier'
'Armature[Object].Bone.008.BONE_DONE()' depends on 'Armature[Object].Bone.008.BONE_READY()' through 'Ready -> Done'
'Armature[Object].Bone.008.BONE_READY()' depends on 'Armature[Object].Bone.008.BONE_POSE_PARENT()' through 'Pose -> Ready'
'Armature[Object].Bone.008.BONE_POSE_PARENT()' depends on 'Armature[Object].Bone.008.BONE_LOCAL()' through 'Bone Local - PoseSpace Link'
'Armature[Object].Bone.008.BONE_LOCAL()' depends on 'Armature[Object].POSE_INIT()' through 'PoseEval Source-Bone Link'
'Armature[Object].POSE_INIT()' depends on 'BezierCurve[Object].GEOMETRY_UBEREVAL()' through '[Curve.Path -> Spline IK] DepsRel'
'BezierCurve[Object].GEOMETRY_UBEREVAL()' depends on 'BezierCurve[Object].GEOMETRY_MODIFIER(Hook-Armature)' through 'Object Geometry UberEval'

Exact steps for others to reproduce the error

Create a Curve
Create Armature, extrude some bone chain and set Spline IK to the Curve
Add another bone in Armature, set VertexHook modifier on Curve to be controlled with this bone.

BlendFile

dep_graph_cycle.blend

Why it is important to work

Production rigs require Spline IK for spine or tentacles. It is possible to have 2 Armatures (Control and Deform one) to solve the dependencies, but they cause problems when the Rig is linked, because you make proxy from the control armature and not the deform one, which makes editing deform armature properties (bone ID properties) impossible. Having everything in one armature is the way to go and something we hope new dependency graph should fix.

**System Information** Win7 GTX980Ti **Blender Version** Broken: 2.76 rc1 c586e30 **Short description of error** With new dependency graph (blender.exe --enable-new-depsgraph) controlling a curve with Hook modifier that's targeting a bone in same armature that uses the curve for IK spline causes dependency cycle, something I would expect to work in new dependency graph. The cycle is as follows: ``` Dependency cycle detected: 'BezierCurve[Object].GEOMETRY_MODIFIER(Hook-Armature)' depends on 'Armature[Object].Bone.008.BONE_DONE()' through 'Hook Modifier' 'Armature[Object].Bone.008.BONE_DONE()' depends on 'Armature[Object].Bone.008.BONE_READY()' through 'Ready -> Done' 'Armature[Object].Bone.008.BONE_READY()' depends on 'Armature[Object].Bone.008.BONE_POSE_PARENT()' through 'Pose -> Ready' 'Armature[Object].Bone.008.BONE_POSE_PARENT()' depends on 'Armature[Object].Bone.008.BONE_LOCAL()' through 'Bone Local - PoseSpace Link' 'Armature[Object].Bone.008.BONE_LOCAL()' depends on 'Armature[Object].POSE_INIT()' through 'PoseEval Source-Bone Link' 'Armature[Object].POSE_INIT()' depends on 'BezierCurve[Object].GEOMETRY_UBEREVAL()' through '[Curve.Path -> Spline IK] DepsRel' 'BezierCurve[Object].GEOMETRY_UBEREVAL()' depends on 'BezierCurve[Object].GEOMETRY_MODIFIER(Hook-Armature)' through 'Object Geometry UberEval' ``` **Exact steps for others to reproduce the error** - Create a Curve - Create Armature, extrude some bone chain and set Spline IK to the Curve - Add another bone in Armature, set VertexHook modifier on Curve to be controlled with this bone. **BlendFile** [dep_graph_cycle.blend](https://archive.blender.org/developer/F234186/dep_graph_cycle.blend) **Why it is important to work** Production rigs require Spline IK for spine or tentacles. It is possible to have 2 Armatures (Control and Deform one) to solve the dependencies, but they cause problems when the Rig is linked, because you make proxy from the control armature and not the deform one, which makes editing deform armature properties (bone ID properties) impossible. Having everything in one armature is the way to go and something we hope new dependency graph should fix.

Jaroslav Novotny commented

2015-09-18 13:42:29 +02:00

Changed status to: 'Open'

Jaroslav Novotny commented

2015-09-18 13:42:29 +02:00

Added subscriber: @jerryno

Sergey Sharybin was assigned by Aaron Carlisle

2015-09-18 14:21:45 +02:00

Aaron Carlisle commented

2015-09-18 14:21:45 +02:00

Added subscriber: @Blendify

Sergey Sharybin commented

2015-09-18 14:41:14 +02:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2015-09-18 14:41:14 +02:00

Sergey Sharybin commented

2015-09-18 14:41:14 +02:00

As mentioned in the original release notes of the depsgraph currently only armature evaluation is split into granular evaluation steps. Other objects still needs work to support all sort of weird and wonderful configuration.

So thanks for the report, but currently it's not really a bug.

As mentioned in the original release notes of the depsgraph currently only armature evaluation is split into granular evaluation steps. Other objects still needs work to support all sort of weird and wonderful configuration. So thanks for the report, but currently it's not really a bug.

Lukas Tönne commented

2015-09-18 14:51:34 +02:00

Added subscriber: @LukasTonne

Lukas Tönne commented

2015-09-18 14:51:34 +02:00

I think the problem here is that the POSE_INIT component (evaluating the IK tree) is a parent for all the bones of the armature, regardless of whether they are actually part of the IK chain. The SplineIK constraint makes the pose dependent on the curve, while the curve depends on the single control bone (correctly)

Perhaps this code is a bit too greedy?
https://developer.blender.org/diffusion/B/browse/master/source/blender/depsgraph/intern/depsgraph_build_relations.cc$1477

I think the problem here is that the `POSE_INIT` component (evaluating the IK tree) is a parent for *all* the bones of the armature, regardless of whether they are actually part of the IK chain. The SplineIK constraint makes the pose dependent on the curve, while the curve depends on the single control bone (correctly) ![depsgraph.png](https://archive.blender.org/developer/F234219/depsgraph.png) Perhaps this code is a bit too greedy? https://developer.blender.org/diffusion/B/browse/master/source/blender/depsgraph/intern/depsgraph_build_relations.cc$1477

Cenek Strichel commented

2016-03-04 12:24:59 +01:00

Added subscriber: @Cenda

Cenek Strichel commented

2016-03-04 12:24:59 +01:00

Sorry for commented old report. I am solving same thing now. I am little bit confused. I understand that it is not possible use one armature for spline IK. When I tried it bone was jumping. I tried it again and it is working great. I don`t know how can I replicated this. It is working with both new and old deps graph. Do you know why it is ok? splineWorking.blend

Sorry for commented old report. I am solving same thing now. I am little bit confused. I understand that it is not possible use one armature for spline IK. When I tried it bone was jumping. I tried it again and it is working great. I don`t know how can I replicated this. It is working with both new and old deps graph. Do you know why it is ok? [splineWorking.blend](https://archive.blender.org/developer/F287496/splineWorking.blend)

Lukas Tönne commented

2016-03-04 13:59:23 +01:00

The situation is not unsolvable per-se, it's just that the depsgraph has to make the nodes detailed enough to properly resolve the order of updates. The old depsgraph simply cannot do this, while the new depsgraph just hasn't gotten enough attention in this area.

Without a valid solution by the depsgraph the order of updates is essentially random (or rather undefined). So in some cases (often depending on selected/unselected objects) you may still get a valid update order by accident and everything seems to work fine, but then breaks on seemingly unrelated changes.

The situation is not unsolvable per-se, it's just that the depsgraph has to make the nodes detailed enough to properly resolve the order of updates. The old depsgraph simply cannot do this, while the new depsgraph just hasn't gotten enough attention in this area. Without a valid solution by the depsgraph the order of updates is essentially random (or rather undefined). So in some cases (often depending on selected/unselected objects) you may still get a valid update order by accident and everything seems to work fine, but then breaks on seemingly unrelated changes.

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

New dependency graph Spline IK with curve control dependency cycles. #46151